AIクラスタにTCPはもう不要、Homaが新時代を切り開く
Homa: The end of TCP for AI clusters [video]
Homaは、AIクラスタ向けに設計された新しいトランスポートプロトコルで、TCPの限界を超えることを目指している。USENIX ATC 2021で発表された論文を基に、Hacker Newsで議論が交わされた。TCPに代わるプロトコルとして注目を集めており、Stanfordの教授が提唱している。
Homa: The end of TCP for AI clusters
HNでの議論
23- Animats
Homaはずっと前からあります。これが2018年の論文です。[1]
核心となるアイデア：メッセージが送信側のトランスポートモジュールに到着すると、Homaはメッセージを2つの部分に分割します。最初のスケジュールされていない部分（最初のRTTbytesバイト）と、それに続くスケジュールされた部分です。
送信側は、1つ以上のDATAパケットを使用して、スケジュールされていないバイトを即座に送信します。スケジュールされたバイトは、受信側がGRANTパケットを使用して明示的に要求するまで送信されません。
つまり、短いリクエストに対してはブラインドで送信し、その後受信側からのゴーサインを必要とします。
これは、主なアプリケーションがリモートプロシージャコールである場合には合理的です。これは、QNXのネットワーキングプロトコルを思い起こさせます。これも単一パケットのメッセージ要求/応答ですが、任意の長さのメッセージも処理できます。
これが今日機能するのは、ハードウェアスイッチにおけるパケットあたりの処理オーバーヘッドが、バイトあたりのオーバーヘッドと比較して低いためです。初期のソフトウェアドリブンのスイッチでは、パケットあたりのオーバーヘッドが支配的になる傾向があり、小さなパケットの送信は非常に非効率的でした。FPGAが処理を行っている現代のハードウェアスイッチでは、パケットあたりのオーバーヘッドが十分に低いため、小さなパケットは非効率的ではありません。
今日のウェブ関連が非常に肥大化しているため、1MB未満のトランザクションが「小さい」と見なされるのは面白いことです。
したがって、これはオープンウェブでの使用には適したプロトコルではありません。
[1] https://people.csail.mit.edu/alizadeh/papers/homa-sigcomm18....
- Veserv
Homaは良い設計ではありません。[1]
1. RPC全体の損失を検出する方法がありません。外側の接続状態がないため、RPCの送信側のすべてのパケットが失われた場合、サーバーが再送を発行すべきことを検出する方法がありません。RPCはただ虚空に消えるだけです。これは、送信側のパケット数が少ないため、単一パケットに収まるメッセージのような小さなメッセージに、より影響します。
2. 上記に関連して、組み込みの暗号化サポートがありません。そのため、暗号化が必要な場合は、上位または下位にレイヤー化する必要があります。
3. ベンチマークされたパフォーマンスはひどいものです。[2]の表4にある60 kBの平均メッセージのケースでは、平均20 Gbit/sを出すのに5(!)個のハイパースレッドが必要です。これはハイパースレッドあたりわずか4 Gbit/sです。完全に素朴な、システムコールごとに1パケットというネットワークプロトコルの設計と実装でさえ、ハイパースレッドあたり約8 Gbit/sには達するはずです。少しパフォーマンスに焦点を当てるだけで、ハイパースレッドあたり30 Gbit/sは簡単です。
4. QUICにはパフォーマンス設計上の問題がすべてあるにもかかわらず（それでもHomaよりは速い）、Homaが解決しようとしている基本的にすべての問題を、はるかにクリーンな方法ですでに解決しています。ストリームIDはRPC IDに対応します。ストリームMaxはGrantsに対応します。単一のClientの下の複数のストリームにより優先順位付けが可能になります。
ただし、メッセージ全体をランダムに失うことはありません。小さなメッセージをパケットに詰め込むことができます。より正確なRTT時間が得られ、より正確なペーシング/輻輳計算が可能になります。組み込みの暗号化が得られます。硬化したミドルボックスを生き延びます。複数のackフレーム/パケットがあり、[…]を減らします