Homa: Das Ende von TCP für KI-Cluster
Homa: The end of TCP for AI clusters [video]
Ein Video und eine HN-Diskussion stellen Homa vor, ein neues Transportprotokoll, das TCP in KI-Clustern ersetzen soll. Der Ansatz stammt aus einem USENIX-ATC-Paper und wird von einem Stanford-Professor vorangetrieben, der für einen grundlegenden Wandel der Netzwerkschicht wirbt. Die Diskussion verlinkt das Paper sowie verwandte Artikel von LWN und The Register.
Homa: The end of TCP for AI clusters
- Animats
Homa gibt es schon eine Weile. Hier ist das Paper von 2018.[1]
Die Kernidee: Wenn eine Nachricht am Transportmodul des Senders ankommt, teilt Homa
die Nachricht in zwei Teile: einen anfänglichen, nicht eingeplanten Teil (die ersten RTTbytes Bytes), gefolgt von einem eingeplanten Teil.
Der Sender überträgt die nicht eingeplanten Bytes sofort, unter Verwendung
eines oder mehrerer DATA-Pakete. Die eingeplanten Bytes werden erst übertragen, wenn der Empfänger sie explizit mit GRANT-Paketen anfordert.
Also sendet er bei kurzen Anfragen blind, braucht dann aber eine Freigabe vom Empfänger.
Das ist sinnvoll, wenn die Hauptanwendung ein Remote Procedure Call ist. Es erinnert an das Netzwerkprotokoll von QNX, das ebenfalls Ein-Paket-Nachrichten-Anfrage/Antwort bietet, aber auch beliebig lange Nachrichten verarbeiten kann.
Was das heute funktionieren lässt, ist, dass der Verarbeitungsaufwand pro Paket in Hardware-Switches gering ist im Vergleich zum Aufwand pro Byte. In frühen softwaregesteuerten Switches dominierte der Aufwand pro Paket, und das Senden kleiner Pakete war sehr ineffizient. In modernen Hardware-Switches, wo FPGAs die Verarbeitung übernehmen, ist der Aufwand pro Paket niedrig genug, dass kleine Pakete nicht ineffizient sind.
Es ist amüsant, dass Web-Kram heute so aufgebläht ist, dass jede Transaktion unter 1 MB als "klein" gilt.
Das ist also kein geeignetes Protokoll für die Nutzung im offenen Web.
[1] https://people.csail.mit.edu/alizadeh/papers/homa-sigcomm18....
- Veserv
Homa ist kein gutes Design. [1]
1. Keine Möglichkeit, den Verlust eines ganzen RPC zu erkennen. Da es keinen äußeren Verbindungszustand gibt, kann ein Server, wenn jedes Paket auf der Sendeseite eines RPC verloren geht, nicht erkennen, dass er ein erneutes Senden veranlassen sollte. Der RPC ist einfach im Äther verloren. Dies betrifft kleine Nachrichten, wie Nachrichten, die in ein einzelnes Paket passen, stärker, da es weniger Pakete auf der Sendeseite gibt.
2. Im Zusammenhang damit gibt es keine eingebaute Verschlüsselungsunterstützung. Wenn man also Verschlüsselung will, muss man sie entweder darüber oder darunter schichten.
3. Die gemessene Leistung ist furchtbar. Der Fall mit durchschnittlich 60 kB Nachricht in [2] Tabelle 4 braucht 5(!) Hyperthreads, um durchschnittlich 20 Gbit/s zu erreichen. Das sind nur 4 Gbit/s pro Hyperthread. Selbst ein völlig naives Netzwerkprotokoll-Design und seine Implementierung mit einem Paket pro Systemaufruf sollte auf etwa 8 Gbit/s pro Hyperthread kommen. 30 Gbit/s pro Hyperthread sind mit nur ein wenig Fokus auf Leistung leicht zu erreichen.
4. Trotz all der Leistungsdesignprobleme in QUIC (obwohl immer noch schneller als Homa) löst es bereits im Grunde jedes Problem, das Homa zu lösen versucht, auf eine viel sauberere Weise. Stream-IDs entsprechen RPC-IDs. Stream Max entspricht Grants. Mehrere Streams unter einem einzigen Client ermöglichen Priorisierung.
Nur dass man nicht zufällig ganze Nachrichten verliert. Man kann kleine Nachrichten in Paketen kompakt zusammenfassen. Man bekommt präzisere RTT-Zeiten, was genauere Pacing-/Kongestionsberechnungen ermöglicht. Man bekommt eingebaute Verschlüsselung. Es überlebt verknöcherte Middleboxen. Es hat mehrere Ack-Frames/-Pakete, was die Anzahl der […] reduziert