Es hora de reemplazar TCP en el centro de datos

A pesar de su larga y exitosa historia, TCP no es adecuado para los centros de datos modernos. Cada elemento importante de TCP, desde su orientación de flujo hasta su expectativa de entrega de paquetes en orden, es inadecuado para el entorno del centro de datos. Los problemas fundamentales con TCP están demasiado interrelacionados como para solucionarlos de forma incremental; La única manera de aprovechar todo el potencial de rendimiento de las redes modernas es introducir un nuevo protocolo de transporte. Homa, un novedoso protocolo de transporte, demuestra que es posible evitar todos los problemas de TCP. Aunque Homa no es suitable con API con TCP, se puede integrar con marcos RPC para darle un uso generalizado.

Introducción

TCP, diseñado a finales de los años 1970, ha sido extraordinariamente exitoso y adaptable. Originalmente creado para una purple con alrededor de 100 hosts y velocidades de enlace de decenas de kilobits por segundo, TCP ha escalado a far de millones de hosts y velocidades de enlace de 100 Gbit/segundo o más. Sin embargo, la informática del centro de datos presenta desafíos sin precedentes para TCP. Con millones de núcleos muy próximos y aplicaciones que aprovechan miles de máquinas interactuando en escalas de tiempo de microsegundos, el rendimiento de TCP no es óptimo. TCP introduce gastos generales que limitan el rendimiento a nivel de aplicación, lo que contribuye significativamente al “impuesto al centro de datos”.

Este documento de posición sostiene que los desafíos de TCP en el centro de datos son insuperables. Cada decisión importante de diseño en TCP es incorrecta para el centro de datos, lo que genera importantes consecuencias negativas. Estos problemas afectan a los sistemas en múltiples niveles, incluida la purple, el software program del kernel y las aplicaciones. Por ejemplo, TCP interfiere con el equilibrio de carga, un aspecto crítico de las operaciones del centro de datos.

Requisitos para protocolos de transporte de centros de datos

Antes de analizar los problemas de TCP, es esencial comprender los desafíos que debe abordar cualquier protocolo de transporte para centros de datos:

1. Entrega confiable: El protocolo debe garantizar que los datos se entreguen de manera confiable de un host a otro, a pesar de las fallas transitorias.
2. Baja latencia: El {hardware} de purple moderno permite tiempos de ida y vuelta de unos pocos microsegundos para mensajes cortos. El protocolo de transporte no debe aumentar significativamente esta latencia.
3. Alto rendimiento: El protocolo debe admitir un alto rendimiento de datos y un alto rendimiento de mensajes, lo que es esencial para patrones de comunicación como la transmisión y la reproducción aleatoria.
4. Management de congestión: El protocolo debe limitar la acumulación de paquetes en las colas de la purple para proporcionar una latencia baja.
5. Equilibrio de carga eficiente: Con velocidades de purple en rápido aumento, el protocolo debe distribuir la carga entre múltiples núcleos para mantenerse al día con los enlaces de alta velocidad.
6. Descarga de tarjeta de purple: Los protocolos de transporte basados ​​en software program se están volviendo obsoletos. Los protocolos futuros deben pasar a {hardware} NIC de propósito especial para proporcionar un alto rendimiento a un costo aceptable.

Todo lo relacionado con TCP está mal

Las propiedades clave de TCP, incluida la orientación del flujo, la orientación de la conexión, el uso compartido del ancho de banda, el management de la congestión impulsado por el remitente y la entrega de paquetes en orden, son todas incorrectas para el transporte del centro de datos. Cada una de estas decisiones tiene graves consecuencias negativas:

1. Orientación de la corriente: El modelo de flujo de bytes de TCP no es adecuado para aplicaciones de centros de datos, que normalmente intercambian mensajes discretos. Este modelo introduce complejidad y gastos generales, como mantener el estado de los mensajes parcialmente recibidos.
2. Orientación de la conexión: TCP requiere un estado de conexión de larga duración para cada par, lo que genera altos gastos generales. Esto es problemático para entornos de centros de datos donde las aplicaciones pueden tener cientos o miles de conexiones.
3. Compartir ancho de banda: El enfoque de programación justa de TCP funciona mal bajo carga, discriminando en gran medida los mensajes cortos, que son críticos en entornos de centros de datos.
4. Management de congestión impulsado por el remitente: El management de la congestión de TCP se ve obstaculizado por su dependencia de la ocupación del buffer y la falta de colas de prioridad, lo que genera un dilema en el que es difícil optimizar tanto la latencia como el rendimiento.
5. Entrega de paquetes en orden: La suposición de TCP de entrega de paquetes en orden restringe el equilibrio de carga, lo que genera puntos críticos tanto en el {hardware} como en el software program y, en consecuencia, una alta latencia de cola.

TCP no tiene reparación

Es poco possible que las soluciones incrementales a TCP tengan éxito debido a la naturaleza profundamente arraigada e interrelacionada de sus problemas. Por ejemplo, el management de congestión de TCP se ha estudiado ampliamente y, si bien se han realizado mejoras como DCTCP, sólo serán posibles mejoras adicionales significativas si se rompen algunos de los supuestos fundamentales de TCP.

Homa: un rediseño desde cero

Homa representa un rediseño desde cero del transporte de purple para el centro de datos. Su diseño se diferencia del TCP en todos los aspectos importantes:

1. Mensajes: Homa se basa en mensajes e implementa llamadas a procedimientos remotos (RPC). Esto permite un equilibrio de carga más eficiente y una programación de ejecución hasta su finalización.
2. Sin conexiones: Homa no tiene conexión, lo que elimina la sobrecarga de configuración de la conexión y permite que un solo socket administre cualquier número de RPC simultáneos.
3. SRPT: Homa implementa la programación del tiempo de procesamiento restante más corto (SRPT) para favorecer mensajes más cortos, utilizando colas de prioridad en conmutadores modernos.
4. Management de congestión impulsado por el receptor: Homa gestiona la congestión desde el receptor, que tiene conocimiento de todos sus mensajes entrantes, lo que lo posiciona mejor para gestionar la congestión.
5. Paquetes fuera de servicio: Homa puede tolerar llegadas de paquetes desordenados, lo que proporciona más flexibilidad para el equilibrio de carga y elimina potencialmente la congestión del núcleo.

Llegar desde aquí

Reemplazar a TCP será difícil debido a su estatus arraigado. Sin embargo, la integración de Homa con los principales marcos RPC como gRPC y Apache Thrift puede hacer que su uso se generalice. Este enfoque permite que las aplicaciones que utilizan estos marcos cambien a Homa con poco o ningún trabajo.

Conclusión

TCP es el protocolo incorrecto para la informática de centros de datos. Cada aspecto de su diseño es inadecuado para el entorno del centro de datos. Para eliminar el 'impuesto a los centros de datos', debemos pasar a un protocolo radicalmente diferente como Homa. Integrar Homa con marcos RPC es la mejor manera de darle un uso generalizado. Para obtener más información, puede consultar el documento técnico. Es hora de reemplazar TCP en el centro de datos.

Debes iniciar sesión para comentar.

Iniciar sesión