En este artículo se hace una comparación detallada entre las tecnologías Ethernet y RapidIO. RapidIO, similar a Ethernet, intercambia paquetes a través de diferentes medios.

Descripción general de la tecnología RapidIO
RapidIO, similar a Ethernet, intercambia paquetes a través de diferentes medios. RapidIO soporta correo electrónico y semántica de lectura y escritura, permitiendo operaciones en el plano de control y de datos para utilizar la misma interconexión física, lo que representa una característica que mejora la eficiencia y simplifica el diseño del sistema. Diseñada desde el principio para minimizar la latencia, la tecnología RapidIO se ha optimizado para su implementación en hardware.

Los enlaces RapidIO garantizan la entrega de los paquetes, aunque haya congestión y errores de transmisión, mediante simples mecanismos de control de flujo y de recuperación después de detectar un error. Dichos mecanismos se implementan con pequeñas cantidades específicas de enlace, que se denominan “símbolos de control”. La mayoría de los símbolos de control pueden incorporarse a paquetes; de este modo, se garantiza una reducción al mínimo de la latencia del bucle de control para un intercambio de paquetes fiable.
Descripción general de la tecnología Ethernet

Ethernet siempre ha sido un medio “imperfecto”, porque requiere soporte de software de protocolos, como el TCP (Transmission Control Protocol), para prestar servicios de transporte fiables. Los mecanismos de control de flujo habituales en Ethernet consisten en protocolos de capa de red, que controlan las tasas de transmisión basándose en la detección de pérdida de paquetes, ya que esta es la manera más eficaz de asegurar un caudal razonable en una red mundial.

Últimamente, se ha oído hablar del concepto de “Ethernet sin pérdidas”, también conocido como “Data Center Ethernet (DCE)”. Ethernet sin pérdidas reduce el número de paquetes perdidos como consecuencia de la congestión en la red estableciendo un control de flujo a nivel de enlace. Esto permite incrementar la eficiencia de la red global porque se reduce enormemente la cantidad de paquetes extraviados. El rendimiento de Ethernet sin pérdidas en caso de congestión es comparable al de RapidIO.
Para una comparación detallada entre las tecnologías RapidIO y Ethernet, visite www.rapidio.org y lea System Interconnect Fabrics:

Ethernet Versus RapidIO Technology.
¿Sin pérdidas?
RapidIO garantiza la entrega de paquetes en cada enlace. En el caso de una conexión de fibra óptica de 100 m/10 Gbps, la recuperación puede llevarse a cabo con el intercambio de tres símbolos de control, proceso que requiere aproximadamente 2,5 microsegundos. En caso de enlace chip a chip, el intercambio se realiza en menos de 300 ns.

El término Ethernet sin pérdidas no es del todo acertado, porque sigue existiendo la posibilidad de perder paquetes debido a un error de transmisión. Por lo tanto, DCE necesita, ahora como antes, motores de descarga y/o pilas de software, por lo que aumenta la latencia en la entrega de mensajes. Por ejemplo, el protocolo de canal de fibra permite la recuperación tras un error en FCoE. Por consiguiente, la resolución del error presenta una latencia mucho más alta en Ethernet que en RapidIO, y esta latencia elevada tiene un impacto considerable sobre el uso de los recursos y el rendimiento del sistema.
Los grupos de trabajo dedicados a Ethernet trabajan para incorporar la corrección de errores de envío (FEC) al esquema de transmisión para tasas de datos más altas. Es cierto que esto puede disminuir significativamente la posibilidad de un error, pero también contribuye a una mayor latencia en cada transferencia de un dispositivo a otro en toda la red.  

Dos mercados de Ethernet
En efecto, la comunidad de Ethernet toma un rumbo completamente nuevo y divide el mercado en dos segmentos, es decir, Internet y DCE. En el contexto de Internet que se extiende por todo el planeta, el control de flujo a nivel de capa de red proporciona un caudal más alto que el control de flujo a nivel de enlace. Por las latencias de Ethernet en la red mundial Internet y la topología de red dinámica, el control de flujo a nivel de red resulta ser la estrategia de control de flujo más eficaz. La tecnología de Ethernet consiste, en su gran mayoría, en Ethernet para Internet.

La tecnología de Ethernet para Internet depende de la capacidad de procesamiento en forma de plataformas de conmutadores y routers. Dentro de estas plataformas, las unidades de procesamiento de red (NPU) regulan el tráfico en conformidad con los acuerdos de nivel de servicio (SLA) establecidos e implementan protocolos de red, tales como MPLS. La figura 1 muestra un conmutador/router típico de Ethernet para Internet.

Transferencia de paquetes sin pérdidas
Tenga en cuenta que una plataforma de routers o conmutadores de Internet cuenta con una serie de conexiones de corto alcance entre chips. La baja latencia de estas conexiones de corto alcance puede aprovecharse para minimizar la pérdida de paquetes mediante simples mecanismos de control de flujo. Cabe señalar que los líderes de conmutadores y routers de Ethernet para Internet no utilizan Ethernet como tecnología de interconexión exclusiva en sus propias plataformas. En lugar de ello, unos estándares de interconexión, como SPI (Serial Peripheral Interconnect), Interlaken y RapidIO, incorporan mecanismos de control de flujo de baja latencia para asegurar una transferencia de paquetes eficaz sin pérdidas.
A diferencia de los conmutadores DCE con latencia más baja, los chips de conmutación de Ethernet para Internet pueden soportar las funciones incluidas en las plataformas de conmutadores y routers. Por lo tanto, algunos dispositivos conectados directamente a los conmutadores DCE son responsables de estas funciones. Esto supone un cambio importante en las arquitecturas sencillas de transmisión y recepción que caracterizan la tecnología de Ethernet para Internet de la mayoría de los usuarios.

La llegada de Ethernet sin pérdidas significa la fractura del mercado de Ethernet en dispositivos de Ethernet para Internet y dispositivos para DCE. Los dispositivos para DCE, sin embargo, no pueden beneficiarse de las mismas economías de escala que los de Ethernet para Internet.

Caudal, latencia y control de flujo
En la red de centros de datos, la latencia para funciones de control, tales como modificaciones de archivos y confirmaciones de transmisiones de datos, realmente puede limitar la capacidad del sistema. De modo similar, la latencia del sistema de control para funciones de equilibrado de carga en servidores puede determinar la utilidad y la eficiencia del sistema global.
En este contexto, los mecanismos de control de flujo deberían permitir a los paquetes de control hacer avanzar el envío tan pronto como sea posible. En caso de contención, convendría maximizar las opciones de programación, utilizando plenamente los búferes, para aumentar el caudal y reducir la latencia. La solución ideal sería que los búferes se gestionaran de tal manera que los flujos de alta prioridad siempre pudieran  circular hacia adelante. A continuación, se comparan las estrategias de control de flujo de RapidIO y de DCE.
Una estrategia de control de flujo integral

RapidIO implementa una estrategia de control de flujo integral para resolver la congestión del sistema a corto, mediano y largo plazo. Los mecanismos de control de flujo de RapidIO permiten que un transmisor use la capacidad de los búferes del receptor hasta su agotamiento. Esto es importante por varios motivos:
Cuantos más paquetes guarda un chip de conmutación en sus búferes, más posibilidades tiene para incrementar el caudal encaminando paquetes a puertos de salida no congestionados, lo cual debería dar por resultado un máximo de caudal y un mínimo de latencia.
El transmisor y el receptor se han puesto de acuerdo sobre cuántos paquetes se pueden transferir por cada canal prioritario/virtual. El transmisor puede utilizar esta información a la hora de programar la transmisión de paquetes para optimizar el rendimiento de latencia de la red.

El mecanismo de control de baja latencia permite minimizar el tamaño del búfer de RapidIO a la vez que garantiza la entrega de paquetes y alcanza tasas de transmisión de línea.
El control de flujo basado en el estándar de prioridad IEEE 802.1p utiliza un mecanismo XON/XOFF, que debe activarse antes de que el espacio del búfer en el receptor pueda agotarse. En la figura 2 se puede ver claramente por qué la posibilidad de incluir información del control de flujo a nivel de enlace en los paquetes es una ventaja tan importante para RapidIO. En el punto 1, el receptor decide que tiene que desactivar una prioridad determinada. No obstante, el marco MAX amarillo (punto 2) ha iniciado la transmisión e impide la transmisión del marco PAUSE XOFF. De este modo, el receptor puede recibir el correspondiente marco MAX amarillo. Una vez que el transmisor haya recibido el marco PAUSE XOFF, puede surgir un problema similar en el punto 3, en el que un marco MAX ya ha iniciado la transmisión. Por lo tanto, la cantidad de información mínima recibida después de la transmisión de XOFF, es decir, el derrape o skid, que los enlaces de Ethernet deben tener en cuenta, es de dos paquetes de tamaño máximo.

Para un enlace de 10 Gbps con una longitud de 100 m, se calcula una longitud del derrape de aproximadamente 10,1 KB (http://www.ieee802.org/1/files/public/docs2008/bb-pelissier-pfc-proposal-0508.pdf). Este cálculo supone una longitud máxima de paquete de 2.000 bytes. Si se utilizan otros protocolos relacionados con el almacenamiento, tales como FCoE con una unidad máxima de transferencia (MTU) de 2,5 KB o iSCSI cuya MTU es de 9 KB, se incrementará la longitud del derrape. Y en otras iniciativas de Ethernet, como por ejemplo PEE (Power Efficient Ethernet), la longitud del derrape puede ser incluso mayor.

Relevancia de la longitud del derrape

Para tarjetas de interfaz de red (NIC) y procesadores con gigabytes de DRAM, la longitud del derrape no es relevante. Sin embargo, para las pequeñas memorias incorporadas que se encuentran en los chips de conmutación, la longitud del derrape es preocupante. Una longitud elevada tiene consecuencias importantes para los diseñadores de conmutadores de Ethernet y los usuarios de Data Center Ethernet:
Para evitar el envío de un XON seguido inmediatamente de un XOFF, se necesita más que la longitud del derrape del búfer antes de activar un flujo. Esto implica que los paquetes se transmitirán en determinados flujos formando un tráfico a ráfagas, lo cual dará como resultado un comportamiento irregular de la red.
No hay garantía de que los paquetes de “derrape” enviados cumplan con la prioridad, que se desactiva. Por lo tanto, una parte del búfer que se reserva para el derrape no contendrá paquetes, por lo que se incrementará la latencia y se disminuirá el caudal.
Para reducir el espacio de memoria requerido para un puerto de Ethernet, una manera de optimizar el diseño consiste en agrupar múltiples prioridades con la finalidad de controlar el flujo. Esto puede llevar a un bloqueo en la cabeza de la línea (HoL) con las correspondientes bajadas del caudal e incrementos de latencia en todo el tráfico que se registra en este grupo de prioridad.
Es posible que el control de flujo inutilice los algoritmos de programación para la transmisión de paquetes.
El control de flujo a corto plazo nunca ha sido el punto fuerte de Ethernet, pero el control de flujo a largo plazo sí que lo es. Por regla general, los protocolos de control de flujo basados en software dependen de la detección de pérdidas de paquetes cuando los dispositivos de Ethernet para Internet descartan paquetes en caso de congestión. Puesto que DCE ya no descarta paquetes en caso de congestión, el control de flujo a largo plazo se soporta utilizando el estándar de LAN virtual 802.1Q. 

Las especificaciones de RapidIO Gen2 han creado XON/XOFF así como mecanismos de control de flujo basados en tasas y créditos para flujos basados en paquetes de Data Streaming. Este mecanismo se ha diseñado para sistemas con múltiples remitentes y un solo destino. El protocolo permite a los remitentes comunicar la cantidad de información disponible, y al destinatario gestionar y programar quiénes de los remitentes están activos y a qué velocidad. Al contrario del mecanismo de control de flujo que funciona con software, el formato de paquete es tan simple que el hardware puede soportar estos mecanismos. Si se usan correctamente, estos mecanismos de control de flujo pueden evitar congestiones a largo plazo y capacitan las aplicaciones para un rendimiento óptimo.

Superar la congestión
Un método de resolver los problemas relacionados con la congestión de red y el control de flujo consiste en comunicar dónde se atasca el tráfico por la red. Esta información permite programar la transmisión de paquetes en origen para que circulen por áreas no congestionadas de la red. RapidIO soporta mecanismos para comunicar el lugar de congestión en la red. RapidIO Gen2 define un mecanismo de baja latencia basado en símbolos de control, denominado Virtual Output Queue (VoQ) Backpressure. La contrapresión de las colas virtuales a la salida (VoQ Backpressure) define un método jerárquico, implementable en hardware, que relega la congestión hacia el margen de la red. Este método presenta dos ventajas:
Desacelera los flujos que contribuyen a puntos de congestión y libera recursos del sistema.
Favorece la transmisión de otros flujos que no incrementan la congestión y, de este modo, aumenta el caudal y equilibra la carga del sistema.
En 2010, un grupo de trabajo IEEE ha empezado a definir un mecanismo similar, conocido como IEEE 801.3Qau - Notificación de congestión para redes de área local y metropolitana. No está claro si este mecanismo será lo suficientemente simple como para que los dispositivos pertenecientes al ecosistema DCE puedan soportarlo. 

Coclusión
Al hacer mis investigaciones acerca del tema de este artículo, encontré otro de Stuart Cheshire, publicado por primera vez en 1996, con el título provocador “It’s the Latency, Stupid”, que se podría traducir como “Es la latencia, tonto” (http://www.stuartcheshire.
org/rants/Latency.html). Aunque su artículo apunta a la latencia en los equipos de consumo de Ethernet para Internet, sus afirmaciones esenciales hoy en día parecen correctas:

•    Hacer más ancho de banda es fácil.
•    Ampliar el ancho de banda limitado es fácil.
•    Una vez que se establezca la mala latencia, es difícil librarse de ella.

La Ethernet del mercado de masas, es decir, Ethernet para Internet, se centra en entregar más ancho de banda por menos dinero.
La Data Center Ethernet tiene características que aumentarán el caudal y mejorarán el comportamiento de Ethernet para Internet en el centro de datos. No obstante, estas prestaciones repercuten negativamente en el diseño de chips de Ethernet, y siguen requiriendo software y/o motores de descarga para la recuperación tras un error de transmisión. El mercado de Data Center Ethernet es mucho más pequeño que el de Ethernet para Internet; por consiguiente, las economías de escala, que dan como fruto una tecnología económica de Ethernet para Internet, no son aplicables a Data Center Ethernet.

Las aplicaciones que han adoptado RapidIO necesitan una latencia baja y previsible para la comunicación chip a chip, placa a placa, backplane y caja a caja. Las empresas líderes en estos sistemas (como p. ej. Ericsson, EMC y Mercury) aseguran que RapidIO seguirá teniendo una latencia baja combinada con un alto caudal para garantizar que se cumplan las especificaciones de rendimiento de estos sistemas. RapidIO mantendrá la paridad de ancho de banda con otras interconexiones, a la vez que conserva el tejido con la latencia más baja y la eficiencia más alta disponible para conexiones chip a chip, placa a placa, backplane así como de fibra óptica/cable de hasta 100 m. 

Acerca del autor
Barry Wood es ingeniero experto en aplicaciones de IDT Canada. Barry se incorporó a IDT en 2001 después de trabajar 11 años en Nortel Networks. Barry tiene una dilatada experiencia en el diseño de sistemas tolerantes a errores, desarrollo de software e integración de hardware/software. Barry dirige actualmente el grupo de trabajo técnico dedicado a RapidIO.

Autor: Barry Wood, ingeniero de aplicaciones. IDT Technologies

Más información o presupuesto