´ UNIVERSIDAD DE CONCEPCION FACULTAD DE INGENIER´IA ´ DPTO. DE INGENIER´IA ELECTRICA

Profesor Patrocinante: Mario Medina C. PhD.

Alternativas para aumentar el desempe˜ no de red en un cluster Linux Ra´ ul Alejandro Hormaz´ abal Vivanco Informe de Memoria de T´ıtulo para optar al t´ıtulo de Ingeniero Civil Electr´onico.

Concepci´on, Chile. Diciembre 2007.

hola

A mi familia ....

a

1

Agradecimientos

A mis padres, Ra´ ul y Lilian, por su apoyo incondicional. A mis hermanos, Carolina y Andr´es, por ser como son. A mi profesor gu´ıa, Mario Medina, por su gran ayuda y siempre buena disposici´on. Y a todos mis compa˜ neros, por hacer mi estad´ıa en la universidad m´as entrenida. A todos ellos, les doy mis m´as sinceros agradecimientos.

a

1

Resumen

Los computadores se han convertido en un pilar de la ciencia y de la ingenier´ıa. Son una herramienta imprescindible de la industria y la comunidad cient´ıfica para recoger y analizar datos, modelar y simular problemas. Un cluster es un grupo de computadores unidos mediante una red, de manera tal que el conjunto es visto como un u ´nico computador con mayor capacidad de procesamiento. Dentro del desarrollo de los clusters, uno de sus principales problemas es c´omo realizar una comunicaci´on eficiente entre los distintos nodos. En el presente trabajo se presenta un analisis de como mejorar el desempe˜ no de la comunicaci´on entre los nodos de un cluster. Para ello, se presenta una descripci´on de la arquitectura de red de los clusters, posteriormente se hace una rese˜ na detallada del protocolo TCP y su evoluci´on, seguida de una explicaci´on del est´andar IEEE 802.3ad, tambien conocido como link aggregation. Luego, fueron realizados algunos experimentos, los cuales muestran resultados del comportamiento de ciertos par´ametros criticos en la comunicaci´on, con la limitante del hardware y software disponible. De esta forma, el enfoque dado en este trabajo fue mejorar el desempe˜ no de la red, dentro de las posibilidades que nos proporcion´o la tecnolog´ıa disponible. El software utilizado para los experimentos fue: el sistema operativo GNU/Linux con su implementaci´on de la arquitectura de red, el sistema de archivos paralelo (PVFS), y las herramientas de benchmark iperf y NetPIPE. En base a los resultados, se pudo observar como mejor´o el rendimiento de un cluster, aplicando ciertas optimizaciones a Linux. De esta forma, se comprob´o la influencia que tiene el rendimiento de la arquitectura de red, en el desempe˜ no de un cluster real.

I

a

1 ´ Indice

Resumen

I

´Indice

II

Lista de Figuras

IV

Lista de Tablas

VI

1. Introducci´ on 1.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Efecto de la comunicaci´on en la computaci´on distribuida . . . . . . . 2. Arquitectura de red 2.1. Modelo de red . . . . . . . . . . 2.2. Modelo cliente-servidor . . . . . 2.3. Ethernet . . . . . . . . . . . . . 2.4. Mejoras a la arquitectura de red 2.4.1. Infiniband . . . . . . . . 2.4.2. Myrinet . . . . . . . . . 2.4.3. 10 Gigabit Ethernet . . 2.4.4. Jumbo frames . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

1 2 3 5 5 7 9 13 13 16 16 18

3. Protocolo TCP 19 3.1. Encabezado TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.2. Estados de una conexi´on . . . . . . . . . . . . . . . . . . . . . . . . . 21

II

´Indice

3.3. Conexi´on . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1. Establecimiento de una conexi´on . . . . . . 3.3.2. Transferencia de datos . . . . . . . . . . . . 3.3.3. Termino de la conexi´on . . . . . . . . . . . . 3.4. Opciones de TCP . . . . . . . . . . . . . . . . . . . 3.4.1. Tama˜ no m´aximo de segmento (MSS) . . . . 3.4.2. Redimensionamiento de ventana . . . . . . . 3.4.3. Marca de tiempo . . . . . . . . . . . . . . . 3.4.4. Acuse de recibo selectivo . . . . . . . . . . . 3.5. Control de congesti´on . . . . . . . . . . . . . . . . . 3.5.1. Arranque lento . . . . . . . . . . . . . . . . 3.5.2. Prevenci´on de congesti´on . . . . . . . . . . . 3.5.3. Retransmisi´on r´apida y recuperaci´on r´apida 3.6. Implementaciones de TCP . . . . . . . . . . . . . . 3.6.1. BIC-TCP . . . . . . . . . . . . . . . . . . . 3.6.2. CUBIC TCP . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

22 24 25 27 28 29 30 32 32 33 33 35 36 37 38 40

4. Link aggregation 42 4.1. Tipos de link aggregation . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.2. Channel bonding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.2.1. Configuraci´on de bonding en Linux . . . . . . . . . . . . . . . 46 5. Resultados 5.1. Definici´on de los experimentos . . . . 5.2. Hardware disponible . . . . . . . . . 5.3. Software disponible . . . . . . . . . . 5.3.1. Iperf . . . . . . . . . . . . . . 5.3.2. NetPIPE . . . . . . . . . . . . 5.3.3. PVFS . . . . . . . . . . . . . 5.4. Experimentos . . . . . . . . . . . . . 5.4.1. Efecto del MTU . . . . . . . . 5.4.2. Efecto del n´ umero de flujos . 5.4.3. Efecto del buffer de datos . . 5.4.4. Efecto de la ventana de TCP 5.4.5. Latencia del driver bonding . 5.4.6. Prueba en cluster (PVFS) . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

48 48 48 49 49 50 52 52 52 56 58 60 61 62

6. Conclusiones

65

Referencias

69

III

a

1

2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7.

Lista de Figuras

El modelo OSI. . . . . . . . . . . . . . . . . . . . . . Comparaci´on modelo OSI y TCP/IP. . . . . . . . . . Divisi´on de nivel de enlace de datos . . . . . . . . . . Arquitectura simple de Infiniband [25]. . . . . . . . . Interconexi´on de nodo usando Infiniband [25]. . . . . Enlace myrinet [35]. . . . . . . . . . . . . . . . . . . . Arquitectura de un adaptador Intel PRO/10GbE [4].

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

6 8 9 14 15 16 17

Encabezado TCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagrama de estados de una conexi´on TCP [30]. . . . . . . . . . . . . Conexi´on TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Establecimiento de una conexi´on TCP . . . . . . . . . . . . . . . . . Termino de una conexi´on TCP en cuatro pasos. . . . . . . . . . . . . Termino de una conexi´on TCP en tres pasos. . . . . . . . . . . . . . . Comparaci´on del uso de opci´on de redimensionamiento de ventana. . Compartamiento de TCP, usando algoritmo arranque lento y prevenci´on de congesti´on [13]. . . . . . . . . . . . . . . . . . . . . . . . . . . 3.9. Comportamiento de TCP, usando retransmisi´on r´apida y recuperaci´on r´apida [13]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.10. Funci´on de crecimiento de ventana de BIC [38]. . . . . . . . . . . . . 3.11. Funci´on de crecimiento de ventana de CUBIC [28]. . . . . . . . . . .

20 23 24 25 27 28 31

4.1. Topolog´ıas usadas con link aggregation [32]. . . . . . . . . . . . . . . 4.2. Arquitectura de red en Linux con channel bonding . . . . . . . . . . .

43 45

3.1. 3.2. 3.3. 3.4. 3.5. 3.6. 3.7. 3.8.

35 38 40 41

IV

Lista de Figuras

5.1. iperf como servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2. iperf como cliente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3. NetPIPE como servidor (nodo 2) y cliente (nodo 1) . . . . . . . . . . 5.4. Contenido de archivo nphosts. . . . . . . . . . . . . . . . . . . . . . . 5.5. Contenido de archivo de salida (salida.txt). . . . . . . . . . . . . . . . 5.6. Esquema de Red con una interfaz. . . . . . . . . . . . . . . . . . . . . 5.7. Variaci´on del throughput en el tiempo ante cambios en MTU. . . . . 5.8. Variaci´on del throughput ante cambios en el MTU. . . . . . . . . . . 5.9. Esquema de Red con dos interfaces. . . . . . . . . . . . . . . . . . . . 5.10. Variaci´on del throughput en el tiempo ante cambios en MTU, usando bonding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.11. Variaci´on del throughput ante cambios en el MTU, usando bonding. . 5.12. Script simplificado para generar rangos de flujos TCP. . . . . . . . . . 5.13. Evoluci´on del throughput ante variaci´on en el n´ umero de flujos TCP. 5.14. Script simplificado para generar variaci´on de buffer con seis flujos TCP. 5.15. Evoluci´on del throughput ante variaci´on del tama˜ no del buffer. . . . . 5.16. Script simplificado para generar variaci´on de la ventana con seis flujos TCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.17. Evoluci´on del throughput ante variaci´on del tama˜ no de la ventana. . 5.18. Comparaci´on de latencias entre nodos que usan y no usan bonding. . 5.19. Tiempo de copiado de archivo con diferentes m´etodos de interconexi´on.

50 50 51 51 51 53 53 54 54 55 56 57 58 59 59 60 61 62 64

V

a

1

5.1. 5.2. 5.3. 5.4.

Lista de Tablas

Datos obtenidos en experimento de variaci´on del MTU. . . . . . . . . Datos obtenidos en porcentaje, en experimento de variaci´on del MTU Datos obtenidos en experimento con PVFS. . . . . . . . . . . . . . . Porcentajes obtenidos en experimento con PVFS respecto al valor del MTU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5. Porcentajes obtenidos en experimento con PVFS respecto al n´ umero de interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

56 56 63 63 63

VI

Cap´ıtulo

1 Introducci´ on

Las tecnolog´ıas de la informaci´on y las comunicaciones tienen un papel cada vez m´as decisivo en la posici´on cient´ıfica y econ´omica de las naciones en esta era globalizada. Los computadores se han convertido en un pilar de la ciencia y de la ingenier´ıa. Son una herramienta imprescindible de la industria y la comunidad cient´ıfica para recoger y analizar datos, modelar y simular problemas. Por ello, se hace necesario buscar alternativas para la capacidad de procesamiento de las m´aquinas, ya que cada vez aparecen m´as aplicaciones y problemas que requieren de un gran poder de c´omputo. Una alternativa interesante es el procesamiento paralelo, el cual nos permite obtener las velocidades de procesamiento requeridas sin la necesidad de usar componentes de alta velocidad. Un cluster es un grupo de computadores unidos mediante una red de manera tal que el conjunto es visto como un u ´nico gran computador con mayor poder de procesamiento. En pocas palabras, un cluster permite tratar a 10 computadores de 500 MHz que act´ uan en conjunto como si fuesen un s´olo computador de 5.000 MHz. Si bien este ejemplo es un simplificaci´on, ilustra a grosso modo el porqu´e de su desarrollo. Conforme el hardware de procesamiento ha incrementado su rendimiento a˜ no tras a˜ no, esto ha resultado en que el desempe˜ no total de un cluster est´e limitado generalmente por la arquitectura de red. Esta arquitectura engloba componentes como el hardware de red y el sistema operativo, con su implementaci´on de los protocolos de red. Por lo tanto, uno de los principales problemas actualmente en los clusters es c´omo realizar una comunicaci´on eficiente entre sus distintos nodos.

1

Cap´ıtulo 1. Introducci´on

Se han propuesto e implementado con ´exito mejoras a la arquitectura de red. Pero, no se debe olvidar que uno de los criterios de dise˜ no de la computaci´on distribuida, es el de obtener mayor procesamiento de datos a un bajo costo relativo de sus componentes. Las mejoras propuestas en la arquitectura de red para un entorno de procesamiento paralelo se pueden dividir en dos grupos: hardware y software. El hardware es claramente el componente preponderante en el rendimiento de la red y es donde continuamente se est´an desarrollando y consiguiendo mejoras. El software consiste principalmente en el sistema operativo y su implementaci´on de los distintos protocolos de comunicaci´on. El protocolo m´as usado en estos entornos es, sin duda, TCP/IP. TCP/IP no es siempre la mejor opci´on para realizar la comunicaci´on ´ınterprocesos en una red de alta velocidad, ya que TCP/IP est´a dise˜ nado para ser un protocolo confiable para ser usado en redes no confiables. Por otro lado, una red de alta velocidad en un cluster es un entorno generalmente confiable, por lo tanto, las caracter´ısticas implementadas por TCP/IP para asegurar la confiabilidad en la comunicaci´on no son realmente necesarias. En base a esto, se puede decir que TCP/IP implementa funcionalidades superfluas para la comunicaci´on en un cluster de computadores. Adem´as, estudios demuestran que TCP/IP no escala adecuadamente a la velocidad de los procesadores y de las redes actuales [20]. Por lo que en aplicaciones que requieran hacer uso intensivo de la velocidad de los procesadores y de la red, probablemente no lo har´an debido al ((cuello de botella)) que significa el uso de TCP/IP para estos fines.

1.1.

Objetivos

Esta memoria de t´ıtulo tiene como objetivo general: mejorar el desempe˜ no de la comunicaci´on entre nodos de un cluster. Los objetivos espec´ıficos son: Identificar par´ametros cr´ıticos en el comportamiento de la comunicaci´on de un cluster. Estudiar modificaciones a la comunicaci´on, con el fin de aumentar su desempe˜ no. Estudiar alternativas para la comunicaci´on entre los nodos de un cluster Familiarizarse con el uso de herramientas de software que permitan medir las variables relevantes en la comunicaci´on de un cluster.

2

Cap´ıtulo 1. Introducci´on

1.2.

Efecto de la comunicaci´ on en la computaci´ on distribuida

Como ya se ha mencionado, un cluster es un grupo de computadores interconectados entre s´ı mediante una red de alta velocidad de manera que el conjunto es visto como un solo supercomputador. De esta forma se presenta el problema el retardo en la comunicaci´on entre los nodos emisor y receptor. Este retardo no s´olo incluye al retardo del canal de comunicaci´on, sino que corresponde m´as bien al retardo presentado por todo el sistema. Este tipo de retardo es conocido como latencia. Para el caso particular de un cluster es de especial inter´es la latencia de un mensaje entre dos nodos cualquiera. Una definici´on adecuada de la latencia de un mensaje es el tiempo transcurrido entre el comienzo del env´ıo de un mensaje hasta que se pone a disposici´on del receptor la informaci´on contenida en el mensaje. La latencia de un mensaje depende de la combinaci´on de varios factores [5], algunos de estos factores son: Funcionamiento de la interconexi´ on: Incluye retardos por ca´ıdas, retardos en el montaje y desmontaje de las conexiones, retardos en la propagaci´on de las se˜ nales por los alambres o fibras y el retardo producido por el tr´ansito a trav´es de los distintos componentes l´ogicos en la transmisi´on. Es decir, el funcionamiento de la interconexi´on corresponde al medio f´ısico de transmisi´on de datos. Comportamiento de la interconexi´ on: Incluye al consumo de recursos asociados para la mantenci´on de la calidad del servicio en aspectos como confiabilidad, control de flujo, control de acceso, tama˜ nos de paquetes, etc. Es decir, consiste en el software usado para asegurar el correcto funcionamiento del medio f´ısico. Interfaces de red: Incluye retardos producidos por el software que ayuda a transportar los datos desde y hacia las interfaces de red. Efectos del sistema de memoria: Incluye retardos producidos en el movimiento de los datos desde la cache hacia la estructura de red del sistema y viceversa. Protocolos: Incluye costos indirectos en el software tanto del emisor como el receptor, incluyendo retardos en el bus de memoria, en la cache y retardos debidos al largo del c´odigo. Otro par´ametro muy importante es la velocidad de la transferencia de los datos, este par´ametro es conocido como throughput, y es de vital importancia, ya que un throughput elevado permite la transmisi´on de una gran cantidad de datos en periodos de tiempos cortos.

3

Cap´ıtulo 1. Introducci´on

Un u ´ltimo par´ametro, de vital importancia en la comunicaci´on de un cluster, es la escalabilidad. La escalabilidad consiste en la capacidad de la red de crecer, por consiguiente, consiste en la capacidad de extender un cluster, aumentando la cantidad de nodos para el procesamiento. De lo anteriormente mencionado, se entiende que tanto el hardware y software son parte activa de estos par´ametros cr´ıticos para la comunicaci´on entre nodos. Este proyecto de tesis presenta una descripci´on de la arquitectura de red de un cluster. Adem´as se realizar´an experimentos para mejorar algunos de los par´ametros cr´ıticos en la comunicaci´on, con la limitante del hardware y software disponible. Respecto al hardware, la tecnolog´ıa usada sera ((Gigabit Ethernet)), por lo que el enfoque estar´a dado en mejorar el desempe˜ no de la red, dentro de las posibilidades de esta tecnolog´ıa. En cuanto al software, se usar´a el sistema operativo GNU/Linux y el protocolo TCP/IP, por tanto, se tratar´a de optimizar la implementaci´on de TCP/IP de Linux.

4

Cap´ıtulo

2 Arquitectura de red

Este cap´ıtulo presenta un resumen general de la arquitectura de red m´as usada actualmente. Se mencionan el modelo OSI, el modelo TCP/IP y el modelo clienteservidor. Luego, se mencionan tres de las m´as importantes mejoras desarrolladas en el ´ambito de las redes de datos: InfiniBand, Myrinet y 10GbE1 . Por u ´ltimo se mencionan los marcos jumbo (jumbo frames), una caracter´ıstica del hardware de red que ayuda a mejorar el desempe˜ no. La arquitectura de red de un cluster consiste t´ıpicamente en una red de ´area local (LAN), implementada para proporcionar condiciones ´optimas en la transferencia de datos. Para introducir en la arquitectura de red de los clusters, se presenta un breve resumen del modelo de red, conocido como modelo OSI (Open System Interconnection).

2.1.

Modelo de red

El modelo OSI es una arquitectura por niveles para el dise˜ no de sistemas de red que permite la comunicaci´on entre todo tipo de computadores. El modelo OSI es un modelo para entender y dise˜ nar un arquitectura de red robusta, flexible e interoperable. El modelo OSI est´a compuesto por siete niveles diferentes pero relacionados entre s´ı, como se muestra en la figura 2.1. Como se ha mencionado, el modelo OSI consta de siete niveles ordenados, estos son: 1

acr´ onimo del est´ andar 10 Gigabit Ethernet

5

Cap´ıtulo 2. Arquitectura de red

Figura 2.1. El modelo OSI.

F´ısico (nivel 1): Nivel encargado de realizar las funciones para transmitir los datos a trav´es de un medio f´ısico. Principalmente trabaja con las especificaciones el´ectricas y mec´anicas de las interfaces y del medio de transmisi´on de los datos. Tambi´en define los procedimientos que los dispositivos f´ısicos (controladores) y medios de transmisi´on deben seguir para realizar la transmisi´on. Enlace (nivel 2): Nivel encargado de asegurar la confiabilidad del medio f´ısico en la transmisi´on de los datos, y de asegurar la entrega de los datos s´olo nodo a nodo (misma red). De esta forma, presenta el nivel f´ısico ante el siguiente nivel (nivel de red), como un medio confiable y libre de errores. Red (nivel 3): Nivel encargado de la entrega de paquete desde el origen al destino. Este nivel debe ser capaz de operar, tanto en una misma red, como a trav´es de m´ ultiples redes. Transporte (nivel 4): Nivel encargado de la entrega de un mensaje desde el origen al destino. Pese a parecer muy similar al nivel de red, la diferencia radica en que el nivel de red se encarga de la entrega de extremo a extremo de paquetes individuales, sin reconocer relaci´on alguna entre esos paquetes. En cambio, el

6

Cap´ıtulo 2. Arquitectura de red

nivel de transporte toma estos paquetes y analiza si estos est´an relacionados entre s´ı, es decir, si los paquetes componen un mensaje. Sesi´ on (nivel 5): Nivel encargado del control de dialogo de la red; establece, mantiene y sincroniza la interacci´on entre sistemas de comunicaci´on. Presentaci´ on (nivel 6): Nivel encargado de la sintaxis de la informaci´on intercambiada entre dos sistemas. Aplicaci´ on (nivel 7): Nivel encargado de permitir tanto al usuario, como a las aplicaciones, acceder a la red. Proporciona interfaces de usuario y el soporte para servicios como correo electr´onico, transferencia de archivos, web, etc. El modelo OSI trata de estandarizar la arquitectura de red, para facilitar la interoperabilidad de diferentes tipos de sistemas. Sin embargo, antes de la aparici´on del modelo OSI ya exist´ıa un modelo, el cual se hab´ıa convertido en est´andar de facto, conocido como modelo el TCP/IP. Debido a esto, los niveles que implementa TCP/IP no corresponden exactamente a los niveles del modelo OSI. TCP/IP tiene cinco niveles: los cuatro primeros (f´ısico, enlace, red y transporte) concuerdan con los niveles del modelo OSI, la diferencia est´a en el quinto nivel de TCP/IP llamado nivel de aplicaci´on, el cual es equivalente a los niveles de sesi´on, presentaci´on y aplicaci´on del modelo OSI. En la figura 2.2 se muestra gr´aficamente la diferencias entre el modelo OSI y el modelo de red implementado por TCP/IP.

2.2.

Modelo cliente-servidor

El modelo cliente-servidor es un paradigma de protocolos de capa de aplicaci´on, que consta de dos instancias: uno o m´as procesos cliente y un proceso servidor. Cliente: Es un proceso que se ejecuta, generalmente en una m´aquina local, y que solicita los servicios de un servidor determinado. El proceso cliente es invocado por el usuario y termina su ejecuci´on cuando el servicio en cuesti´on se ha completado. Servidor: Es un proceso que se ejecuta, generalmente en una m´aquina remota, y que ofrece un servicio a los clientes. Un proceso servidor est´a dise˜ nado para ejecutarse indefinidamente esperando por peticiones de los clientes. En el modelo cliente-servidor el procesamiento se reparte entre clientes y servidores. Algunas ventajas del uso de este modelo son: Control centralizado.

7

Cap´ıtulo 2. Arquitectura de red

Figura 2.2. Comparaci´ on modelo OSI y TCP/IP.

Escalabilidad. Integraci´on simple entre sistemas. Disminuci´on de costos en hardware. El modelo cliente-servidor tiene distintas implementaciones, que reparten el procesamiento de los datos entre cliente y servidor de diferente forma. Estos son: Procesamiento en el servidor: El procesamiento de datos se realiza en el servidor, y los clientes son responsables s´olo de ofrecer una interfaz. Procesamiento en el cliente: Todo el procesamiento se lleva a cabo en el cliente, y s´olo las rutinas de validaci´on de los datos y otras funciones l´ogicas se realizan en el servidor. Procesamiento cooperativo: Procesamiento de datos que se realiza de forma distribuida, para as´ı aprovechar las capacidades de procesamiento tanto del cliente, como el servidor. La importancia del modelo cliente-servidor radica en que la gran mayor´ıa de los clusters lo implementan, para distribuir los datos a procesar por cada uno de los nodos.

8

Cap´ıtulo 2. Arquitectura de red

2.3.

Ethernet

En 1985, la IEEE inici´o un proyecto denominado ((proyecto 802)). El objetivo de este proyecto era definir est´andares que permitieran la intercomunicaci´on entre equipos de diferentes fabricantes, de forma de complementar el modelo OSI. En estricto rigor, el proyecto 802 especifica funciones para los niveles f´ısico, de enlace y parcialmente de red para lograr la interconectividad entre los distintos protocolos de redes de ´area local. El est´andar IEEE 802 subdividi´o el nivel de enlace de datos en dos subniveles (ver figura 2.3). Control de enlace l´ogico (LCC, Logical Link Control). Control de acceso al medio (MAC, Medium Access Control).

Figura 2.3. Divisi´ on de nivel de enlace de datos

Control de enlace l´ ogico El subnivel de control de enlace l´ogico corresponde a la capa superior del nivel de enlace de datos del modelo OSI. Algunas de las caracter´ısticas principales de este subnivel son: Utiliza los servicios ofrecidos por el subnivel MAC.

9

Cap´ıtulo 2. Arquitectura de red

Proporciona capacidad de direccionamiento interno y opcionalmente control de flujo y errores. Su protocolo interno est´a basado en la familia de protocolos HDLC. Independiza las capas superiores de las particularidades de cada LAN. Este subnivel ofrece tres tipos de servicios, estos son: No orientado a la conexi´ on: Este servicio, tambi´en conocido como servicio de tipo 1, no ofrece control de flujo, ni control de errores. Este servicio ni siquiera garantiza que los datos sean transmitidos. Este tipo de servicio es adecuado para el broadcast de datos no cr´ıticos o donde se requiera de un m´ınimo retardo. La detecci´on y correcci´on de errores se deja a los protocolos de los niveles superiores. Orientado a la conexi´ on: Este servicio, tambi´en conocido como servicio de tipo 2, establece una conexi´on l´ogica entre el emisor y el receptor, ofreciendo control de flujo y detecci´on de errores. Adecuado para una transferencia de datos confiable o cuando los protocolos de los niveles superiores no ofrecen detecci´on de errores. No orientado a la conexi´ on con reconocimiento: Este servicio, tambi´en conocido como servicio de tipo 3, combina los dos tipos anteriores. En este servicio el emisor env´ıa datos con la salvedad de que existe una confirmaci´on o acuse de recibo de los datos por parte de receptor. De esta forma se logra un servicio que soporta control de flujo y control de errores. En la actualidad, debido a las peque˜ nas tasas de error que se producen en el nivel f´ısico, y dada la existencia de protocolos en los niveles superiores, como por ejemplo TCP, que buscan eliminar los errores de comunicaci´on, el subnivel LLC s´olo utiliza su servicio tipo 1, el cual como se ha visto es el servicio m´as simple de los tres servicios provistos. En realidad, se puede afirmar que este servicio simplemente refleja los servicios del subnivel inferior, es decir, el subnivel MAC. Control de acceso al medio El subnivel de control de acceso al medio corresponde a la capa inferior del nivel de enlace de datos del modelo OSI. El subnivel MAC act´ ua como una interfaz entre el control de enlace l´ogico (LLC) y el nivel f´ısico. MAC provee direccionamiento y mecanismos de control de acceso al canal de datos, lo cual hace posible que varios terminales o nodos de un red se comuniquen entre s´ı. El mecanismo de direccionamiento

10

Cap´ıtulo 2. Arquitectura de red consiste en una direcci´on f´ısica conocida como ((direcci´on MAC)); esta direcci´on consiste en un identificador de 48 bits cuasi-´ unico2 que se le agrega a una interfaz de red. El subnivel MAC es el encargado de lograr la transmisi´on entre dos m´aquinas directamente conectadas. Para ello, debe gestionar el acceso al medio de transmisi´on y garantizar: La detecci´on de las colisiones en todas las situaciones. Que en caso de una colisi´on, se retransmitan las tramas todas las veces que sean necesarias hasta tener una transmisi´on libre de colisiones. El m´etodo de acceso al medio usado en ethernet se conoce como ((portadora sensible a acceso m´ ultiple con detecci´on de colisiones)) (CSMA/CD, Carrier Sense Multiple Access with Collision Detection). CSMA/CD CSMA/CD es el resultado de la evoluci´on de ((acceso m´ ultiple)) (MA, Multiple Access) a ((portadora sensible a acceso m´ ultiple)) (CSMA, Carrier Sense Multiple Access) y finalmente a CSMA/CD. El primer dise˜ no consist´ıa en un m´etodo de acceso m´ ultiple en el que cada nodo o computadora ten´ıa el mismo acceso al enlace. En el caso de MA no exist´ıa ninguna forma de coordinar la transferencia de datos, es decir, el acceso al enlace estaba abierto para todos los nodos en cualquier instante, despreciando la probabilidad de que dos computadores compitieran por el acceso al enlace al mismo tiempo. En el sistema de acceso CSMA, cualquier nodo que quiera transmitir datos debe chequear que no haya tr´afico en el enlace. Esta chequeo se realiza mediante la comprobaci´on de la existencia de cierto voltaje en el enlace. Si no se detecta voltaje, entonces se considera el canal de datos vac´ıo y se comienza a transmitir. CSMA reduce las colisiones pero no las elimina. La siguiente mejora a CSMA fue agregar el mecanismo de detecci´on de colisi´on, para obtener el sistema de acceso CSMA/CD. Este mecanismo funciona de forma que un nodo al querer transmitir datos escucha primero para asegurarse de que el canal de datos est´e libre. De ser as´ı, se transmiten los datos y despu´es se vuelve a escuchar. Durante este nuevo periodo de inspecci´on el nodo comprueba si en la linea aparecen voltajes extremadamente altos, lo cual es un indicador de una colisi´on. Si se detecta una colisi´on, el nodo deja inmediatamente de transferir datos y espera una cantidad de tiempo aleatorio (conocido como tiempo de back-off ) para volver a enviar datos. La mejora producida sobre CSMA es el tiempo que no se continua 2

En algunos casos la direcci´ on MAC puede ser la misma para dos o m´as adaptadores de red.

11

Cap´ıtulo 2. Arquitectura de red

usando el canal de datos para realizar un transferencia de datos in´ util (cuando existe una colisi´on). Finalmente, se puede mencionar que CSMA/CD se puede clasificar en tres variantes: CSMA no-persistente: Al escuchar, el nodo transmite inmediatamente si el canal de datos est´a libre. Por otro lado, si el canal de datos est´a siendo utilizado se espera un tiempo aleatorio y se vuelve a escuchar. CSMA 1-persistente: Al encontrarse el canal de datos ocupado, el nodo pasa a escuchar sin esperar ning´ un tiempo. En el instante que se detecta el canal desocupado los datos se transmiten inmediatamente. En este caso, los tiempos de propagaci´on largos deben ser evitados, ya que con ellos aumenta la probabilidad de que diferentes nodos intenten acceder al canal de datos al mismo tiempo, lo que puede suceder debido a que los dem´as nodos interpretan que el canal de datos est´a libre cuando en realidad est´a siendo ocupado por una trama emitida por otro nodo. El nombre de este tipo de variante se debe a que existe un probabilidad 1 de que la trama se transmita cuando el canal de datos est´a libre. CSMA p-persistente: Si canal est´a ocupado, el transmisor se pone a escuchar hasta encontrarlo libre. Una vez que el canal est´a libre el nodo decide si transmite los datos. Para ello ejecuta un algoritmo que dar´a la orden de transmitir con una probabilidad p, o de permanecer a la espera con una probabilidad q = (1 − p). Con el transcurso de los a˜ nos ethernet ha ido evolucionando, apareciendo nuevas especificaciones como: Fast Ethernet. Gigabit Ethernet. 10 Gigabit Ethernet. Estas variaciones de ethernet, por lo general, no son m´as que un aumento de la velocidad de transferencia de datos en un factor determinado. Mas adelante en la secci´on 2.4.3 mencionaremos el est´andar 10 Gigabit Ethernet, el cual es la u ´ltima especificaci´on de ethernet.

12

Cap´ıtulo 2. Arquitectura de red

2.4.

Mejoras a la arquitectura de red

Los cambios recientes introducidos en las capas inferiores del modelo OSI (f´ısico y de red) est´an, casi exclusivamente, destinados a mejorar el desempe˜ no de la red. En esta secci´on presentamos tres tecnolog´ıas desarrolladas en los u ´ltimos a˜ nos, usadas ´ en el campo de la computaci´on distribuida. Estas son: InfiniBand. Myrinet. 10 gigabit Ethernet. En los siguientes p´arrafos describimos en mayor detalles estas tecnolog´ıas.

2.4.1.

Infiniband

InfiniBand nace en 1999, con el nombre de ((System I/O)). InfiniBand fue el resultado de la uni´on de dos proyectos: ((Future I/O)), proyecto desarrollado por Compaq, IBM y HP; y ((Next Generation I/O)), desarrollado por Dell, Hitachi, Intel, NEC, Siemens y Sun Microsystems. En un principio InfiniBand se dise˜ n´o como una red de ´area de sistema (((System Area Network)), SAN), de ah´ı su primera denominaci´on; a partir de este dise˜ no, InfiniBand ser´ıa capaz de interconectar CPUs y proveer E/S de alta velocidad para aplicaciones de bajo nivel. Tomando esta caracter´ısticas InfiniBand ser´ıa potencialmente capaz de reemplazar a varios est´andares de E/S, tales como: PCI, canal de fibra (fibre channel ), ethernet, etc. Sin embargo, el impacto de InfiniBand ha sido mucho menor, ya que pese a tener grandes posibilidades de aplicaci´on, su uso se ha visto limitado a clusters de computadores. Arquitectura La especificaci´on de InfiniBand define una arquitectura de interconexi´on serial de alta velocidad, basada en los llamadas tramas de switches (((switched fabric))). Estos conjuntos de switches permiten definir enlaces entre 2.5 y 30 Gbps, resolviendo las limitaciones de escalabilidad, expansibilidad y tolerancia a fallas de la arquitectura de bus compartido. Este nuevo sistema de interconexi´on deja atr´as el modelo de E/S basada en transacciones locales a trav´es de buses compartidos para implantar un nuevo modelo basado en el paso remoto de mensajes a trav´es de canales. Esta arquitectura es totalmente independiente del sistema operativo y de la CPU. En la figura 2.4 se

13

Cap´ıtulo 2. Arquitectura de red

muestra un diagrama simple de la arquitectura de InfiniBand. En ella se puede apreciar como uno o m´as nodos est´an conectados entre s´ı, a trav´es de una trama de switches. Un nodo puede representar tanto un host, como un servidor o un sistema de E/S, como un disco duro.

Figura 2.4. Arquitectura simple de Infiniband [25].

La especificaci´on InfiniBand define un enlace base o simple llamado 1x. La velocidad de transmisi´on de este enlace simple es de aproximadamente 2.5 Gbps. Este enlace tambi´en permite comunicaci´on full-duplex por lo que puede lograr una velocidad de hasta 5 Gbps. Adem´as del enlace base, InfiniBand proporciona otras dos velocidades de conexi´on, conocidas como 4x y 12x. Actualmente los enlaces de 12x son bastante usados en clusters. Sobre los velocidades de transmisi´on cabe mencionar que los 2.5 Gbps corresponden a la transmisi´on de datos en bruto, ya que InfiniBand usa una codificaci´on 8B/10B, por lo que, cada 10 bits transmitidos s´olo 8 corresponden a datos. Por lo tanto, si la velocidad de transmisi´on de datos en bruto es 2.5 Gbps, la taza real de transmisi´on de datos es 2 Gbps. Los datos transmitidos con InfiniBand consisten en paquetes de hasta 4 KBytes, los cuales se agrupan para formar mensajes. Un mensaje puede ser: Una operaci´on de acceso directo a memoria de forma remota, conocido como RDMA (Remote Direct Memory Access). Una operaci´on por el canal de datos. Una operaci´on basada en una transacci´on.

14

Cap´ıtulo 2. Arquitectura de red

Una operaci´on de transmisi´on multicast. Una operaci´on at´omica. InfiniBand se basa en las llamadas tramas de switches, las cuales interconectan a los diferentes nodos. En la figura 2.5 se muestra la interconexi´on mediante InfiniBand.

Figura 2.5. Interconexi´ on de nodo usando Infiniband [25].

En la figura 2.5 se puede apreciar dos componentes utilizados para la interconexi´on entre nodo y switch, estos son: HCA (((Host Channel Adapter ))) y TCA (((Target Channel Adapter ))). Los HCA son los encargados de conectar a los switches con la memoria de un nodo, correspondiente a una CPU; en general, los HCA deben encargarse de transmitir o recibir los datos desde o hacia la memoria (RDMA). Para ello, deben adaptar los datos a los paquetes de 4 Kbytes o convertir los paquetes en datos. El uso de un HCA permite eliminar el procesamiento de red por parte de la CPU. Por su parte, los TCA deben unir a los nodos que corresponden a dispositivos de E/S, con los dem´as componentes de la red; en resumen, deben traducir los datos entrantes, para que el controlador del dispositivo de E/S pueda interpretarlos o convertir los datos que el dispositivo debe enviar en paquetes de red.

15

Cap´ıtulo 2. Arquitectura de red

2.4.2.

Myrinet

Myrinet es una tecnolog´ıa de comunicaci´on de alto desempe˜ no, dise˜ nada por Myricom en 1995, para redes de ´area local. Myrinet est´a ampliamente extendida en la interconexi´on de clusters. Actualmente Myrinet es un est´andar ANSI (ANSI/VITA 26-1998). Algunas caracter´ısticas de Myrinet son: Control de flujo, control de errores y monitoreo del enlace. Baja latencia a trav´es de switches, con monitorizaci´on para alta disponibilidad. Redes con switches, las cuales permiten escalabilidad y tolerancia a fallas. Tarjetas de red con chips integrados, que permiten procesar las comunicaciones de red, liberando as´ı a la CPU de parte del procesamiento de las comunicaciones. Un enlace Myrinet est´a compuesto por un par de canales, que f´ısicamente corresponden a dos cables de fibra ´optica, uno de subida y el otro de bajada (ver figura 2.6). El throughput real alcanzado por Myrinet es muy cercano al te´orico, debido a su bajo overhead. Tambi´en producto de esto las latencias alcanzadas por Myrinet son muy bajas.

Figura 2.6. Enlace myrinet [35].

En resumen, se puede decir que Myrinet busca reemplazar el hardware de red, con el fin de mejorar el desempe˜ no de la misma, en latencia y throughput.

2.4.3.

10 Gigabit Ethernet

La u ´ltima especificaci´on de los est´andar ethernet, tambi´en se conoce como 10GbE. Como su nombre lo indica, 10GbE define velocidades de conexi´on de 10 Gbps.

16

Cap´ıtulo 2. Arquitectura de red

10GbE es la evoluci´on del est´andar IEEE 802.3, por lo que, la compatibilidad con versiones anteriores del est´andar est´a totalmente soportada. 10GbE mantiene los subniveles de control de enlace l´ogico (LLC) y control de acceso al medio (MAC), adem´as del formato y tama˜ nos de los frames. Sin embargo, existen diferencias claves en 10GbE relacionadas con el desempe˜ no. que no afectan la compatibilidad de ethernet. En las versiones anteriores de ethernet, tanto los datos como los mensajes de control se mueven serialmente desde y hacia la capa MAC. En cambio, 10GbE opera con datos en paralelo, por lo general se usan cuatro canales para transmitir y otros cuatro para recibir. En la figura 2.7 se muestra la arquitectura de un adaptador 10GbE.

Figura 2.7. Arquitectura de un adaptador Intel PRO/10GbE [4].

Al tener varios canales de recepci´on y transmisi´on, un adaptador 10GbE s´olo permite operar en modo full-duplex, lo que difiere de las versiones anteriores de ethernet, cuyo modo de operaci´on era half duplex. Al abandonar el modo de operaci´on half duplex, tambi´en se abandona el m´etodo de acceso al medio CSMA/CD (((Carrier Sense Multiple Access with Collision Detection))), ya que al funcionar exclusivamente en modo full-duplex se elimina la existencia de colisiones. Estas dos diferencias proveen a 10GbE de mayor velocidad y menor latencia en las peticiones de transacci´on. 10GbE define dos familias de capa f´ısicas (PHYs), ´estas son: LAN PHY: Dise˜ nado para ser utilizado en redes de fibra; tales como fibra monomodo, para distancias largas; y fibra multimodo, para distancias cortas. WAN PHY: Dise˜ nado para ser utilizado con interfaces SONET/SDH OC192/STM-64, que proporcionan soporte a redes extensas, tales como redes metropolitanas, nacionales e internacionales.

17

Cap´ıtulo 2. Arquitectura de red

En un principio, el est´andar 10 GbE fue especificado s´olo para interfaces de fibra ´optica. Pero, con el tiempo han aparecido especificaciones que hacen uso de la tecnolog´ıa de cobre para las interfaces, tales como los est´andares 10GBase-CX (IEEE 802.3ak) que utiliza cableado de cobre de alta calidad, desarrollado inicialmente para el cableado de redes InfiniBand, y 10GBase-T (IEEE 802.3an aprobado en Junio del 2006) que utiliza cables de par trenzado.

2.4.4.

Jumbo frames

jumbo frames consiste en una mejora a las redes ethernet. Los jumbo frames permiten al hardware ethernet enviar, recibir y transmitir marcos ethernet mayores a 1518 bytes, lo que corresponde a un MTU de 1500 bytes. Los jumbo frames m´as usados y soportados por el hardware actual, son los que tienen un valor de MTU de 9000 bytes. Este aumento del tama˜ no de los marcos ethernet tiene por objetivo mejorar el desempe˜ no de TCP y reducir el trabajo de la CPU. La raz´on de la mejora es evidente, ya que al tener marcos de mayor tama˜ no aumenta la cantidad de datos transferidos por marco. Por lo tanto, son necesarios menos marcos para transferir la misma cantidad de datos, lo que libera a la CPU de procesamiento. Seg´ un [22] el desempe˜ no se puede expresar como: T hroughput =

0.7 · M SS √ RT T · packet loss

(2.1)

Por lo tanto, el throughput de TCP es proporcional al MSS (((Maximum Segment Size))), el cual como veremos en el cap´ıtulo 3 est´a relacionado directamente con el MTU. A partir, de lo mencionado en est´a secci´on, podemos afirmar que el uso de los jumbo frames mejora el throughput de TCP. Por lo tanto, experimentar con el tama˜ no de los marcos consiste en una experiencia a realizar en la presente tesis. Finalmente, se debe aclarar que el uso de los jumbo frames est´a relacionado con los niveles uno y dos del modelo OSI, y es necesario hardware que sea capaz de soportar estos cambios.

18

Cap´ıtulo

3 Protocolo TCP

El siguiente cap´ıtulo describe el funcionamiento del protocolo TCP. Se describen sus encabezados, estados de conexi´on, opciones m´as relevantes, c´omo realiza el control de flujo, y finalmente se mencionan sus implementaciones existentes. TCP (Transmission Control Protocol ) es un protocolo dise˜ nado para ser utilizado como un protocolo de comunicaci´on confiable, orientado a la conexi´on, que permite intercambio de datos entre dos nodos interconectados entre s´ı en las redes de comunicaci´on. TCP s´olo supone que se puede acceder a un servicio de transmisi´on de datagramas simple (datagrama IP), poco confiable, de los protocolos implementados en el nivel inferior. A partir de estos datagramas, TCP implementa un modelo de control que debe proveer confiabilidad, control de flujo y transferencia b´asica de datos. TCP implementa diferentes caracter´ısticas, algunas de ellas son: Protocolo unicast: TCP es un protocolo unicast, es decir, TCP s´olo permite intercambio de datos entre dos partes (un receptor y un emisor). Estado de la conexi´ on: TCP es un protocolo orientado a la conexi´on, por lo que antes de enviar los datos debe establecer la conexi´on entre ambos extremos. La idea de esto es sincronizar ambas partes, para as´ı asegurar que ambos extremos est´en comunicados y sean reconocidos entre s´ı. Confiabilidad: TCP debe asegurar que la secuencia de datos que se transmiten lleguen al otro extremo, y en la misma secuencia en la cual fueron generados. De presentarse datos perdidos, duplicados o corruptos, ser´a necesario retransmitirlos.

19

Cap´ıtulo 3. Protocolo TCP

Full duplex: TCP es un protocolo full-duplex, es decir, ambos nodos pueden enviar y recibir datos en una misma conexi´on. Desde el punto de vista de un proceso de aplicaci´on, una conexi´on full-duplex permite la existencia de dos flujos independientes que se mueven en direcciones opuestas. Control de flujo: TCP implementa control sobre el flujo. Cada extremo de una conexi´on TCP tiene una cantidad finita de espacio para su buffer, por lo tanto, un receptor TCP permite que el emisor env´ıe solamente una cantidad de datos equivalente al tama˜ no de su buffer. De esta forma se evita congesti´on en la conexi´on.

3.1.

Encabezado TCP

TCP requiere un encabezado en cada segmento de datos, para de esta forma implementar sus distintas funcionalidades. 0

15 16

Direcci´ on del puerto de origen

31

Direcci´on del puerto de destino

N´ umero de secuencia

N´ umero de acuse de recibo Tama˜ no del encabezado

Reservados

U A P R S F R C S S Y I G K H T N N

Suma de comprobaci´ on

Tama˜ no de la ventana Puntero urgente

Opciones TCP

Relleno

Figura 3.1. Encabezado TCP.

En la figura 3.1 se puede observar el encabezado de un segmento TCP. A continuaci´on se realiza un breve descripci´on de los campos del encabezado TCP: Un campo de 16 bits de direcci´on del puerto de origen.

20

Cap´ıtulo 3. Protocolo TCP

Un campo de 16 bits de direcci´on del puerto de destino. Un campo de 32 bits de n´ umero de secuencia. Un campo de 32 bits de n´ umero de acuse de recibo. Un campo de 4 bits de tama˜ no del encabezado. Un campo de 6 bits reservados. Una secci´on de 6 bits de control donde cada bit tiene una funci´on espec´ıfica. • URG : Indica que puntero de datos urgentes es v´alido. • ACK : Indica que el numero de acuse de recibo es v´alido. • PSH : Solicita el env´ıo inmediato de datos. • RST : Reinicia la conexi´on. • SYN : Sincroniza los n´ umeros de secuencia al comenzar la conexi´on. • FIN : Finaliza la conexi´on de forma normal. Un campo de 16 bits de tama˜ no de ventana. Un campo de 16 bits de suma de comprobaci´on (checksum). Un campo de 16 bits de puntero de datos urgentes. Un campo de opciones TCP de longitud variable, pero siempre m´ ultiplo de 8 bits. Un campo de relleno de longitud variable.

3.2.

Estados de una conexi´ on

Una conexi´on TCP durante su tiempo de vida se mueve dentro de diferentes estados. Seg´ un [26], los estados por lo cuales se pasa son: LISTEN: Representa la espera por una solicitud de conexi´on de cualquier agente (emisor) TCP en cualquier puerto. SYN-SENT: Representa la espera por una solicitud de conexi´on correspondiente, luego de haber enviado un solicitud de conexi´on. SYN-RECEIVED: Representa la espera por una paquete que confirme (ACK) la solicitud de conexi´on tras haber recibido y enviado una solicitud de conexi´on.

21

Cap´ıtulo 3. Protocolo TCP

ESTABLISHED: Representa una conexi´on abierta, los datos recibidos son entregados al usuario. Estado normal para la fase de transferencia de una conexi´on. FIN-WAIT-1: Representa la espera por una solicitud de t´ermino de conexi´on proveniente de agente TCP remoto, o la espera por un paquete que confirme (ACK) una solicitud de terminaci´on previamente enviada. FIN-WAIT-2: Representa la espera por un solicitud de t´ermino de conexi´on de un agente TCP remoto. CLOSE-WAIT: Representa la espera por una solicitud de finalizaci´on de la conexi´on proveniente por el usuario local. CLOSING: Representa la espera del paquete que confirma el recibo de la solicitud de finalizaci´on. LAST-ACK: Representa la espera del paquete de confirmaci´on de la solicitud de finalizaci´on enviada despu´es de enviar el paquete de confirmaci´on al solicitud de finalizaci´on recibida. TIME-WAIT: Representa el tiempo de espera para asegurar que el agente TCP remoto recibi´o el paquete de confirmaci´on de su solicitud de finalizaci´on de la conexi´on. CLOSED: Representa un estado sin conexi´on. En realidad es un estado ficticio. En la figura 3.2 se puede apreciar aproximadamente c´omo una conexi´on TCP se desplaza por sus distintos estados.

3.3.

Conexi´ on

TCP, por ser un protocolo orientado a la conexi´on, debe asegurar fiabilidad en la transmisi´on de datos durante una conexi´on. Para ello, TCP crea una especie de circuito virtual entre extremos antes de transferir los datos y una vez finalizado el env´ıo de datos elimina este circuito virtual. A partir de esto, se puede apreciar que una conexi´on TCP est´a compuesta de tres fases, que son: Establecimiento de la conexi´on. Transferencia de datos. T´ermino de la conexi´on.

22

Cap´ıtulo 3. Protocolo TCP

Figura 3.2. Diagrama de estados de una conexi´ on TCP [30].

23

Cap´ıtulo 3. Protocolo TCP

Como ejemplo en la figura 3.3 se muestra la salida del programa tcpdump para una conexi´on TCP real, en este caso dos sistemas GNU/Linux. En ella se aprecia c´omo transcurre una conexi´on TCP. El establecimiento de la conexi´on se produce desde la primera l´ınea hasta la tercera l´ınea, luego la transferencia de datos va desde la cuarta l´ınea hasta la octava l´ınea y finalmente desde la novena hasta la u ´ltima l´ınea corresponde al t´ermino de la conexi´on. 1.-

IP 152.74.20.202.51354 > 152.74.20.201.22: S 1879774589:1879774589(0) win 5840 2.- IP 152.74.20.201.22 > 152.74.20.202.51354: S 1908201117:1908201117(0) ack 1879774590 win 5792 3.- IP 152.74.20.202.51354 > 152.74.20.201.22: . ack 1908201118 win 46 4.- IP 152.74.20.201.22 > 152.74.20.202.51354: P 1908201118:1908201139(21) ack 1879774590 win 46 5.- IP 152.74.20.202.51354 > 152.74.20.201.22: . ack 1908201139 win 46 6.- IP 152.74.20.202.51354 > 152.74.20.201.22: P 1879774590:1879774739(149) ack 1908201139 win 46 7.- IP 152.74.20.201.22 > 152.74.20.202.51354: . ack 1879774739 win 54 8.- IP 152.74.20.201.22 > 152.74.20.202.51354: P 1908201139:1908201158(19) ack 1879774739 win 54 9.- IP 152.74.20.201.22 > 152.74.20.202.51354: F 1908201158:1908201158(0) ack 1879774739 win 54 10.- IP 152.74.20.202.51354 > 152.74.20.201.22: . ack 1908201158 win 46 11.- IP 152.74.20.202.51354 > 152.74.20.201.22: F 1879774739:1879774739(0) ack 1908201159 win 46 12.- IP 152.74.20.201.22 > 152.74.20.202.51354: . ack 1879774740 win 54

Figura 3.3. Conexi´ on TCP

3.3.1.

Establecimiento de una conexi´ on

Primera fase de una conexi´on TCP, conocida como three-way handshake (apret´on de manos en tres sentidos). Su objetivo consiste en conocer por parte del emisor la disponibilidad del otro extremo (receptor) para realizar una transferencia de datos. El dialogo entre extremos se realiza generalmente en tres secuencias: El emisor env´ıa un paquete de petici´on con un n´ umero de secuencia aleatorio y el flag SYN activado (en adelante SYN). De esta forma, el emisor indica que quiere comenzar una conexi´on TCP. El receptor devuelve un paquete con su propio n´ umero de secuencia y un n´ umero de acuse de recibo (en adelante ACK), el cual corresponde al n´ umero de secuencia recibido m´as uno. As´ı el receptor acusa recibo del paquete enviado por el emisor.

24

Cap´ıtulo 3. Protocolo TCP

El emisor env´ıa un paquete ACK con un n´ umero de acuse de recibo que corresponde al n´ umero de secuencia del receptor mas uno. As´ı el emisor acusa recibo el paquete enviado por el receptor. En la figura 3.4 se puede apreciar gr´aficamente lo explicado sobre c´omo se inicia una conexi´on TCP.

Figura 3.4. Establecimiento de una conexi´ on TCP

3.3.2.

Transferencia de datos

En esta fase TCP debe encargarse de: Ordenar los datos. Retransmitir los paquetes perdidos. Descartar los paquetes duplicados. Eliminar los posibles errores de los datos. Evitar la congesti´on.

25

Cap´ıtulo 3. Protocolo TCP

Los tres primeros puntos se consiguen asignando un n´ umero de secuencia a cada paquete transmitido, y exigiendo un ACK para confirmar que el paquete enviado ha sido recibido correctamente. Si el ACK no es recibido en un per´ıodo de tiempo determinado, se transmite nuevamente el paquete. Por su parte, el receptor utiliza el n´ umero de secuencia de cada paquete para ordenar los paquetes que puedan haber llegado desordenadamente, y adem´as para eliminar los paquetes duplicados. Los paquete se consideran duplicados cuando presentan el mismo n´ umero de secuencia. Para eliminar los errores en los datos, TCP utiliza el campo de suma de comprobaci´on (checksum) presente en el encabezado. De esta forma el receptor comprueba cada paquete recibido, descartando los paquetes que presenten errores. En un principio, TCP controlaba la congesti´on utilizando un mecanismo de control de flujo. Este mecanismo consiste en que el receptor devuelve una ventana o window al emisor. Esta ventana especifica el numero de datos en bytes que el receptor est´a preparado para recibir en ese momento. Con el tiempo este mecanismo b´asico de control de flujo mostr´o que ten´ıa limitaciones. Debido a esto fueron apareciendo diferentes caracter´ısticas y algoritmos que complementaron el m´etodo antes descrito. La raz´on de la aparici´on de estas nuevas caracter´ısticas apunta casi exclusivamente a mejorar del desempe˜ no de TCP en la redes modernas, ya que con el correr de los a˜ nos el hardware y tecnolog´ıa de comunicaciones ha ido mejorando. Algunas de estas opciones o algoritmos que han aportado nuevas caracter´ısticas al dise˜ no original de TCP son: Opci´on de redimensionamiento de ventana. Opci´on de marca de tiempo. Opci´on de acuse de recibo selectivo (SACK). Algoritmo de ventana deslizante. Algoritmo de comienzo lento. Algoritmo de prevenci´on de la congesti´on. Algoritmo de retransmisi´on r´apida. Algoritmo de recuperaci´on r´apida. En las secciones 3.4 y 3.5 se explican con mayor detalle en que consisten estas nuevas modificaciones para mejorar el control de flujo de TCP.

26

Cap´ıtulo 3. Protocolo TCP

3.3.3.

Termino de la conexi´ on

Fase final de una conexi´on TCP, la cual entra en acci´on una vez que la transferencia de datos a finalizado. Al igual que la primera fase tiene como objetivo que un extremo (emisor o receptor) informe al otro que desea cerrar la conexi´on. Para ello realiza un dialogo de cuatro secuencias. La secuencia de terminaci´on de una conexi´on TCP consiste en: Un extremo, en este caso el receptor, env´ıa un paquete de terminaci´on con el flag FIN habilitado (en adelante FIN). El extremo que recibe el paquete de terminaci´on (emisor) responde con un ACK confirmando. El emisor que ya envi´o un paquete de acuse de recibo, ahora env´ıa un paquete de terminaci´on, es decir, un paquete FIN. El extremo que inici´o el termino de la conexi´on (receptor) acusa recibo del paquete de terminaci´on enviando el correspondiente ACK.

Figura 3.5. Termino de una conexi´ on TCP en cuatro pasos.

27

Cap´ıtulo 3. Protocolo TCP

En algunos casos, la secuencia de termino se puede reducir de cuatro a tres pasos1 . Esto se logra uniendo el segundo y tercer paso. El extremo en vez de enviar dos paquetes (un ACK y un FIN) env´ıa solamente un paquete. Este consiste en un paquete de acuse de recibo con los flags ACK y FIN habilitados (en adelante ACK/FIN). Las figuras 3.5 y 3.6 muestran gr´aficamente los dos tipos de t´erminos de conexi´on.

Figura 3.6. Termino de una conexi´ on TCP en tres pasos.

3.4.

Opciones de TCP

La infraestructura en redes ha tenido un significativo aumento en las velocidades de transmisi´on. TCP ha debido adaptarse a estas mejoras en la infraestructura de las comunicaciones, para ello ha implementado diferentes modificaciones para mejorar su desempe˜ no en redes de alta velocidad. Algunas de estas nuevas funcionalidades son implementadas en el campo ((Opciones TCP)). La longitud de este campo es variable pero siempre debe cumplir el requisito de ser m´ ultiplo de 8 bits, por lo tanto, si se utilizan opciones que dan como resultado una longitud no m´ ultiplo de 8 bits, ser´a necesario rellenar hasta completar la longitud requerida. 1

El establecimiento de una conexi´ on originalmente tambi´en constaba de cuatro pasos. Para llegar a lo que actualmente se conoce como three-way handshake se fundieron los pasos dos y tres, formando as´ı el actual segundo paso SYN/ACK

28

Cap´ıtulo 3. Protocolo TCP

En general, TCP utiliza estas opciones en la fase inicial de una conexi´on, es decir, en paquetes SYN y/o SYN/ACK. Sin embargo, existen otras opciones, en menor cantidad, disponibles para su utilizaci´on durante toda la conexi´on TCP. Algunas opciones relevantes para mejorar el rendimiento de TCP en redes de alta velocidad son: Tama˜ no m´aximo de segmento (((Maximum Segment Size)), MSS). Redimensionamiento de ventana ((Window Scale)). Marca de tiempo ((Timestamp)). Acuse de recibo selectivo (((Selective-Acknowledgements)), SACK) y (((SACKPermitted ))). A continuaci´on se explica en profundidad cada una de las opciones.

3.4.1.

Tama˜ no m´ aximo de segmento (MSS)

Esta opci´on sirve para obtener el tama˜ no m´aximo del segmento2 que el receptor puede recibir, de esta forma se define el segmento m´aximo que se usar´a durante la conexi´on. MSS es independiente de la direcci´on del flujo de datos, por lo tanto, pueden existir dos tama˜ nos m´aximos para cada sentido del flujo de datos. La opci´on MSS se usa solamente durante la fase SYN y SYN/ACK, y ocupa 32 bits en el encabezado. MSS se utiliza tambi´en para definir la m´axima unidad de transferencia (((Maximun Transfer Unit)), MTU) usada en la red, ya que la MTU y MSS se encuentran relacionadas tal como se muestra en la ecuaci´on 3.1. M T U = Encabezado IP + Encabezado T CP + M SS

(3.1)

El u ´nico inconveniente para la obtenci´on de MSS es que tanto el encabezado TCP, como el encabezado IP son variables, por lo tanto, como no se tiene certeza del tama˜ no de los encabezados, se proponen tres criterios: Conservador: Este criterio considera la peor condici´on para ambos encabezados, asign´andole un tama˜ no de 60 bytes a cada uno. Moderado: Este criterio asume que el encabezado IP tiene un tama˜ no m´aximo de 60 bytes y el encabezado TCP tiene un tama˜ no m´ınimo de 20 bytes. 2

No se incluye el encabezado TCP.

29

Cap´ıtulo 3. Protocolo TCP

Optimista: Este criterio considera la mejor situaci´on posible, esto supone un tama˜ no m´ınimo de 20 bytes para ambos encabezados. Para obtener un buen rendimiento en la transferencia de datos es necesario conocer el MTU3 , de esta forma se puede obtener el mejor valor posible para MSS. Logrando as´ı un buen desempe˜ no en la transmisi´on de datos.

3.4.2.

Redimensionamiento de ventana

Esta opci´on indica el tama˜ no de la ventana del receptor. En estricto rigor, el redimensionamiento de ventana es una extensi´on del campo ((tama˜ no de ventana)) del encabezado TCP. Sin el uso de esta opci´on el m´aximo tama˜ no de ventana posible es de 216 bytes (64 Kbytes). Esto claramente es una limitaci´on en redes con caracter´ısticas de gran ancho de banda y altas latencias, ya que al enviar peque˜ nas cantidades de datos (64 Kbytes) no se utiliza todo el ancho de banda disponible, y producto del elevado RTT (((Round-Trip Time))) el acuse de recibo que permite el env´ıo de m´as datos, demora en llegar. Como resultado de esto se obtiene una tasa de transferencia muy pobre. El redimensionamiento de ventana se negocia al iniciarse la conexi´on TCP, y se env´ıa en un segmento donde el bit SYN est´a activado y el bit ACK desactivado. El tama˜ no m´aximo que puede tener un segmento de datos es de 230 bytes. Por lo tanto, al usar la opci´on de redimensionamiento de ventana se usan como m´aximo 30 bits, los cuales incluyen 16 bits del campo ((tama˜ no de ventana)), y el aporte realizado por el campo ((opciones TCP)) que es de 14 bits. Si el campo ((opciones TCP)) excede los 14 bits, se produce un mensaje de error y se usan 14 bits por omisi´on. 30 [bits] = 16 [bits] de ((tama˜ no de ventana)) + 14 [bits] de ((opciones TCP)) (3.2) As´ı la opci´on de redimensionamiento de ventana nos permite usar un m´aximo de 230 bytes de tama˜ no de ventana, ayudando a TCP en la adaptaci´on a redes con gran ancho de banda y altas latencias, ya que permite enviar una mayor cantidad de datos al vuelo. Un ejemplo de la ventaja del uso de esta opci´on se puede ver en la figura 3.7. En un enlace de alta latencia y gran ancho de banda, se usa un tama˜ no de ventana de 64 Kbytes, vease figura 3.7a. Debido a esto, los paquetes tardan en llegar a su destino (host B). La alta latencia tiene como efecto que el host A detenga la transmisi´on de datos, puesto que ha enviado 64 Kbytes. En t = 4, el host B recibe los datos y env´ıa el acuse de recibo al host A de forma que pueda continuar enviando datos, 3

Un receptor puede utilizar distintas t´ecnicas para obtener el MTU, una de estas t´ecnicas es la conocida como ((Path MTU Discovery)).

30

Cap´ıtulo 3. Protocolo TCP

pero el acuse de recibo llegar´a aproximadamente en t = 6. Esto implica que el host A estar´a en espera aproximadamente desde t = 1 a t = 6. Como resultado de esto, si fuese necesario transferir una gran cantidad de datos el tiempo total ser´ıa extremadamente grande.

3.7a. Ventana de 64 kb

3.7b. Ventana de 256 kb

Figura 3.7: Comparaci´ on del uso de opci´ on de redimensionamiento de ventana.

Con el uso del redimensionamiento de ventana, se incrementa el tama˜ no a 256 Kbytes, v´ease figura 3.7b. Esto produce una mayor cantidad de datos para la transferencia, de manera que en t = 1, cuando el host B ha comenzado a recibir los primeros paquetes, el host A a´ un continua enviando los datos correspondientes a la primera ventana de 256 Kbytes. En t = 2, el host B env´ıa el acuse de recibo al host A, que a´ un continua enviando datos. As´ı el host A recibir´a el acuse de recibo antes de terminar de enviar los datos que corresponden a la primera ventana, por lo tanto, continuar´a con enviando datos

31

Cap´ıtulo 3. Protocolo TCP

correspondientes a la segunda ventana, sin detenerse hasta que arribe otro acuse de recibo desde el host B. La diferencia que se produce al aumentar el tama˜ no de ventana se hace evidente, ya que si fuese necesario tambi´en transferir una gran cantidad de datos, el tiempo de espera es casi nulo, de manera tal que el rendimiento se eleva considerablemente.

3.4.3.

Marca de tiempo

Puesto que cada red tiene caracter´ısticas de latencia u ´nicas, TCP tiene que adaptarse a dichas caracter´ısticas con idea de establecer umbrales de tiempo precisos para los temporizadores de acuse de recibo. Las redes de area local (LAN) sufren normalmente tiempos de latencia muy bajos, y as´ı TCP podr´a usar valores bajos para los temporizadores de acuse de recibo. Si un segmento no es reconocido (acusado) r´apidamente, un emisor puede retransmitir r´apidamente los datos en cuesti´on, minimizando as´ı el ancho de banda perdido y el retraso. Por el contrario, usar un umbral bajo en una red de area extensa (WAN) causar´a problemas simplemente porque los temporizadores de acuse de recibo expirar´an antes de que los datos alcancen su destino. De esta manera, para que TCP pueda establecer con exactitud el umbral de los temporizadores para un circuito virtual, tiene que medir el RTT medio para varios segmentos. Finalmente, tiene que monitorear otros segmentos a lo largo de la duraci´on de la conexi´on para mantenerse al d´ıa de los cambios producidos en la red. Para solucionar estos problemas, TCP usa la opci´on ((Timestamp)). Esta opci´on proporciona a TCP un mecanismo para calcular el RTT por cada n´ umero de acuse de recibo. Por cada segmento y acuse de recibo enviados se registra el momento de env´ıo en el campo de opciones ((Timestamp)). De esta manera, TCP puede obtener un valor aproximado del RTT. Esta opci´on debe enviarse al iniciarse la conexi´on TCP, donde el bit SYN debe estar activo y el bit ACK no. La opci´on ((Timestamp)) se compone de los campos ((Timestamp Echo)) y ((Timestamp Reply)), de los cuales el campo de respuesta es siempre puesto a cero por el emisor y completado por el receptor, despu´es de lo cual es envi´ado de vuelta al emisor original. Ambos campos del Timestamp tiene 4 bytes de largo.

3.4.4.

Acuse de recibo selectivo

En determinadas circunstancias el protocolo TCP puede experimentar m´ ultiples p´erdidas de paquetes de datos en una ventana. Con la limitada informaci´on que se dispone de los acuses de recibo acumulativos, un emisor TCP s´olo puede enterarse de un u ´nico paquete perdido por cada RTT. Un emisor agresivo podr´ıa optar por

32

Cap´ıtulo 3. Protocolo TCP

retransmitir paquetes tempranamente, cuando estos segmentos ya podr´ıan haber sido exitosamente recibidos. Para mejorar esta limitaci´on se implement´o la opci´on de Acuse de Recibo Selectivo (SACK). Esta opci´on altera el comportamiento de acuse de recibo de TCP. La extensi´on de acuse de recibo selectivo (SACK) emplea dos opciones. La primera es la opci´on de habilitaci´on ((SACK-permitted)) y la segunda es la opci´on ((SACK)). SACK-permitted: Esta opci´on se env´ıa s´olo en un segmento SYN, y le indica a TCP que puede emplear la opci´on ((SACK)) durante la conexi´on. SACK: Esta opci´on puede ser enviada durante una conexi´on establecida una vez se ha dado permiso mediante ((SACK-permitted)). La opci´on SACK es enviada por un receptor para informar al emisor de los bloques de datos no continuos que se han recibido correctamente. En base a esta informaci´on el emisor es capaz de mandar s´olo los datos que faltan en el receptor para completar la transferencia.

3.5.

Control de congesti´ on

El m´etodo utilizado por TCP para control de la congesti´on est´a basado en la regulaci´on del tr´afico inyectado a la red. Esto supone que implementa funciones que le permiten estudiar cu´ando es posible enviar m´as tr´afico por el enlace, y cuando se ha superado la capacidad del mismo y se debe disminuir la carga. TCP implementa diferentes algoritmos para realizar el control de congesti´on, dentro de los m´as importantes est´an: Arranque lento ((slow start)). Prevenci´on de congesti´on ((congestion avoidance)). Transmisi´on r´apida ((fast transmit)). Recuperaci´on r´apida ((fast recovery)).

3.5.1.

Arranque lento

El arranque lento (slow start) es uno de los algoritmos usados por TCP para controlar la cantidad de tr´afico inyectado a la red. Arranque lento entra en funcionamiento una vez establecida la conexi´on. Para ello cuenta con tres variables de estado de TCP, estas son:

33

Cap´ıtulo 3. Protocolo TCP

Cwnd : Ventana de congesti´on (((congestion window))). Evoluciona en funci´on de las condiciones de congesti´on de la red y limita la cantidad de datos sin haber recibido acuse de recibo. Rwnd : Ventana anunciada por el receptor (((receiver’s advertised window ))). Indica la cantidad de datos que el receptor puede recibir. Ssthresh: Umbral del arranque lento (((slow start threshold))). Variable usada para saber en qu´e fase del control de congesti´on se encuentra el emisor. Si cwnd tiene un valor inferior a ssthresh indica que los datos deben enviarse usando el algoritmo de arranque lento. Si el valor es superior, se debe usar el algoritmo de prevenci´on de congesti´on. Al inicio de una conexi´on, se desconoce completamente el nivel de congesti´on de la red. As´ı mediante el uso del algoritmo de arranque lento, TCP puede probar y conocer la capacidad de la red, evitando congestionar la red. El valor inicial de la ventana cwnd, conocida como ventana inicial (IW, initial window ) se fija en el tama˜ no m´aximo de segmento del emisor (SMSS). Este valor est´a basado en el tama˜ no m´aximo de segmento del receptor y del MTU definido durante el inicio de la conexi´on. A continuaci´on, el emisor entra en el modo de arranque lento. En arranque lento, el emisor env´ıa un solo segmento de datos, llenando as´ı la ventana permitida inicialmente. Entonces, el emisor espera por el acuse de recibo correspondiente. Cuando el acuse de recibo llega, el emisor incrementa su ventana aumentando cwnd en un SMSS. El emisor ahora es capaz de transmitir dos segmentos. Esto produce que la ventana se llene nuevamente, por lo tanto, el emisor debe esperar por los acuses de recibo de los segmentos enviados. Cuando se reciben los acuses de recibo se vuelve a incrementar cwnd en un SMSS por cada acuse de recibo, de esta forma cwnd se duplica nuevamente. El efecto de este algoritmo es que la tasa de env´ıo de datos en el emisor, se duplica exponencialmente cada RTT. Es claro que esta situaci´on (aumento de cwnd) no puede sostenerse indefinidamente. El fin de este proceso se produce cuando se detecta congesti´on: esto ocurre cuando la ventana de congesti´on (cwnd) supera a rwnd, ssthresh o cuando se detecta la p´erdida de un paquete. El valor inicial de ssthresh se fija lo m´as alto posible, generalmente igual a rwnd. Sin embargo, cuando se observa congesti´on, ssthresh se disminuye a la mitad del tama˜ no actual, esto le proporciona a TCP un punto de referencia, para anticipar el inicio de congestiones futuras. En la figura 3.8 se observa el comportamiento de TCP en la fase de arranque lento. Se puede apreciar claramente la forma exponencial de la curva, mientras cwnd

34

Cap´ıtulo 3. Protocolo TCP

es menor que ssthresh, que es el tiempo de funcionamiento del algoritmo. Un aspecto importante en busca de un mejor desempe˜ no del algoritmo de arranque lento, en redes de alta velocidad, es la elecci´on de la ventana inicial (IW), en general, un segmento. Pruebas indican que m´as de cuatro segmentos como ventana inicial pueden permitir sesiones m´as eficientes [1]. Por ejemplo, en el caso del tr´afico HTTP se tiene un promedio de 17 segmentos por transferencia de datos. El uso de arranque lento, con una ventana inicial de un segmento, toma cinco intervalos RTT para transmitir todos los datos. En cambio, usando una ventana inicial de cuatro segmentos, se disminuye a tres intervalos RTT. Finalmente, una vez terminada la etapa de arranque lento, TCP entra en la etapa conocida como prevenci´on de congesti´on (congestion avoidance).

Figura 3.8: Compartamiento de TCP, usando algoritmo arranque lento y prevenci´ on de congesti´ on [13].

3.5.2.

Prevenci´ on de congesti´ on

Como ya se ha mencionado, el algoritmo de prevenci´on de congesti´on entra en funcionamiento cuando culmina el arranque lento. En este punto, el emisor incrementa el valor de cwnd de forma lineal por cada acuse de recibo no duplicado recibido.

35

Cap´ıtulo 3. Protocolo TCP

La actualizaci´on de cwnd se realiza de acuerdo a la f´ormula siguiente: cwnd = cwnd + SM SS ·

SM SS cwnd

(3.3)

Como resultado de esto, cwnd aumenta aproximadamente en un SMSS por cada RTT, de esta manera se logra un acercamiento lento a la m´axima capacidad de transferencia de la red. Cuando el emisor detecta la p´erdida de un segmento, a partir del temporizador de retransmisi´on, el valor de ssthresh de actualizarse seg´ un la ecuaci´on 3.4. FS ssthresh = max , 2 · SM SS 2 



(3.4)

Donde FS (flight size) es la cantidad de datos enviados, que todav´ıa no han sido confirmado con un acuse de recibo. Al mismo tiempo, cwnd toma un valor que no puede ser mayor que LW (loss window ), el cual equivale a un segmento, sin tener en cuenta el valor de la ventana inicial. Despu´es de retransmitir el segmento perdido, el emisor usa el algoritmo de arranque lento, para incrementar cwnd desde LW hasta el nuevo valor de ssthresh. En este punto, la prevenci´on de congesti´on entrar´a en acci´on nuevamente. De forma similar al arranque lento, en la figura 3.8 se observa el comportamiento de TCP en la fase de prevenci´on de congesti´on, donde se puede observar que la curva una vez superado el valor de ssthresh toma un crecimiento lineal.

3.5.3.

Retransmisi´ on r´ apida y recuperaci´ on r´ apida

La descripci´on de ambos algoritmos se realiza en forma conjunta, ya que en la practica ambos algoritmos se implementan y trabajan juntos. El algoritmo de retransmisi´on r´apida tiene como objetivo detectar y reparar p´erdidas de segmentos. En cambio, el algoritmo de recuperaci´on r´apida busca evitar que la transmisi´on comience desde el principio, es decir, evitar que se vuelva al fase de arranque lento. En ciertas circunstancias, TCP puede recibir segmentos desordenados. Si el receptor TCP recibe un segmento fuera de orden, debe enviar inmediatamente un acuse de recibo duplicado. Con ello se busca informar al emisor el n´ umero de secuencia esperado. Las conclusiones a las que puede llegar el emisor ante la llegada de acuses de recibo duplicados pueden ser varias. Puede concluir que est´a ante la presencia de segmentos descartados. Que por razones de tr´ansito en la red, los segmentos est´an llegando en desorden al receptor.

36

Cap´ıtulo 3. Protocolo TCP

Que ocurre por duplicaci´on de los segmentos o de los acuses de recibo en la propia red. Adem´as, el receptor debe enviar inmediatamente un acuse de recibo cuando el segmento entrante completa todo o una parte del espacio de la secuencia, de forma de colaborar con el emisor con m´as informaci´on. El algoritmo emplea la recepci´on de tres acuses de recibo duplicados (cuatro acuses de recibo id´enticos sin la llegada de cualquier otro segmento) para concluir que un segmento se ha perdido. Una vez confirmada la p´erdida del segmento, el emisor env´ıa el segmento perdido sin esperar que expire el timer de retransmisi´on, ssthresh es calculado nuevamente de acuerdo a la ecuaci´on 3.4 y cwnd se obtiene de acuerdo a la ecuaci´on 3.5, de esta forma se hace crecer cwnd en la cantidad de segmentos que abandonaron la red. cwnd = ssthresh + 3 · SM SS

(3.5)

En este instante, el algoritmo retransmisi´on r´apida gobierna la transmisi´on mientras no se reciban nuevos acuses de recibo duplicados. Si el nuevo valor de cwnd y rwnd lo permiten, se transmite un nuevo segmento y ante la llegada del siguiente acuse de recibo reconociendo los nuevos datos, se reduce cwnd al nuevo valor de ssthresh, obtenido seg´ un la ecuaci´on 3.4. Como resultado de esto, la tasa de transmisi´on se reduce a la mitad y se comienza un nuevo ciclo de prevenci´on de congesti´on. En la figura 3.9, se puede apreciar el funcionamiento de ambos algoritmos, donde se puede ver claramente la evoluci´on de cwnd y ssthresh, tal y como ha sido descrita.

3.6.

Implementaciones de TCP

A lo largo del tiempo, TCP ha evolucionado en busca de un mejor rendimiento, producto de esto han aparecido diferentes versiones. Sin embargo, pese a las diferencias entre ellas, la compatibilidad es total. En esta secci´on se mencionan algunas de las diferentes implementaciones que existen del stack de TCP. Algunas de versiones de TCP son: TCP Tahoe. TCP Reno. TCP New Reno. TCP Vegas.

37

Cap´ıtulo 3. Protocolo TCP

Figura 3.9: Comportamiento de TCP, usando retransmisi´ on r´ apida y recuperaci´ on r´ apida [13].

HighSpeed TCP. Scalable TCP. BIC-TCP. CUBIC TCP H-TCP. Fast TCP. A continuaci´on se explican dos de las implementaciones mencionadas recientemente, estas son BIC-TCP y CUBIC TCP. Estas dos implementaciones son las que vienen por omisi´on en Linux.

3.6.1.

BIC-TCP

BIC-TCP es un variante de TCP, dise˜ nado para redes de alta velocidad y alta latencia. BIC que significa ((Binary Increase Congestion)) esta dise˜ nado b´asicamente

38

Cap´ıtulo 3. Protocolo TCP

para cumplir con los siguientes criterios: Equidad del RTT. Amigabilidad de TCP. Escalabilidad. Equidad y convergencia. La principal caracter´ıstica de BIC-TCP es su funci´on de aumento de ventana. Cuando existen p´erdidas de paquetes, la ventana es reducida por un factor multiplicativo (β), asegurando as´ı una r´apida reacci´on a las p´erdidas. El tama˜ no de la ventana justo antes de la p´erdida de paquetes es ajustado como el valor m´aximo (Wmax ), mientras el tama˜ no de ventana inmediatamente producida la reducci´on es ajustada como el valor m´ınimo (Wmin ). Luego BIC realiza una b´ usqueda binaria incremental entre ambos par´ametros, que consiste en saltar al valor medio (Wavg ) de Wmin y Wmax . Existen casos en que el incrementar la ventana desde el valor m´ınimo actual al valor medio puede agregar mucha carga a la red, por lo tanto, si la diferencia entre el valor medio y el valor m´ınimo (Wavg − Wmin ) es mayor que una constante determinada, llamada m´aximo incremento (Smax ), en vez de aumentar la ventana hacia ese valor medio, se incrementa en Smax , luego la nueva ventana tiene un valor de Wmin + Smax . Si este nuevo valor de ventana no produce p´erdidas de paquetes, entonces este valor se convierte en el nuevo m´ınimo (Wmin ). Por otro lado si este nuevo valor si produce p´erdidas de paquetes, entonces este valor pasa a convertirse en el nuevo valor m´aximo (Wmax ). As´ı el proceso vuelve a repetirse y continua hasta que la diferencia entre el valor m´ınimo y el valor medio sea menor que una constante determinada (Smin ). En este punto la ventana actual toma el valor m´aximo, el cual fue asignado cuando se presentaron p´erdidas de paquetes. Hasta este momento la funci´on de aumento de ventana se parece a una funci´on linear (incremento aditivo), seguida por una funci´on logar´ıtmica (b´ usqueda binaria incremental). Cuando se haya alcanzado el valor m´aximo para el valor de ventana, es necesario asignar un nuevo m´aximo; a diferencia del m´aximo anterior, ´este es desconocido. El nuevo m´aximo asignado es una constante predeterminada de gran valor. Como resultado de esto, se tiene un valor m´aximo muy alejado, por lo que se deber´ıa entrar nuevamente a la etapa linear (incremento aditivo) de BIC. En lugar de realizar el incremento aditivo, se realiza un comienzo lento (((Slow Start))). Esta etapa se conoce como ((max probing)) (prueba o b´ usqueda del m´aximo). El procedimiento seguido consiste en incrementar la ventada actual (W ) de forma exponencial cada RTT hasta alcanzar el valor de W +Smax , es decir, la ventana crece de la siguiente forma: W +1,

39

Cap´ıtulo 3. Protocolo TCP

W + 2, W + 4,....,W + Smax . Si se alcanza el valor determinado como m´aximo, y no ocurren p´erdidas de paquetes, significa que el nuevo m´aximo se encuentra m´as lejos. Luego, para aumentar la velocidad de b´ usqueda del nuevo valor m´aximo, se cambia del ((Slow Start)) al incremento aditivo, y as´ı se contin´ ua hasta encontrar el nuevo m´aximo, o sea, hasta presentar nuevamente p´erdida de paquetes.

Figura 3.10. Funci´ on de crecimiento de ventana de BIC [38].

Como se puede observar en la figura 3.10, la b´ usqueda del nuevo m´aximo (((max probing))) tiene una funci´on de crecimiento de ventana que corresponde a la inversa de las dos etapas anteriores juntas (incremento aditivo y busqueda binaria), ya que al inicio usa una funci´on de crecimiento de ventana exponencial (((Slow Start))), y luego cambia a una funci´on de crecimiento linear (incremento aditivo).

3.6.2.

CUBIC TCP

CUBIC es otra variante de TCP, dise˜ nada a partir de BIC. CUBIC se desarroll´o para mejorar la funci´on de crecimiento de ventana de BIC, ya que en casos como bajo RTT o baja velocidad de transferencia, esta funci´on puede ser muy agresiva para TCP. CUBIC presenta tres nuevas caracter´ısticas a lo que era BIC. Nueva funci´on de crecimiento de ventana. Nuevo modo TCP-friendly. Baja utilizaci´on de la detecci´on.

40

Cap´ıtulo 3. Protocolo TCP

La principal caracter´ısticas de CUBIC, tal como lo indica su nombre, es la nueva funci´on de crecimiento de ventana, la cual es una funci´on c´ ubica similar a la de BIC. Esta nueva funci´on de crecimiento de ventana se puede expresar como se indica en la ecuaci´on 3.6. Wcubic = C(t − K)3 + Wmax (3.6) Donde C es un factor determinado; t es el tiempo transcurrido desde la reducci´on de ventana; Wmax , al igual que BIC, corresponde al valor de la ventana justo q 3 antes de la reducci´on de esta misma; y K = Wmax β/C, donde β es la constante multiplicativa aplicada durante la reducci´on de ventana.

Figura 3.11. Funci´ on de crecimiento de ventana de CUBIC [28].

En la figura 3.11 se muestra la funci´on de crecimiento de CUBIC. En ella se puede apreciar que al ocurrir una p´erdida de paquetes (reducci´on de ventana), la ventana crece r´apidamente, pero al acercarse a Wmax , ´esta disminuye su crecimiento. Al alcanzar el valor m´aximo de ventana, el incremento se hace casi cero. A continuaci´on, CUBIC entra en la parte conocida como ((max probing)); para ello comienza a incrementar la ventana lentamente, acelerando este crecimiento mientras m´as se aleja de Wmax . De esta forma, el nulo crecimiento de la ventana alrededor de Wmax mejora la estabilidad, y el incremento del flujo al alejarse de Wmax , asegura la escalabilidad.

41

Cap´ıtulo

4 Link aggregation

El siguiente cap´ıtulo explica en que consiste el link aggregation, se mencionan sus aplicaciones m´as comunes y el por qu´e de su desarrollo. Adem´as, se explica brevemente como se implementa, funciona y configura el link aggregation en Linux. Link aggregation o est´andar IEEE 802.3ad es un m´etodo para combinar enlaces f´ısicos de red (ethernet) en s´olo un enlace l´ogico con el fin de aumentar las velocidades de transferencia de datos. Link aggregation adem´as provee balanceo de carga, es decir, las comunicaciones son distribuidas a trav´es de los enlaces que componen el enlace l´ogico. De esta forma se trata de evitar que los enlaces f´ısicos sean sobrecargados. Link aggregation provee importantes beneficios, como son: Enlace de alta disponibilidad: Previene la falla de cualquier enlace f´ısico. La p´erdida de un enlace f´ısico en un enlace l´ogico reduce la capacidad pero la comunicaci´on y el flujo de datos se mantiene ininterrumpido. Incremento de la capacidad del enlace: El desempe˜ no se mejora debido a que la capacidad de un enlace l´ogico es mayor que cada enlace f´ısico por s´ı s´olo. Los valores est´andares de la capacidad de los enlaces son de 10, 100 y 1000 Mbps. Si un enlace requiere un capacidad intermedia o mayor, se puede lograr mediante el uso de link aggregation. Reutilizaci´ on del hardware existente: Si un enlace requiere mayor capacidad, generalmente existen dos posibilidades: Reemplazar el enlace por alg´ un dispositivo m´as moderno o usar link aggregation. Cuando se reemplaza un enlace, esto t´ıpicamente ocurre en factores de diez (10, 100 y 1000 Mbps, y 10 Gbps), y en muchos casos, no se puede tomar ventaja del aumento de velocidad. Adem´as,

42

Cap´ıtulo 4. Link aggregation

los costos asociados a una actualizaci´on casi siempre son altos. Por lo tanto, el uso de link aggregation evita la actualizaci´on innecesaria de hardware.

4.1.

Tipos de link aggregation

El est´andar 802.3ad menciona algunas situaciones t´ıpicas donde se usa link aggregation (ver figura 4.1. Algunas de estas son:

Figura 4.1. Topolog´ıas usadas con link aggregation [32].

Conexiones switch a switch: Esta topolog´ıa agrupa varios puertos de ambos switch en un s´olo enlace agregado (l´ogico). Mediante el uso de estos m´ ultiples enlaces, es posible lograr altas velocidades de transferencia sin la necesidad de actualizar el hardware. Conexi´ on switch a estaci´ on (servidor o router ): La mayor´ıa de los servidores son capaces de saturar un enlace de 100 o 1000 Mbps, debido a la demanda de los servicios disponibles hoy (web, mail, ftp, netbios, etc). El uso de link aggregation hace posible aumentar el desempe˜ no de un servidor, adem´as de proveer redundancia ante posibles fallas de los dispositivos de red.

43

Cap´ıtulo 4. Link aggregation

Estaci´ on a estaci´ on: Similar al anterior, el uso de un enlace l´ogico entre dos servidores puede ser beneficioso para aplicaciones de multiprocesamiento, adem´as de proveer redundancia en la comunicaci´on entre los servidores. Link aggregation es conocido adem´as por otros t´erminos. Esto se debe a que cada entidad, organizaci´on u empresa ha bautizado esta tecnolog´ıa con sus propios nombres. Algunas t´erminos con los cuales se conoce a link aggregation son: Etherchannel. Port trunking o trunking. Channel bonding. Link aggregate group (LAG). NIC Teaming.

4.2.

Channel bonding

Channel Bonding es el t´ermino con el cual se conoce en Linux al link aggregation. Channel Bonding, en adelante bonding, est´a implementado en Linux como un driver del kernel, el cual puede ser activado como m´odulo del kernel o compilando el driver dentro del kernel, siendo la primera la opci´on recomendada por los desarrolladores de Linux, ya que esta es la u ´nica forma de pasarle par´ametros al kernel o configurar m´as de una interfaz como bonding. El driver bonding fue implementado originalmente por Donald Becker, como parte de su desarrollo del cluster ((Beowulf)). Su ubicaci´on dentro del ´arbol de directorios del kernel es linux/driver/net/bonding. Linux, al utilizar bonding, denomina el enlace l´ogico como enlace maestro. Este enlace maestro es designado como bondX en la carpeta de dispositivos /dev, donde X corresponde al n´ umero de dispositivos maestros presentes en el sistema (bond0, bond1, bond2, etc). Los enlaces f´ısicos que componen el enlace maestro se conocen (sin mucho misterio) como enlaces esclavos. Para un enlace maestro se pueden crear cuantos enlaces se quieran. En el caso de los enlaces esclavos, ´estos est´an limitados por el n´ umero de interfaces que Linux puede soportar y/o el n´ umero de tarjetas de red que se pueden conectar al computador. En la figura 4.2 se muestra un esquema como funciona el driver bonding en la arquitectura de red de Linux. Se puede observar que al usar bonding se agrega una capa extra a la arquitectura normal de red. Bonding provee diferentes opciones para su configuraci´on. Algunas de las opciones m´as importantes se listan a continuaci´on:

44

Cap´ıtulo 4. Link aggregation

Figura 4.2. Arquitectura de red en Linux con channel bonding

downdelay: Tiempo, en milisegundos , que se debe esperar para deshabilitar un enlace esclavo despu´es de una falla de este. max bonds: Especifica el n´ umero m´aximo de dispositivos bonding que se pueden crear. miimon: Especifica la frecuencia, en milisegundos, de monitoreo de la interfaz de red MII (Media Independient Interface), es decir, cu´an seguido se debe verificar el estado de cada uno de los enlaces esclavos en la b´ usqueda de fallas de enlace. mode: Especifica una de las pol´ıticas de bonding disponibles para que pueda ser utilizado por el enlace maestro. Las pol´ıticas actualmente disponibles son: balance-rr: Pol´ıtica ((round robin)), en ella se transmiten secuencialmente los paquetes desde el primer enlace esclavo hasta el u ´ltimo. active-backup: Pol´ıtica donde s´olo un enlace esclavo est´a activo. Otro enlace esclavo se activar´a s´olo si el enlace activo actual falla. balance-xor: Pol´ıtica ((XOR)), los datos se transmiten basados en la actual pol´ıtica de transmisi´on hash. La pol´ıtica de transmisi´on hash por omisi´on consiste en: (Dir.M ACorigen ⊕ Dir.M ACdestino ) %N umeroenlaces esclavos

(4.1)

Otras pol´ıticas de transmisi´on hash se pueden seleccionar mediante la opci´on xmit hash policy,

45

Cap´ıtulo 4. Link aggregation

broadcast: Transmite todos los datos por todas las interfaces esclavas. 802.3ad: Crea grupos de link aggregation que comparten la misma velocidad. Todos los enlaces esclavos se utilizan de acuerdo al est´andar 802.3ad. balance-tlb: Pol´ıtica de transmisi´on adaptativa de balanceo de carga. El tr´afico saliente es distribuido de acuerdo a la carga actual en cada enlace esclavo. balance-alb: Pol´ıtica de balanceo de carga adaptativo. Similar a modo anterior con la salvedad que incorpora balanceo de carga a tr´afico entrante. updelay: Tiempo, en milisegundos que se debe esperar para habilitar un enlace esclavo despu´es de que una recuperaci´on de su enlace haya sido detectado.

4.2.1.

Configuraci´ on de bonding en Linux

En esta secci´on se explica como habilitar y configurar el driver bonding en Linux. Como ya se ha mencionado bonding se puede habilitar de dos formas, en este caso, se trabajar´a con ´el como m´odulo del kernel por las ventajas ya mencionadas. Primero es necesario cargar el modulo en el kernel, para ello utilizamos el comando modprobe: # modprobe bonding Al insertar el m´odulo en el kernel este crear´a un directorio en /proc/net/bonding y un archivo por cada interfaz l´ogica (bondX) exista, por ej. /proc/net/bonding/bond0. Este archivo proporciona informaci´on del m´odulo, tal como: versi´on del driver, opciones seleccionadas e interfaces esclavas. Como el m´odulo se habilit´o sin ning´ un par´ametro y como las interfaces esclavas a´ un no han sido especificadas, la informaci´on proporcionada corresponde s´olo a los valores por defecto del driver. Para ver la informaci´on, basta con escribir en la shell: # cat /proc/net/bonding/bond0 Ethernet Channel Bonding Driver: v3.1.1 (September 26, 2006) Bonding Mode: load balancing (round-robin) MII Status: down MII Polling Interval (ms): 0 Up Delay (ms): 0 Down Delay (ms): 0 Para modificar las opciones del m´odulo, basta con pasarle como par´ametro al m´odulo el valor deseado de las opciones. La forma de hacerlo en la shell es la siguiente:

46

Cap´ıtulo 4. Link aggregation

# modprobe bonding mode=active-backup miimon=100 Una vez cargado el m´odulo con las opciones deseadas, es necesario agregar las interfaces esclavas, para ello se utiliza el programa ifenslave. Para agregar las interfaces esclavas a la interfaz maestra se deben realizar los siguientes pasos: # ifconfig bond0 up # ifenslave bond0 eth1 eth2 Al revisar el archivo /proc/net/bonding/bond0 se puede observar que la informaci´on provista ha aumentado. # cat /proc/net/bonding/bond0 Ethernet Channel Bonding Driver: v3.0.3 (March 23, 2006) Bonding Mode: fault-tolerance (active-backup) Primary Slave: None Currently Active Slave: eth2 MII Status: up MII Polling Interval (ms): 100 Up Delay (ms): 0 Down Delay (ms): 0 Slave Interface: eth1 MII Status: up Link Failure Count: 0 Permanent HW addr: 00:04:23:c2:31:54 Slave Interface: eth2 MII Status: up Link Failure Count: 0 Permanent HW addr: 00:14:38:b8:b7:cb De esta forma tenemos configurado y funcionando nuestro driver bonding en Linux. La configuraci´on anterior se puede programar para que se ejecute durante el inicio del sistema (boot), la forma de realizar esta configuraci´on var´ıa de una distribuci´on a otra.

47

Cap´ıtulo

5 Resultados

En el siguiente cap´ıtulo se presentan experimentos realizados para mostrar c´omo ciertas optimizaciones al stack TCP/IP de Linux afectan su desempe˜ no.

5.1.

Definici´ on de los experimentos

El objetivo de los experimentos es realizar ciertas modificaciones a Linux, y observar si ´estas producen mejoras en el desempe˜ no de la implementaci´on de red. En particular se desea observar el rendimiento de TCP/IP: al aumentar el n´ umero de interfaces de red, mediante bonding; y al usar jumbo frames. Adem´as, se pretende ´ observar c´omo ciertos factores afectan a la transferencia de los datos. Estos son: el tama˜ no del buffer de datos, la ventana de congesti´on de TCP y el n´ umero de flujos TCP.

5.2.

Hardware disponible

Para realizar los experimentos es necesario contar con hardware acorde a las necesidades. En esta secci´on, se hace un resumen de las piezas m´as importantes del hardware disponible para los experimentos. Para realizar las experiencias se necesitan dos computadores, un switch y cables para la interconexi´on. Actualmente se dispone de dos m´aquinas ((HP Proliant ML110 G2)), algunas de sus caracter´ısticas son: Procesador: Intel Pentium 4 de 3.20 GHz con HyperThreading.

48

Cap´ıtulo 5. Resultados

RAM: Dos m´odulos DIMM DDR Kingston de 512 MBytes, para un total de 1 Gbytes. Disco duro: Dos discos Seagate Cheetah SCSI de 36.7 Gbytes de 15000 RPM. Tarjeta de red: Tres tarjetas Intel PRO/1000 de 1 Gbps El switch con que se cuenta es: un Dell PowerConnect 2716 que soporta velocidades de hasta 1 Gbps y jumbo frames de hasta 9000 bytes. Finalmente los cables de red usados son NEXXT categor´ıa 5E.

5.3.

Software disponible

Adem´as de contar con el hardware necesario para realizar las pruebas, es necesario contar con el software id´oneo para las experiencias. El software se puede dividir en dos: el software general y el software espec´ıfico. El software general consiste en el sistema operativo, el cual es el que permite la utilizaci´on del hardware disponible. El sistema operativo elegido es GNU/Linux, debido a la gran comunidad que hay detr´as de ´el, y a la gran variedad de hardware soportado, lo cual hace que corra con ventaja frente a otros sistemas operativos tipo Unix, como FreeBSD, NetBSD, Solaris, etc. La versi´on del kernel utilizada es la 2.6.19. El software espec´ıfico se refiere al software usado para realizar las experiencias de laboratorio. En nuestro caso, el software elegido para realizar las pruebas de red es iperf en su versi´on 2.0.2 y NetPIPE en su versi´on 4.x. Adem´as para una peque˜ na prueba final se utiliz´o el sistema de archivos paralelo PVFS en su versi´on 2.6.3.

5.3.1.

Iperf

iperf es un software que permite medir el desempe˜ no de red de TCP o UDP. Su desarrollo est´a pensado como una alternativa m´as moderna a las cl´asicas herramientas, como ttcp, netperf, etc. Adem´as, iperf permite modificar varios par´ametros, tanto de TCP, como UDP. Algunas de estas caracter´ısticas que nos ofrece iperf y que son importantes para nuestro fin son: Modificaci´on del tama˜ no del buffer de datos. Modificaci´on del tama˜ no de la ventana de TCP. Uso de m´ ultiples flujos.

49

Cap´ıtulo 5. Resultados

Un ejemplo del funcionamiento de iperf se muestra en las figuras 5.1 y 5.2. En ellas se puede apreciar como iperf utiliza el modelo cliente-servidor para su funcionamiento, y como despliega las estad´ısticas e informaci´on en pantalla. [root@nodo_1 ~]# iperf -s -f m -----------------------------------------------------------Server listening on TCP port 5001 TCP window size: 0.08 MByte (default) -----------------------------------------------------------[ 4] local 152.74.20.201 port 5001 connected with 152.74.20.202 port 35198 [ 4] 0.0- 5.0 sec 864 MBytes 1449 Mbits/sec

Figura 5.1. iperf como servidor

[root@nodo_2 ~]# iperf -c 152.74.20.201 -t 5 -i 1 -f m -----------------------------------------------------------Client connecting to 152.74.20.201, TCP port 5001 TCP window size: 0.03 MByte (default) -----------------------------------------------------------[ 3] local 152.74.20.202 port 35198 connected with 152.74.20.201 port 5001 [ 3] 0.0- 1.0 sec 176 MBytes 1475 Mbits/sec [ 3] 1.0- 2.0 sec 168 MBytes 1411 Mbits/sec [ 3] 2.0- 3.0 sec 176 MBytes 1476 Mbits/sec [ 3] 3.0- 4.0 sec 173 MBytes 1453 Mbits/sec [ 3] 4.0- 5.0 sec 171 MBytes 1436 Mbits/sec [ 3] 0.0- 5.0 sec 864 MBytes 1450 Mbits/sec

Figura 5.2. iperf como cliente.

5.3.2.

NetPIPE

NetPIPE consiste en un herramienta de software que realiza simples pruebas de ping-pong, enviando mensajes entre dos nodos. Los mensajes enviados se incrementan en intervalos regulares con una leve perturbaci´on. NetPIPE produce un archivo de salida que contiene el tama˜ no del mensaje transferido, el desempe˜ no y el tiempo de transferencia del mensaje. Para usar NetPIPE con el protocolo TCP se debe usar el binario NPtcp. Un ejemplo del funcionamiento de NetPIPE con TCP se muestra en la figura 5.3. En

50

Cap´ıtulo 5. Resultados

ella se puede apreciar como NetPIPE despliega las estad´ısticas e informaci´on en pantalla. [root@nodo_2 ~]# NPtcp -H nphosts,1 [root@nodo_1 ~]# NPtcp -o salida.txt -H nphosts,0 -p 3 -l 1 -u 9 Send and receive buffers are 16384 and 87380 bytes Using a perturbation value of 3 Sending output to salida.txt Now starting the main loop 0: 1 bytes 5934 times --> 1: 2 bytes 6006 times --> 2: 3 bytes 5996 times --> 3: 4 bytes 4002 times --> 4: 6 bytes 5586 times --> 5: 8 bytes 3003 times --> The run has completed successfully

0.19 0.38 0.58 0.95 1.15 1.51

Mbps Mbps Mbps Mbps Mbps Mbps

in in in in in in

41.62 41.69 41.64 33.56 41.62 42.45

usec usec usec usec usec usec

Figura 5.3. NetPIPE como servidor (nodo 2) y cliente (nodo 1)

[root@nodo_2 ~]# cat nphosts 152.74.20.201 152.74.20.202

Figura 5.4. Contenido de archivo nphosts.

[root@nodo_2 ~]# cat salida.out 1 0.192203 0.17412204 2 0.383796 0.36330505 3 0.576310 0.53724392 4 0.953380 0.86190126 6 1.153178 1.05793651 8 1.507824 1.31048026

0.16026663 0.32055983 0.48071977 0.64274972 0.96091138 1.28042830

0.00004162 0.00004169 0.00004164 0.00003356 0.00004162 0.00004245

Figura 5.5. Contenido de archivo de salida (salida.txt).

En la figura 5.4 se muestra el contenido del archivo nphosts, el cual es pasado como par´ametro a NetPIPE. Su contenido consiste en las IPs de los nodos involucrados en la medici´on. A continuaci´on, en la figura 5.5 se muestra el archivo de salida generado (salida.txt), el cual contiene las variables mencionadas anteriormente.

51

Cap´ıtulo 5. Resultados

5.3.3.

PVFS

El sistema de archivos paralelo ((Parallel Virtual File System)), es un sistema de archivos que permite a diferentes aplicaciones almacenar datos en servidores distribuidos en una red. PVFS ha tenido una gran aceptaci´on debido a su gran desempe˜ no al escribir archivos de gran tama˜ no, adem´as de su escalabilidad. La arquitectura de PVFS esta compuesta principalmente por tres componentes, estos son: Servidor de Metadatos: Es un nodo encargado de mantener y actualizar la informaci´on de los archivos y directorios que se almacenan en un sistema PVFS, tales como permisos, due˜ nos, fecha, etc. Servidor de Entrada/Salida (I/O): Es un nodo encargado de gestionar el almacenamiento y recuperaci´on de los datos en un sistema PVFS. Clientes: Es un nodo que nos permite acceder al sistema de archivos. Algunas de sus principales funciones son leer y escribir archivos, acceder a directorios, etc. Respecto a los tres componentes antes mencionados, cabe mencionar que se puede configurar PVFS para que funcione con tantos servidores como se desee, pudiendo haber varios tipos de servidores en un solo cluster. De esta forma se logra una caracter´ıstica importante de PVFS, como lo es la escalabilidad. Finalmente, debemos mencionar que las transmisi´on de los datos entre los nodos de PVFS se realiza mediante el protocolo TCP/IP.

5.4.

Experimentos

Una vez explicado lo que se desea hacer, ahora se proceder´a a explicar de forma detallada todas la experiencias realizadas.

5.4.1.

Efecto del MTU

Este experimento tiene como objetivo observar el comportamiento del desempe˜ no ante los cambios en el MTU/MSS. En Linux para realizar esto, basta con modificar el MTU, ya que seg´ un la ecuaci´on 3.1, al aumentar el MTU, aumentamos el MSS. Para esta experiencia usamos iperf para medir el desempe˜ no en un intervalo de tiempo determinado. El valor del MTU se var´ıa en tres valores: 1500, 3000 y 9000 Bytes; observando los posibles cambios en el desempe˜ no producto de la variaci´on del MTU. El comando espec´ıfico a ejecutar es:

52

Cap´ıtulo 5. Resultados

# iperf -c $IP_SERVER -i 1 -t $TIME -f m La primera parte de la experiencia consiste en realizar el procedimiento especificado con s´olo una interfaz de red. En la figura 5.6 se muestra el esquema de red usado.

Figura 5.6. Esquema de Red con una interfaz.

Como resultado se obtuvo el gr´afico mostrado en la figura 5.7. En ella se puede apreciar que cada vez que se aument´o el MTU, el desempe˜ no tambi´en aument´o.

Figura 5.7. Variaci´ on del throughput en el tiempo ante cambios en MTU.

53

Cap´ıtulo 5. Resultados

En la figura 5.8 se muestra un histograma de la variaci´on del desempe˜ no respecto a los tres valores de MTU dados. Los datos usados corresponden a los valores promedios del desempe˜ no durante un intervalo de tiempo determinado, en este caso, treinta segundos. En ella se puede corroborar como el desempe˜ no se incrementa al aumentar el MTU.

Figura 5.8. Variaci´ on del throughput ante cambios en el MTU.

La segunda parte del experimento, consiste en repetir el mismo procedimiento, utilizando dos interfaces de red por cada computador. En la figura 5.9 se muestra el esquema de red.

Figura 5.9. Esquema de Red con dos interfaces.

54

Cap´ıtulo 5. Resultados

El resultado obtenido para la variaci´on del desempe˜ no a trav´es del tiempo, se muestra en la figura 5.10. En ella se puede apreciar que tendencia se mantiene, es decir, al aumentar el MTU, el desempe˜ no aumenta, pero ahora presenta un estado mucho menos estable, en comparaci´on del experimento usando una interfaz por equipo.

Figura 5.10: Variaci´ on del throughput en el tiempo ante cambios en MTU, usando bonding.

Respecto a la figura 5.11, se observa el mismo comportamiento de la figura 5.8, pero la salvedad est´a en la valor del desempe˜ no, el cual presenta valores m´as altos que los obtenidos anteriormente. Pese a que los valores son mayores a los obtenidos usando s´olo una interfaz de red, la mejora no es tan significativa. En la tabla 5.1 se muestran los valores del desempe˜ no promedio y en la tabla 5.2 se muestran los mismos valores en porcentajes para una mejor interpretaci´on.

55

Cap´ıtulo 5. Resultados

Figura 5.11: Variaci´ on del throughput ante cambios en el MTU, usando bonding.

N´ umero de Interfaces 1 2

MTU 1500 MTU 3000 MTU 9000 (Mbps) (Mbps) (Mbps) 940 961 988 956 1048 1221

Tabla 5.1. Datos obtenidos en experimento de variaci´ on del MTU.

N´ umero de Interfaces 1 2

MTU 1500 MTU 3000 MTU 9000 ( %) ( %) ( %) 100 102.23 105.11 101.70 111.49 129.89

Tabla 5.2: Datos obtenidos en porcentaje, en experimento de variaci´ on del MTU

5.4.2.

Efecto del n´ umero de flujos

En esta experiencia, vamos a observar como afecta el n´ umero de flujos TCP, en una transferencia de datos; para ello, se har´a uso de iperf, el cual tiene la ventaja

56

Cap´ıtulo 5. Resultados

de que permite abrir cuantas conexiones simult´aneas como se desee. El procedimiento a seguir consiste en: Fijar el MTU; a partir de los resultados de la secci´on 5.4.1, se puede afirmar que el valor de MTU que mejores resultados entreg´o, en cuanto al desempe˜ no, fue 9000 bytes. Por lo tanto, en este experimento y en los siguientes el MTU tendr´a un valor de 9000 bytes. El siguiente paso consiste en ejecutar iperf, y sucesivamente ir aumentando el n´ umero de instancias de ella, es decir, ejecutar iperf y obtener los datos, luego ejecutar iperf dos veces y as´ı sucesivamente hasta llegar a diez. Por lo tanto, tendremos los datos de que valores alcanza el desempe˜ no usando de uno a diez flujos TCP. Finalmente, en este procedimiento se usar´a bonding, la primera usando dos interfaces de red, y la segunda con tres interfaces de red. En la figura 5.12 se muestra de forma simplificada como se ejecutan las instancias de iperf, para de esta forma, generar el rango de uno a diez flujos TCP. for i in ‘seq 1 10‘; do for j in ‘seq 1 $i‘; do iperf -c $IP_SERVER -i 1 -t $TIME -f m & done done

Figura 5.12. Script simplificado para generar rangos de flujos TCP.

En la figura 5.13 se muestra los resultados obtenidos. En ella se puede apreciar como evoluciona el desempe˜ no, el cual se va incrementando con cada adici´on de un flujo, hasta llegar a un punto en que se estabiliza. El crecimiento del desempe˜ no se estabiliza aproximadamente cuando el n´ umero de flujos llega a seis. Respecto al valor que alcanza el desempe˜ no, se observa que gracias al uso de varios flujos, el rendimiento de TCP mejora ostensiblemente, si comparamos los datos obtenidos en la secci´on 5.4.1.

57

Cap´ıtulo 5. Resultados

Figura 5.13: Evoluci´ on del throughput ante variaci´ on en el n´ umero de flujos TCP.

5.4.3.

Efecto del buffer de datos

En este experimento, se desea observar el comportamiento del desempe˜ no, frente a la variaci´on del buffer de datos. El procedimiento a seguir en esta experiencia consiste en: Al igual que en la experiencia anterior (secci´on 5.4.2), se fijar´a el MTU en 9000 bytes. Una vez fijado el MTU, es turno de fijar el n´ umero de flujos deseados para la transferencia de datos. En este caso, se opt´o por el n´ umero donde el desempe˜ no se estabiliza aproximadamente al aumentar la cantidad de flujos, por lo tanto, para esta experiencia se utilizar´an seis flujos de datos. A continuaci´on, ejecutamos iperf variando el tama˜ no del buffer, mediante la opci´on ((-l)), la cual nos permite cambiar el tama˜ no del buffer de datos a enviar. De esta forma, y para efectos de la experiencia, el tama˜ no del buffer se aument´o de forma exponencial de 1 Kbytes hasta 4 Mbytes.

58

Cap´ıtulo 5. Resultados

Al igual que en la experiencia anterior (secci´on 5.4.2, el procedimiento lo realizamos usando dos y tres tarjetas de red. En la figura 5.14 se muestra de forma simplificada como se ejecutan las instancias de iperf, para generar la variaci´on de tama˜ no del buffer con seis flujos TCP. for BUFFER in 1 2 4 8 16 32 64 128 256 512 1024 2048 4096; do for j in ‘seq 1 6‘; do iperf -c $IP_SERVER -i 1 -t $TIME -f m -l $BUFFER & done done

Figura 5.14: Script simplificado para generar variaci´ on de buffer con seis flujos TCP.

Figura 5.15. Evoluci´ on del throughput ante variaci´ on del tama˜ no del buffer.

En la figura 5.15 se observa como la variaci´on del tama˜ no de buffer de datos no afecta mayormente, el u ´nico valor que muestra una diferencia notoria es cuando el buffer vale 1 Kbytes. A partir de ah´ı, el desempe˜ no alcanza inmediatamente su estado estable. Por lo tanto, se puede afirmar que el tama˜ no del buffer no tiene gran relevancia en el desempe˜ no de TCP, cuando el canal est´a saturado.

59

Cap´ıtulo 5. Resultados

5.4.4.

Efecto de la ventana de TCP

En la siguiente experiencia vamos a observar la evoluci´on del desempe˜ no, frente a la variaci´on de la ventana de TCP. El procedimiento seguido en esta experiencia es casi id´entico al de la secci´on 5.4.3, el detalle de este es: Fijamos el MTU en 9000 bytes. Una vez fijado el MTU, se fija el n´ umero de flujos deseados para la transferencia de datos. Al igual que la experiencia anterior, se opt´o por utilizar seis flujos de datos. A continuaci´on, ejecutamos iperf variando el tama˜ no de la ventana TCP, mediante la opci´on ((-w)), la cual nos permite cambiar el tama˜ no de la ventana. De esta forma, y de forma id´entica a la experiencia anterior se aument´o el tama˜ no de la ventana de forma exponencial de 2 Kbytes hasta 8 Mbytes. Al igual que en las experiencias anteriores (secci´on 5.4.2 y 5.4.3, el procedimiento lo realizamos usando dos y tres tarjetas de red. En la figura 5.16 se muestra de forma simplificada como se ejecutan las instancias de iperf, para generar la variaci´on de tama˜ no de la ventana con seis flujos TCP. for WINDOW in 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192; do for j in ‘seq 1 6‘; do iperf -c $IP_SERVER -i 1 -t $TIME -f m -w $WINDOW & done done

Figura 5.16: Script simplificado para generar variaci´ on de la ventana con seis flujos TCP.

En la figura 5.17 se observa como la variaci´on del tama˜ no de la ventana de TCP si afecta al desempe˜ no, ya que la variaci´on es mucho m´as evidente, en comparaci´on al experimento anterior. Adem´as, se puede apreciar que el desempe˜ no no llega tan r´apido a estabilizarse, a diferencia de la figura 5.15.

60

Cap´ıtulo 5. Resultados

Figura 5.17: Evoluci´ on del throughput ante variaci´ on del tama˜ no de la ventana.

5.4.5.

Latencia del driver bonding

Como se menciona en la secci´on 4.2 y m´as espec´ıficamente se aprecia en la figura 4.1, el driver bonding agrega una capa m´as a la arquitectura de red en Linux. La adici´on de esta capa de software, evidentemente, significa un costo adicional en procesamiento. Por tanto, la siguiente experiencia tiene como objetivo medir el costo que presenta el uso del driver bonding en la latencia entre dos nodos. Para esto, la herramienta de software utilizada es NetPIPE. Como se explica y se ve en la secci´on 5.3.2, NetPIPE nos entrega directamente la latencia o tiempo de transferencia del mensaje. Por tanto, el experimento a realizar consiste simplemente en ejecutar NetPIPE en nodos normales, es decir, sin usar bonding; para luego ejecutar nuevamente NetPIPE en nodos que s´ı utilizan bonding. De esta forma se puede comparar el costo en tiempo que adiciona el driver bonding. Los resultados obtenidos se muestran en la figura 5.18, en ella se puede apreciar dos cosas: La latencia va creciendo al aumentar el tama˜ no del mensaje. La diferencia entre la latencia de un nodo con y sin bonding es muy leve, por no decir casi nula.

61

Cap´ıtulo 5. Resultados

Figura 5.18: Comparaci´ on de latencias entre nodos que usan y no usan bonding.

5.4.6.

Prueba en cluster (PVFS)

La siguiente experiencia tiene como objetivo observar como afecta la transferencia de los datos al desempe˜ no de un cluster. Para ello se instal´o y configur´o PVFS, el cual como ya se ha mencionado es un sistema de archivos paralelos espec´ıficamente para clusters. El experimento en s´ı es muy simple, este consiste en copiar un archivo de gran tama˜ no desde un nodo cliente, de esta forma PVFS dividir´a este archivo y lo copiar´a de forma paralela en todos los nodos del cluster. La variables a medir es el tiempo que demora en transferir este archivo. Se utiliz´o un u ´nico archivo de gran tama˜ no debido a que PVFS presenta su mejor rendimiento cuando se utilizan archivos de gran tama˜ no. En este caso espec´ıfico el archivo a copiar es de 3.6 Gbytes. Las optimizaciones aplicadas a la arquitectura de red de Linux en esta experiencia son dos: Aumentar el n´ umero de interfaces de red Aumentar el valor del MTU.

62

Cap´ıtulo 5. Resultados

Los resultados obtenidos se muestran en la tabla 5.3. En las tablas 5.4 y 5.5 se muestran los porcentajes de mejoras al aplicar las optimizaciones. Para la tabla 5.4 se muestra el porcentaje de mejora del desempe˜ no al incrementar el valor del MTU. no al ir En el caso de la tabla 5.5 se muestra el porcentaje de mejora del desempe˜ aumentando el n´ umero de interfaces de red utilizadas para la comunicaci´on. N´ umero de Interfaces 1 2 3

Tiempo con MTU 1500 (segs) 106.330994 98.693014 97.321576

Tiempo con MTU 9000 (segs) 104.944712 97.556917 95.420079

Tabla 5.3. Datos obtenidos en experimento con PVFS.

N´ umero de Interfaces 1 2 3

Tiempo con MTU 1500 ( %) 100 100 100

Tiempo con MTU 9000 ( %) 98.7 98.8 98.0

Tabla 5.4: Porcentajes obtenidos en experimento con PVFS respecto al valor del MTU.

N´ umero de Interfaces 1 2 3

Tiempo con MTU 1500 ( %) 100 92.8 91.5

Tiempo con MTU 9000 ( %) 100 92.9 90.9

Tabla 5.5: Porcentajes obtenidos en experimento con PVFS respecto al n´ umero de interfaces.

Como se puede apreciar en las tabla 5.3, 5.4 y 5.5, tanto el aumento de interfaces de red por nodo, como el aumento del MTU producen una disminuci´on del tiempo de copiado del archivo. Esto comprueba que ambas modificaciones a la arquitectura de red producen una mejora en la transferencia de datos y por ende en el rendimiento del cluster. Ahora observando los datos de las tablas 5.4 y 5.5 podemos afirmar que la adici´on de interfaces de red produce una mejora m´as significativa en el desempe˜ no del cluster,

63

Cap´ıtulo 5. Resultados

ya que el hecho de agregar s´olo una interfaz de red disminuye los tiempos de copiados en aproximadamente un 7 %, mientras que al aumentar el valor del MTU tiene como m´aximo una disminuci´on del 2 % del tiempo de copiado. La ventaja de ambas optimizaciones es que se complementan, por lo tanto, se pueden aplicar ambas en un nodo. De hecho, la mayor reducci´on del tiempo de copiado se logr´o cuando los nodos funcionaban con tres interfaces de red y un MTU de 9000.

Figura 5.19: Tiempo de copiado de archivo con diferentes m´ etodos de interconexi´ on.

En la figura 5.19, se puede ver gr´aficamente como disminuyen los tiempos de copiado, y como el menor tiempo se logra con 3 interfaces de red y el MTU de 9000.

64

Cap´ıtulo

6 Conclusiones

A partir del trabajo realizado podemos concluir que existen variadas formas de optimizar la arquitectura de red de Linux, algunas de las cuales se pudieron comprobar en un cluster real (PVFS). De esta forma, con hardware bastante t´ıpico se pudo mostrar como es posible montar un cluster, cuyo costo es muy inferior a los clusters espec´ıficamente dise˜ nados para procesamiento paralelo. En realidad, el trabajo realizado consisti´o en exprimir a fondo el hardware disponible, para lograr mejoras en la comunicaci´on de los nodos. Lo cierto es que, por el lado del channel bonding se podr´ıa haber seguido experimentando, pero el hardware disponible no permit´ıa m´as de tres interfaces de red por nodo, debido al n´ umero limitado de slots PCI-Express, pese a ello los resultados fueron bastante buenos, ya que se logr´o aumentar un par´ametro muy importante, como lo es: el throughput o desempe˜ no, sin sacrificar otro par´ametro igual de importante como lo es: la latencia. Algunas conclusiones obtenidas directamente de los resultados de los experimentos son: El incremento del valor del MTU produce un aumento directamente proporcional del desempe˜ no. La adici´on de flujos TCP simult´aneos producen un aumento en el desempe˜ no, ya que de esta forma, el canal de datos (el cual ha aumentado de capacidad debido al uso de bonding) recibe una mayor cantidad de datos transferidos por cada uno de los m´ ultiples flujos TCP. Sin embargo, el desempe˜ no aumenta hasta una determinada cantidad de flujos, en este caso seis. Luego, si se sigue incrementando el n´ umero de flujos el desempe˜ no no aumentar´a, por lo tanto, podemos decir que la capacidad total de canal ha sido alcanzada con seis flujos TCP, tal como se puede ver en la figura 5.13.

65

Cap´ıtulo 6. Conclusiones

El tama˜ no del buffer de datos no influye mayormente en el desempe˜ no, ya que para varios tama˜ nos de buffer el valor permanece bastante estable. La variaci´on de la ventana de datos TCP afecta el desempe˜ no, ya que tal como se puede ver en la figura 5.17, para valores peque˜ nos de ventana, el desempe˜ no obtenido es mucho menor que para valores m´as grandes de ventana. De hecho, el desempe˜ no tiende ir aumentando mientras los valores de ventana se incrementan hasta llegar a estabilizarse, en este caso, alrededor de los 256 KBytes. La adici´on de interfaces de red, mediante el uso del driver bonding, produce un aumento del desempe˜ no. El crecimiento del desempe˜ no debido al aumento del MTU, se amplifica al aumentar el n´ umero de interfaces usadas para transferir datos. Esto se puede no son apreciar en la tabla 5.2, como los porcentajes de aumento del desempe˜ mayores cuando se utilizan dos interfaces. El desempe˜ no se vuelve menos estable al agregar interfaces de red. Esto se debe principalmente, a que el env´ıo y recepci´on de paquetes se realiza indistintamente por cualesquiera de las interfaces de red que componen la interfaz l´ogica. Por lo tanto, esto hace que la transferencia de datos sea mucho m´as propensa a presentar errores, los cuales se pueden considerar como indicadores de congesti´on en la red. Luego, TCP reacciona al detectar congesti´on en la red, disminuyendo su tasa de transferencia, para luego ir aument´andola gradualmente. Debido a esto, el desempe˜ no se vuelve m´as variable, como se puede apreciar en la figura 5.10, a diferencia del registrado con una sola interfaz, la cual se muestra en la figura 5.7. Seg´ un [6] es posible mejorar estas variaciones en el desempe˜ no, ajustando el par´ametro net.ipv4.tcp reordering. Este par´ametro le indica al kernel la cantidad de paquetes que pueden ser reordenados en un flujo TCP, sin que se asuma una p´erdida de paquetes. La latencia de las conexiones TCP practicamente no se ve afectada por la adici´on de una capa de software, como resulta ser el uso del driver bonding. Esto se debe principalmente a que, la capacidad de procesamiento de los nodos, la cual se menciona en la secci´on 5.2, es bastante grande, y a su vez ´estos se encuentran dedicados a realizar esta experiencia. Es posible esperar que en una situaci´on real de un cluster, la latencia se vea afectada por la capa extra de software, ya que cada nodo adem´as de procesar una capa extra de software debido al bonding, deber´a utilizar su recursos en la tarea para la cual fue dise˜ nado el cluster.

66

Cap´ıtulo 6. Conclusiones

Para el caso de prueba en un cluster real (PVFS), se comprob´o como un par de optimizaciones propuestas provocaron cambios en el rendimiento del cluster. Para el caso de la variaci´on del MTU se pudo observar que al aumentar su valor de 1500 a 9000, PVFS disminuy´o su tiempo de copiado entre un 1.5 % y 2 %, por lo tanto, est´a optimizaci´on mejor´o levemente el rendimiento del cluster. La siguiente optimizaci´on aplicada fue el aumento del n´ umero de interfaces de red en cada uno de los nodos involucrados (eran tres). En este caso, al agregar una segunda interfaz de red se observ´o que el tiempo de copiado decay´o en aproximadamente un 7 %, lo cual representa una mejora m´as sustancial respecto a la otra optimizaci´on. Luego, al incrementar a tres el n´ umero de interfaces de red, el tiempo de copiado volvi´o a caer en promedio un 8.8 % respecto al registrado con una interfaz de red. Por tanto, se puede afirmar que la mejora al pasar de dos a tres interfaces de red es aproximadamente un 1.5 %. En base a esto, se podr´ıa decir que de continuar aumentando el n´ umero de interfaces de red no asegura una mejora en el rendimiento del cluster. Como ya hemos mencionado la ventaja de las optimizaciones aplicadas es que se complementan. Lo cierto es que de acuerdo a los datos obtenidos en la secci´on 5.4.6, el mejor rendimiento del cluster se obtiene con los valores m´as grandes usados para las optimizaciones, es decir, con tres interfaces de red y un MTU de 9000. Se pudo comprobar la influencia que tiene el rendimiento de la arquitectura de red, en la producci´on de un cluster real, ya que fue posible disminuir los tiempos de copiados, al aplicar ciertas optimizaciones. Sin embargo, los porcentajes de mejora son inferiores a los registrador con iperf. Esto puede deberse a la diferencia de los tama˜ nos de los archivos a usados. Con iperf se transfer´ıa cerca de 4 GBytes entre dos nodos, en cambio, con el archivo usado con PVFS era de 3.6 GBytes, el cual se divid´ıa en tres dando un tama˜ no de 1.2 GBytes por nodo. Por lo que, podr´ıa esperarse que al usar archivos de mayor tama˜ no, los porcentajes de mejora se vean incrementados. Otra posible forma de mejorar los tiempos de copiados, ser´ıa aumentando el n´ umero de interfaces de red s´olo en los clientes, ya que los nodos de I/O no utilizan toda la capacidad que les permite el uso de m´ ultiples interfaces de red, debido a que el nodo cliente es quien limita la transferencia de datos. Por lo tanto, si se elimina el uso de bonding en estos nodos, tambi´en se esta disminuyendo los errores asociados, lo cual puede resultar en un mejora en los tiempos de copiado. Finalmente, otra probable manera de mejorar los tiempos de copiados, ser´ıa aumentar el n´ umero de nodos de I/O, ya que de esta forma estar´ıan entrando en acci´on m´as flujos TCP, tal como se muestra en la secci´on 5.4.2.

67

Cap´ıtulo 6. Conclusiones

Como u ´ltimo comentario, se puede afirmar que quiz´as iperf no era la herramienta de benchmark m´as idonea, ya que esta trabaja s´olo entre dos nodos. Producto de esto, al comparar los datos obtenidos con iperf, con los datos obtenidos en un cluster real difieren un poco, ya que el cluster interact´ ua con m´as de dos nodos.

68

a

1

Referencias

[1] M. Allman, S. Floyd, and C. Partridge. Increasing TCP’s initial window, 1998. [2] Daniel Andresen and Sterling Hanenkamp. Heterogeneous channel bonding revisited. [3] Lawrence S. Brakmo and Larry L. Peterson. TCP Vegas: End to end congestion avoidance on a global internet. IEEE Journal on Selected Areas in Communications, 13(8):1465–1480, 1995. [4] Intel Corporation. 10 gigabit ethernet expands network bandwidth and shrinks latency. White paper, Febrero 2006. [5] Al Davis, Mark R. Swanson, and Michael Parker. Efficient communication mechanisms for cluster based parallel computing. In Communication, Architecture, and Applications for Network-Based Parallel Computing, pages 1–15, 1997. [6] Thomas Davis. Linux Ethernet Bonding Driver HOWTO, Nov 2007. [7] Antonio F. D´ıaz, Julio Ortega, Antonio Ca˜ nas, F. J. Fern´andez, and Alberto Prieto. The lightweight protocol CLIC: Performance of an MPI implementation on CLIC. In CLUSTER, pages 391–398, 2001. [8] Robert Shorten Douglas Leith and Y. Lee. H-tcp: A framework for congestion control in high-speed and long-distance networks. [9] Kevin Fall and Sally Floyd. Simulation-based comparisons of Tahoe, Reno and SACK TCP. Computer Communication Review, 26(3):5–21, July 1996.

69

Referencias

[10] S. Floyd. HighSpeed TCP for Large Congestion Windows. RFC 3649 (Experimental), December 2003. [11] S. Floyd and T. Henderson. The NewReno Modification to TCP’s Fast Recovery Algorithm. RFC 2582, 1999. [12] Urs Hengartner, Jurg Bolliger, and Thomas Gross. TCP Vegas revisited. In INFOCOM (3), pages 1546–1555, 2000. [13] Geoff Huston. TCP performance. Internet Protocol Journal, 3(2), June 2000. [14] Geoff Huston. Gigabit TCP. Internet Protocol Journal, 9(2), June 2006. [15] V. Jacobson and R. T. Braden. TCP extensions for long-delay paths. RFC 1072, October 1988. Obsoleted by RFCs 1323, 2018. [16] V. Jacobson, R. T. Braden, and D. Borman. TCP Extensions for High Performance. RFC 1323 (Proposed Standard), May 1992. [17] C. Jin, D. Wei, and S. Low. FAST TCP: Motivation, architecture, algorithms, performance, 2004. [18] Tom Kelly. Scalable tcp: improving performance in highspeed wide area networks. Computer Communication Review, 33(2):83–91, 2003. [19] Douglas Leith and Robert Shorten. H-tcp: Tcp for high-speed and long-distance networks. [20] Evangelos P. Markatos. Speeding up TCP/IP : Faster processors are not enough. Technical Report no. 297, ICS-FORTH, Heraklion, Crete, Greece, December 2001. [21] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow. TCP Selective Acknowledgement Options. RFC 2018 (Proposed Standard), October 1996. [22] M. Mathis, J. Semke, and J. Mahdavi. The macroscopic behavior of the TCP congestion avoidance algorithm. Computer Communications Review, 27(3), 1997. [23] Dave Miller. How the linux tcp output engine works, Jul 2005. [24] J. C. Mogul and S. E. Deering. Path MTU discovery. RFC 1191 (Draft Standard), November 1990.

70

Referencias

[25] Odysseas I. Pentakalos. An introduction to the infiniband architecture. In Int. CMG Conference, pages 425–432, 2002. [26] J. Postel. Transmission Control Protocol. RFC 793 (Standard), September 1981. Updated by RFC 3168. [27] J. Postel. TCP maximum segment size and related topics. RFC 879, November 1983. [28] I. Rhee and L. Xu. Cubic: A new tcp-friendly high-speed tcp variant. In In Proceedings of Third International Workshop on Protocols for Fast Long-Distance Networks, 2005. [29] W. Richard Stevens. TCP/IP illustrated (vol. 1): the protocols. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1993. [30] W. Richard Stevens and Gary R. Wright. TCP/IP illustrated (vol. 2): the implementation. Addison-Weley Longman Publishing Co., Inc., Boston, MA, USA, 1995. [31] Mark R. Swanson and Leigh B. Stoller. Direct deposit: A basic user-level protocol for carpet clusters. Technical Report UUCS-95-003, University of Utah, Department of Computer Science, June 1, 1995. [32] Link aggregation according to ieee 802.3ad. White Paper, Apr 2002. [33] Fouad Tobagi and Wal Noureddine. The transmission control protocol, November 09 2002. [34] Dave Turner, Adam Oline, Xuehua Chen, and Troy Benjegerdes. Integrating new capabilities into netpipe. Technical report, Ames Laboratory - Iowa State University, 327 Wilhelm Hall, Ames, Iowa, 50011, 2003. [35] VITA Standards Organization. Myrinet-on-VME Protocol Specification, 1998. ANSI/VITA 26-1998. [36] Thorsten von Eicken, Anindya Basu, Vineet Buch, and Werner Vogels. U-Net: A user-level network interface for parallel and distributed computing. In SOSP, pages 40–53, 1995. [37] Klaus Wehrle, Frank Pahlke, Hartmut Ritter, Daniel Muller, and Marc Bechler. Linux Network Architecture. Prentice-Hall, Inc., Upper Saddle River, NJ, USA, 2004.

71

Referencias

[38] Lisong Xu, Khaled Harfoush, and Injong Rhee. Binary increase congestion control (bic) for fast long-distance networks. In IEEE Infocom 2004. IEEE, 2004.

72