Antes de comenzar a hablar sobre Jumbo Frames o Jumbograms [29] [30] voy a hacer un breve resumen de los distintos PDU (Packet Data Unit) utilizados en Internet/LAN:
En TCP [41], al PDU se lo llama “segmento” En UDP [42], al PDU se lo llama “datagrama”
En IP [43], al PDU se lo llama “datagrama” o “paquete” En Ethernet, al PDU se lo llama “frame”
Los frames IP grandes, también llamados “jumbogramas” o “jumbo frames”, han sido recomendados para redes de alto rendimiento como Abilene como un factor significativo para aumentar la performance a través de distancias largas. En general el factor limitante en el tamaño del frame o paquete es el MTU (Media Transmission Unit), el cual en Internet es de 1500 Bytes.
El MTU se especifica en octetos y es el tamaño máximo del paquete o frame que se puede enviar por una interface de red (y su correspondiente driver), tal el caso de Internet. TCP utiliza el MTU para determinar y optimizar el tamaño de los paquetes en cualquier transmisión.
La capa de enlace (link layer o nivel 2 en el modelo OSI) es la responsable de descubrir el MTU y reportarlo a los protocolos de niveles superiores. El MTU se configura en forma independiente para cada interface con un flujo de datos IP, y cualquier interface puede limitar el tamaño del paquete fragmentándolo. El método “Path MTU Discovery” [31], intenta descubrir el MTU óptimo para el camino de manera de evitar la fragmentación de los paquetes. Para cada destino se asume inicialmente el MTU del link del primer salto. El Path MTU Discovery está deshabilitado en la mayoría de los sistemas operativos actuales, y existe un MTU fijo.
Con el Path MTU Discovery existen problemas, documentados en el RFC 2923 [32]. El mecanismo es frágil porque depende del mensaje ICMP “Can’t Fragment” de la red. Cuando hay un “agujero negro” de ICMP los
mensajes no se envían, causando que falle el Path MTU Discovery y así se suspenda la conexión de TCP.
Recordemos que el MTU fue una manera de protegernos de las tasas de errores de bit (bit error rate) en los primeros tiempos de Ethernet, en sus componentes de Nivel 1. Pero actualmente se ha incrementado el poder de procesamiento de las computadoras y se usa una Ethernet switcheada sobre UTP o Fibra Óptica, lo que implica una baja significativa en los errores en Ethernet.
La recomendación de Internet2 es trabajar hacia un IP MTU “extremo-a- extremo” de por lo menos 9000 bytes por ahora, y eventualmente más grande. Con respecto a esto, Abilene actualmente trabaja con valores de IP MTU de 9180 Bytes y 9000 Bytes. Estos valores de MTU se usan tanto para IPv4 como para IPv6.
Vale la pena aclarar que en el párrafo anterior se habla de “IP MTU” y no de MTU, dado que se quiere hacer notar que en Internet2 se considera al MTU como el tamaño máximo de paquete IP sin fragmentar que puede atravesar una red, sin importar qué tecnologías de framing estén por debajo. O sea, es deseable trabajar con un valor extremo a extremo de 9000 Bytes de MTU a nivel IP o layer-3. Y por supuesto, dicho MTU incluye al header IP.
Abilene y sus conectores trabajan todos en conjunto con dicho tamaño de MTU, y las instituciones dentro de Internet2 configuraron el MTU también a 9 KB dentro de sus redes locales o por lo menos hasta las estaciones de alto rendimiento.
En cuanto a las redes Gigabit Ethernet, las mismas soportan tamaños de frame mayores a 1500 bytes, y esto ha sido tema de debate durante años y la decisión de adoptar o no este criterio afectará la performance de Internet en los próximos años.
Ethernet ha usado tamaños de frame de 1500 bytes desde que fue creada alrededor de 1980. Para mantener la compatibilidad hacia atrás, las redes Fast Ethernet (100 Mbps) y las redes Gigabit Ethernet (1000 Mbps) estándares usan el mismo tamaño de frame, y por lo tanto no hay ninguna fragmentación o reensamblaje de Nivel 2 (modelo OSI). En este punto vale aclarar que, teniendo en cuenta el modo de transmisión half-duplex y con el objeto de detectar las colisiones, en Ethernet y Fast Ethernet el tamaño mínimo de frame es de 64 Bytes, mientras que en Gigabit Ethernet existen tamaños mínimos de frame definidos de acuerdo a si se transmite por fibra
o cable. El estándar 802.3z para transmisión sobre fibra óptica (1000Base- X) tiene un tamaño mínimo de frame de 416 Bytes, mientras que el estándar 802.3ab para transmisión sobre cable de par trenzado (1000Base- T) tiene un tamaño mínimo de frame de 520 Bytes (provee más tiempo para que el dispositivo transmisor reciba una notificación de colisión en el caso de un evento de congestión). En base a ello en Gigabit Ethernet se usa en campo de extensión variable para rellenar (padding) los frames que son más cortos que el tamaño mínimo. Los tamaños mínimos de frame son necesarios para que el transmisor detecte una colisión antes de enviar el último byte del frame; de esta manera los frames deberán ser lo suficientemente largos para llenar completamente el medio y así, si una colisión sucede, el transmisor la detectará y arrancará el proceso de retransmisión antes de esperar por un ACK. Vale decir, el tamaño mínimo de frame está relacionado al control de colisiones. A manera de comentario, Gigabit Ethernet 1000Base-X usa 416 bytes en lugar de los 520 bytes debido a que esta tecnología codifica y transmite 10 bits por cada byte. Es importante aclarar que half-duplex es el modo de transmisión y recepción por el mismo medio pero no al mismo tiempo, hay contención por un medio compartido y así ocurren colisiones. Se usa el protocolo CMSA/CD (Carrier Sense Multiple Access with Collision Detection). Por otra parte, full-duplex es el modo de transmisión y recepción de datos por el mismo medio y al mismo tiempo. En este último caso existen dos enlaces punto a punto (uno en un sentido y otro en el opuesto) que conectan dos estaciones de transmisión y dado que en este esquema de trabajo no hay contención por un medio compartido, no pueden ocurrir colisiones y así no es necesario el uso del protocolo CMSA/CD.
Los “jumbo frames” extienden Ethernet a 9000 Bytes, primero porque Ethernet usa un CRC (Cycling Redundancy Checking o chequeo de redundancia cíclica) de 32 bits, que es un algoritmo que pierde efectividad por encima de los 12000 Bytes [33]. En verdad no hay ninguna demostración teórica de la citada pérdida de efectividad, pero ha sido bien demostrado en forma práctica en tamaños de frames mayores a 12 KB. EL CRC es un método de chequeo de errores en los datos que se transmiten por un canal de comunicaciones. El emisor aplica un polinomio de 16 o 32 bits al bloque de datos a transmitir y agrega el CRC resultante a dicho bloque. El receptor luego aplica el mismo polinomio a los datos y compara el resultado con el CRC agregado por el emisor; si los resultados concuerdan entonces los datos han sido recibidos en forma exitosa, de lo contrario el emisor puede serc notificado para renviar los datos con errores. El CRC de 16 bits detecta todos los errores de un solo bit y bits dobles (dos errores aislados de un solo bit) y asegura una capacidad de detección del 99,998% de todos los posibles errores de ráfagas de 18 bits o mayores. Este nivel de detección es
considerado suficiente para frames de 4 KB o menos. Para paquetes de mayores tamaños se usa un CRC de 32 bits.
En segundo lugar, un paquete de 9000 Bytes es un tamaño adecuado para transportar un datagrama de 8 KB (como por ejemplo los de una aplicación como NFS) más el overhead del header del paquete.
El límite de un datagrama IPv4 es de 64 KB, en tanto que IPv6 permite paquetes de hasta 4 GB de tamaño. Para Ethernet el límite de CRC 32 bits es muy difícil de cambiar, por lo tanto no se puede esperar tamaños de frame Ethernet mayores a los 9000 Bytes en lo inmediato. La coexistencia de los “jumbo frames” y frames de 1500 bytes es posible en las siguientes circunstancias:
• En un principio de comunicación puerto a puerto, donde todo el flujo de downstream desde un dado puerto es conocido para soportar jumbo frames
• Usando el estándar 802.1q Virtual LANs, donde los dispositivos jumbo frame y no jumbo frames son separados hacia diferentes VLANs
Un estudio del tamaño de los frames que más se usan en la actualidad dio este resultado:
El gráfico muestra la distribución de diferentes tamaños de paquetes que fluyen a través de un backbone OC3. Hay mucha más densidad de uso de paquetes de hasta 1500 Bytes (Ethernet estándar) pero también hay tráfico por encima de los 4000 Bytes (que es el MTU de FDI). Y aquí hay que destacar un hecho: mientras que el número de paquetes de tamaño mayor a 1500 Bytes es más pequeño, más del 50% de los Bytes fueron transportados por tales paquetes a consecuencia de su mayor tamaño. Muchos de los flujos de datos de alta velocidad han sido alcanzados sobre enlaces ATM WAN con 9180 Bytes de MTU.
Los frames más pequeños implican más interrupciones de CPU y más overhead de procesamiento para un dado tamaño de transferencia de datos. Un análisis comparativo entre jumbo frames Ethernet y frames Ethernet de 1500 bytes muestra el siguiente resultado:
Los jumbo frames proveen casi 50% más de throughput con casi el 50% menos de carga de CPU que utilizando frames de 1500 Bytes. A pesar de que este overhead local puede reducirse en parte con diseños de sistemas mejorados, descarga de trabajo hacia las interfaces NIC, etc., lo que más importa es el enlace WAN.
Las últimas estadísticas [28] reportan que aproximadamente el 6% del tráfico de Internet2 es UDP y que el 5.42 % de los paquetes son mayores de 1500 Bytes (jumbo frames).