Homa quiere acabar con TCP en los clústeres de AI
Homa: The end of TCP for AI clusters [video]
El protocolo Homa propone reemplazar TCP en los clústeres de AI, donde las latencias y los patrones de tráfico de las cargas de trabajo distribuidas exigen un diseño distinto. El paper original se presentó en USENIX ATC 21 y un profesor de Stanford insiste en la necesidad de un nuevo protocolo para estas redes.
Stanford prof is beating the drum for a new protocol to replace TCP.
- Animats
Homa lleva un tiempo por ahí. Aquí está el artículo de 2018.[1]
La idea central: cuando un mensaje llega al módulo de transporte del emisor, Homa divide el mensaje en dos partes: una porción inicial no programada (los primeros RTTbytes bytes), seguida de una porción programada.
El emisor transmite los bytes no programados inmediatamente, usando uno o más paquetes DATA. Los bytes programados no se transmiten hasta que el receptor los solicite explícitamente mediante paquetes GRANT.
Así que envía a ciegas para solicitudes cortas, y luego necesita el visto bueno del receptor.
Eso es razonable cuando la aplicación principal es una llamada a procedimiento remoto. Recuerda al protocolo de red de QNX, que también es de solicitud/respuesta de mensaje de un solo paquete, pero que además puede manejar mensajes arbitrariamente largos.
Lo que hace que esto funcione hoy es que la sobrecarga de procesamiento por paquete en los switches de hardware es baja en comparación con la sobrecarga por byte. En los primeros switches controlados por software, la sobrecarga por paquete tendía a dominar, y enviar paquetes pequeños era muy ineficiente. En los switches de hardware modernos, donde las FPGA hacen el procesamiento, la sobrecarga por paquete es lo suficientemente baja como para que los paquetes pequeños no sean ineficientes.
Es divertido que las cosas de la web estén tan infladas hoy que cualquier transacción de menos de 1MB se considere "pequeña".
Así que este no es un protocolo adecuado para uso en la web abierta.
[1] https://people.csail.mit.edu/alizadeh/papers/homa-sigcomm18....
- Veserv
Homa no es un buen diseño. [1]
1. No hay forma de detectar la pérdida total de una RPC. Como no hay estado de conexión externo, si se pierde cada paquete del lado de envío de una RPC, entonces no hay forma de que un servidor detecte que debería emitir un reenvío. La RPC simplemente se pierde en el éter. Esto afecta más a los mensajes pequeños, como los que caben en un solo paquete, ya que hay menos paquetes en el lado de envío.
2. Relacionado con lo anterior, no hay soporte de cifrado integrado. Así que, si quieres cifrado, necesitas ponerlo en una capa por encima o por debajo.
3. El rendimiento medido en los benchmarks es horrible. El caso de mensaje promedio de 60 kB en [2] Tabla 4 requiere 5(!) hyperthreads para promediar 20 Gbit/s. Eso es solo 4 Gbit/s por hyperthread. Incluso un diseño e implementación de protocolo de red totalmente ingenuo de un paquete por llamada al sistema debería alcanzar ~8 Gbit/s por hyperthread. 30 Gbit/s por hyperthread es fácil con solo un poco de enfoque en el rendimiento.
4. A pesar de todos los problemas de diseño de rendimiento en QUIC (aunque sigue siendo más rápido que Homa), ya resuelve básicamente todos los problemas que Homa intenta resolver de una manera mucho más limpia. Los IDs de stream corresponden a los IDs de RPC. Stream Max corresponde a Grants. Múltiples streams bajo un solo Cliente permiten priorización.
Excepto que no pierdes mensajes enteros al azar. Puedes compactar mensajes pequeños en paquetes. Obtienes un tiempo RTT más preciso que permite cálculos de pacing/congestión más exactos. Obtienes cifrado integrado. Sobrevive a middleboxes osificados. Tiene múltiples frames/paquetes de ack reduciendo ac […]