Presentamos RIFL: Un Nuevo Protocolo para Centros de Datos

Los centros de datos están ganando importancia a medida que muchos servicios y aplicaciones requieren un intercambio rápido de datos. La velocidad a la que se mueven los datos puede verse afectada por altos retrasos en la red. Los protocolos de red tradicionales están diseñados para funcionar no solo en redes locales pequeñas, sino también a largas distancias. Esto significa que a menudo incluyen características adicionales que pueden no ser necesarias para los centros de datos. Este artículo presenta un nuevo enfoque utilizando un protocolo de tres capas específicamente para la comunicación en centros de datos, comenzando con la primera capa llamada RIFL.

#Por qué necesitamos RIFL

Con el aumento de aplicaciones que necesitan acceso rápido a los datos, como el aprendizaje automático y el almacenamiento en la nube, la velocidad y la fiabilidad de la red son cruciales. Estudios anteriores muestran que los retrasos en la red pueden impactar significativamente el rendimiento de diferentes aplicaciones. La mayoría de las tecnologías utilizadas en los centros de datos de hoy se desarrollaron mucho antes de que el centro de datos moderno fuera una realidad. El Protocolo de Internet (IP) se creó en 1974, mucho antes de que se imaginaran grandes centros de datos. Dado los cambios rápidos en la tecnología, es hora de reconsiderar cómo deberían estructurarse las redes de los centros de datos para satisfacer las necesidades actuales.

La pila de red TCP/IP tradicional está diseñada para redes locales y de área amplia, lo que significa que tiene características innecesarias cuando se usa en un centro de datos, donde las distancias son típicamente cortas. En muchos casos, un centro de datos opera de manera muy similar a una red de área local. Hay una necesidad de una pila de protocolos más eficiente que aborde las necesidades específicas de un centro de datos.

A pesar de estas necesidades, muchos centros de datos aún dependen de TCP/IP porque cambiar el hardware y el firmware de la red es difícil y consume tiempo. Introducir nuevos protocolos generalmente requiere actualizaciones significativas del hardware existente, lo que puede llevar años. Sin embargo, nuestro trabajo busca crear una plataforma de prueba flexible que nos permita explorar qué se podría hacer si no estuviéramos limitados por el hardware existente y las necesidades comerciales. Aprovechando los FPGAs modernos (matrices de compuertas programables en campo), podemos crear un protocolo más eficiente.

#Lo básico de RIFL

Los FPGAs más avanzados ahora ofrecen muchas conexiones de alta velocidad. Podemos usar estas conexiones para rediseñar las redes de los centros de datos desde cero, sin necesidad de hardware nuevo. Si bien hay muchos protocolos de red disponibles, la mayoría están diseñados para usos específicos y carecen de la flexibilidad necesaria para los centros de datos. Algunos utilizan métodos obsoletos que aún llevan características innecesarias.

Para satisfacer las demandas de las redes de centros de datos, proponemos una nueva pila de protocolos de tres capas:

1. Capa 1: Capa de Enlace
   Esta capa es la más cercana a la conexión física. Cubre la capa de enlace de datos y la capa física. Necesita proporcionar un método de transmisión confiable y abordar cualquier error de datos. El objetivo aquí es asegurar que más allá de esta capa, no debería ocurrir corrupción de datos.

2. Capa 2: Capa de red
   Esta capa se centra en enrutar datos rápidamente sin depender de una tabla de enrutamiento central. También debe gestionar cualquier congestión de tráfico. Las transferencias de datos por encima de esta capa deberían ocurrir sin pérdida.

3. Capa 3: Capa de Aplicación
   Esta capa conecta el hardware y el software. El hardware soporta aplicaciones comunes en centros de datos, como sistemas que aceleran el acceso a los datos. El software proporciona una forma amigable de interactuar con el hardware.

Juntas, estas capas crean un marco para una red sin pérdidas. En nuestras pruebas, encontramos que la Capa de Enlace puede ofrecer retrasos muy bajos y un alto ancho de banda.

#Características clave de RIFL

En nuestras discusiones, nos hemos centrado en la primera capa, RIFL. Esta capa está diseñada para permitir una comunicación de baja latencia con un uso mínimo de recursos. La fiabilidad significa que puede corregir cualquier error de datos durante la transmisión. Esto ayuda a que las capas superiores funcionen correctamente sin tener que preocuparse por la integridad de los datos.

Para asegurar que RIFL cumpla con estas necesidades, primero elegimos cómo manejar los errores. Hay dos enfoques principales: Corrección de errores hacia adelante (FEC) y retransmisión.

• Corrección de Errores hacia Adelante (FEC): Este método envía datos extras junto con los datos principales para ayudar a detectar y corregir errores. Usualmente requiere enviar más datos de los necesarios debido a su complejidad. Este enfoque puede funcionar bien en situaciones como la comunicación inalámbrica.

• Retransmisión: Este método envía los datos nuevamente solo cuando se detectan errores. Generalmente envía una cantidad menor de datos extra, lo que lo hace menos intensivo en ancho de banda en comparación con FEC. En las pruebas, encontramos que la retransmisión es más eficiente para la calidad típica de las conexiones en un centro de datos.

Para RIFL, hemos decidido usar retransmisión para gestionar errores. Nuestra investigación muestra que si la tasa de error está por debajo de un nivel específico, la retransmisión puede ser lo suficientemente eficiente como para garantizar una comunicación confiable.

El mecanismo de retransmisión también necesita estar diseñado para escenarios de peor caso. Para hacer esto, debemos asegurarnos de que nuestro búfer de retransmisión sea lo suficientemente grande para contener datos durante el tiempo de espera más largo posible para una respuesta.

#Beneficios de la transmisión hop-by-hop

Estamos implementando un enfoque hop-by-hop para la retransmisión dentro de RIFL. Esto significa que los datos se envían de un punto a otro sin pasar por múltiples puntos intermedios. Este método minimiza los retrasos, haciéndolo más eficiente que la retransmisión de extremo a extremo utilizada por protocolos como TCP.

Una de las ventajas significativas de este enfoque es que el receptor no experimentará ningún retraso debido a la congestión del tráfico. En el método hop-by-hop, el receptor solo trabaja directamente con un remitente, lo que reduce el riesgo de pérdida de tramas de datos.

#Métodos de reconocimiento

RIFL utiliza un método de reconocimiento negativo (NACK) para confirmar los datos recibidos. En este método, el receptor solo se comunica cuando detecta un error, en lugar de confirmar cada trama recibida correctamente. Esto es más eficiente para los centros de datos donde los errores son relativamente raros. En situaciones donde ocurre pérdida de datos, este método puede continuar asegurando la comunicación confiable sin un overhead excesivo.

#Estructura del marco RIFL

Para implementar RIFL, necesitamos definir claramente cómo se ve cada marco de datos. El marco de datos lleva no solo los datos principales, sino también información de control. Clasificamos los marcos en dos tipos principales:

• Marcos de Datos: Estos contienen los datos reales del usuario que necesitan ser transmitidos.

• Marcos de Control: Estos llevan información necesaria para gestionar el proceso de transferencia de datos.

Cada marco de datos debe contener un encabezado pequeño que incluya información vital como una suma de comprobación para detectar errores, un ID de marco para rastrear qué datos necesitan ser enviados nuevamente, y un marcador que indica el final de los paquetes de datos.

#Cómo opera RIFL

RIFL opera a través de una serie de estados distintos tanto para la lógica de envío (TX) como para la lógica de recepción (RX). La lógica TX gestiona los estados de envío de datos, tratando las pausas cuando es necesario y ocupándose de las retransmisiones cuando se identifican errores. La lógica RX revisa continuamente los datos entrantes y activa señales cuando ocurren problemas como pérdida de sincronización, necesidad de control de flujo o errores.

#Control de flujo y sincronización

Un control de flujo adecuado es esencial en un centro de datos para gestionar cuánto se envía en un momento dado. RIFL utiliza un método de control ON/OFF simple. Si el receptor se vuelve demasiado ocupado, puede señalar al remitente que detenga temporalmente el envío de datos. Esto previene la pérdida de datos y asegura que el sistema funcione sin problemas.

La sincronización del reloj también es crítica. A pesar de que los dispositivos deben funcionar a la misma velocidad, ligeras diferencias en las frecuencias de reloj pueden llevar a un desbordamiento de datos en un extremo. El control de flujo ayuda a gestionar esto, y la lógica TX puede ajustar su tasa de envío para prevenir problemas.

#Combinación de canales para tasas más altas

Si bien RIFL está diseñado para trabajar con una conexión única, también puede combinar varias conexiones para aumentar el ancho de banda total. Al dividir los datos entre múltiples líneas, RIFL puede manejar tasas de datos mucho más altas. Cada conexión funciona de manera independiente, permitiendo transmisiones simultáneas.

#Implementación y rendimiento

RIFL se ha implementado en varios dispositivos, y las pruebas han demostrado que proporciona una transmisión de datos de baja latencia y alta eficiencia. Durante pruebas con tasas de línea de 112 Gbps, logramos latencias alrededor de 100 nanosegundos, demostrando la capacidad de RIFL en aplicaciones del mundo real.

#Conclusión

RIFL representa un avance significativo en los protocolos de red para centros de datos, centrándose en la baja latencia y la comunicación confiable. Al simplificar el manejo de datos y mejorar la forma en que se gestionan los errores, RIFL permite que los protocolos de capas superiores simplifiquen sus procesos. A medida que los centros de datos continúan creciendo, RIFL establece las bases para futuros desarrollos, como la comunicación multi-hop sin congestión.