動き始めた「Ultra Ethernet」とは何か？　そして、「IEEE P802.3dh」続報

「IEEE P802.3dh」続報。これは駄目かもしれない

　今回は、AMDが言及したことで再び話題になったUltra Ethernetの話をしたいと思うが、その前に、前回までの車載Ethernetに関して、Updateをお届けしておきたいと思う。

　前々回の最後では、IEEE P802.3dhの標準化に関して、「次の11月のミーティングでGo/NoGoの判断を下す必要があるというコメントが付いており」としたが、その11月のミーティングについて紹介した前回の原稿を書いていた時点では、まだ11月15日に開催されたMinutesが公開されていなかった。しかし、前回記事の公開直前にMinutesが公開されていたので、その内容を紹介する。

　11月15日のミーティングで、5つのプレゼンテーションが公開された後、議長の渡邊勇仁氏（AGC）からタイムラインのUpdateが示された。これに対し、BoschのSteve Carlson氏及び副議長を務めるKDPOFのRubén Pérez-Aranda Alonso氏の両方から、「スケジュールが非現実的すぎる」というコメントが付き、更にCarlson氏は"Request the IEEE 802.3 Working Group withdraw the IEEE P802.3dh PAR"というMotionを提起する。要するにP802.3dhは非現実的なので、Task Forceを解散しようという動議である。結果は？ というと、

• 賛成:13
• 反対:9
• 棄権:2

　ということで賛成多数ながら、IEEEのTask Forceの場合賛成が75%以上必要（今回は54.2%）ということでMotionは成立せず、引き続き仕様策定に向けて作業を続けることが決まった。次回はAd Hoc Meetingを11月29日に行うという話になっているが、現時点ではまだ詳細が公開されていない。

　なんというか、参加者の半数以上がすでに規格に対してやる気をなくしている、というあたりでTask Forceとしては結構厳しい状況になっているのが分かる。実際、このスライドを含むプレゼンテーションに対してのCarlson氏のコメントは"This is the fact. There is no project here. No adopted baseline. No progress. I make motion to withdraw PAR later today. If it fails, in WG tomorrow."で、相当腹に据えかねているものと思われる（Workgroupでの動議がどうなったのかは不明である）。

　筆者の個人的見解で言えば、A4iまでのPOFでは厳しいのはまぁ見えており、そこにA4jを突っ込むことで、新しいA4jのアプリケーションを開拓したいという意向の日本メーカーと、それに反発する欧州メーカー（ここには顧客であるBoschも含まれる）という図式に見える。問題はいまだにA4jが標準化が終わっていない規格なことで、渡邊氏がIECにおけるA4jの標準化作業の見込みを示したスライドに対しても、次のような厳しいコメントが並んでいる。

"This was not IEC proposal but your proposal."
"Not enough information to predict timeline."（OFSのG. Mabud Choudhury氏）
"IEC timeline, you don’t have control."
"This TF has not been productive long term."（Carlson氏）

　Pérez-Aranda氏もIEC Proposalは非現実的だ、としている。色々な意味で前途多難というか、かなり駄目そうな感じが伝わってくるのが現状である。IEEE P802.3dhについては以上。

2023年7月に立ち上がったUltra Ethernet Consortium（UEC）

　ということで、今月のお題は全然違う話である。今年7月19日、Linux FoundationはUltra Ethernet Consortium（UEC）を設立することを発表した（PC Watchの記事）。

　本連載でもこれまで多数の業界団体がさまざまな規格をConsortiumやらMSAやらのかたちで立ち上げてきた話を紹介しているので、こうした新規格（？）が別に珍しいわけではないのだが、12月6日にAMDがハイブリッドで開催したAdvancing AIというイベント（この基調講演はYouTubeで視聴できる）の中で、生成AIの興隆によりデータセンターのトラフィックが急増（以下の図1）、特にバックエンド側でより高速なネットワークが必要とされると説いた（図2）。

　そして、このGPUクラスタ間のInterconnectにUltra Ethernetを利用すると宣言し（図3）、更にSwitchベンダー3社のキーパーソンを集めてのPanelまで行った（図4）ことで、急に名前が持ち上げられるようになった。

図1：この縦軸はGPUクラスタの個数である。GPUクラスタの数が増える＝GPUクラスタで利用するデータ量が増える、という意味でもある

図2：向かって左がGPUクラスタ同士を接続するInterconnectに当たる部分で、ここがスケールアウトできなければいけない、としている。ちなみに説明しているのはAMDのForrest Norrod氏（EVP&GM, Data Center Solution Business Unit）

図3：この3つのファクターのうち"Open"に関しては、Mellanoxを手中に収めたNVIDIAが、InfiniBandベースのソリューションを提供していることに対する皮肉でもある

図4：左からJonathan Davidson氏（EVP&GM, Cisco Networking）、Jas Tremblay氏（VP&GM of Data Center Solutions Group, Broadcom）、Andy Bechtolsheim氏（Chairman&Chief Development Officer, Arista Networks）である

　ところでこのUltra Ethernetって一体何だ？　という話である。上記のPC Watchの記事を読んでも、漠然とした話しか書いてないので判りにくいと思うが、これは記事の責任ではなく、元々のリリースに漠然とした話しか書いてないのが理由である。ぶっちゃければ、まだ漠然とした話しか決まっていないというのが正しいところであろう。

　実はこのリリース直後にArista NetworkはUECに関する動画を公開している。これによればUECはOpenで相互接続性があり、高性能で、通信スタックベースのアーキテクチャをEthernet上に構築する、としている（図5）。具体的には、Founding Memberの9社でConsortiumを結成。この上でPhysical/Link/Transportの各LayerとSoftware Stackに関する分科会を作成し、それぞれ仕様を策定する作業を行ってゆくとする。

図5：説明を行っているのはArista NetworksのHardev Singh氏（Manager, Product Management）

図6：相互運用性を確保しつつ、またEthernetとの互換性を維持しながら、最小限の通信Stackを構築するという、一見すると両立が不可能ではないが中々困難な項目が並んでいる

RDMAに対する不満の解決がUECの狙い

　実は、この辺りまではまだよく狙いが分からないのだが、次の説明でやっとUECの狙いが腑に落ちた。説明によれば、現在Ethernet（やInfiniBand、というかそもそもがInfiniBand由来であるが）で使われているRDMAに対する不満がこちら（図7）である。

図7：MultipathingとかRecovery mechanismsなどはお説ごもっとも、ではあるのだが、そもそもそういうニーズが不要な場所向けに開発されたのがRDMAということを考えると、広範に使われるようになったことで、当初の想定外の使われ方をするようになった、というべきなのかもしれない

　RDMAのプリミティブな説明は以前こちらで行っているが、要するにLatencyを最小限にすべく余分な機能を全部取っ払ったのがRDMAであり、それゆえに不満も一杯ある、というわけだ。

　ちなみに、ここで挙がっているDCQCNは「Data Center Quantized Congestion Notification」の略で、ECN（Explicit Congestion Notification：明示的な輻輳通知）とPFC（Priority-based Flow Control：プライオリティベースのフロー制御。IEEE 80231QbbをベースにしたLink層ベースの制御方式）を組み合わせることで、パケットロスを最小に抑えるための仕組みである。DCQCNはRoCE（RDMA over Converged Ethernet）向けに開発された技法であるが、RDMAの仕様そのものにDCQCNが含まれているわけではない。

図8：MPIについての説明は以前こちらで紹介している。並列計算機では広範に使われているAPIだ

　利用されるアプリケーションとしては、従来型のAPIやMPIに加え、PGAS（Partitioned Global Address Space）も入っているのが興味深い。PGASは従来のMPIを超える超大型計算機（それこそFrontierやAuroraなどExascaleのHPCなどもターゲットに入っている）向けの分散プログラミング手法で、超巨大なメモリ空間が適当にパーティーショニングされ、それぞれのパーティーションと利用できるThreadが紐付いている（Affinity）というモデルに対応したものである。まだ利用頻度はMPIほど多くないが、今後増えてゆくであろうと予測されているAPI（というか、プログラミングモデル）である。このあたりももRDMA登場時にはなかったものだ。

　ということで、図7にある不満を解消しつつ、図8のような用途に向けると共に、こんな機能を持たせたい、というのが現在のUECの目標とされる（図9）。

図9：上の方は判るが、一番最後の"AI/ML optimized APIs"が今一つピンとこないし、White Paperを読んでも具体的な話が出てこない。この辺りは今後どういうものが出て来るのかを待ちたいところだ

　さて、以上のような説明を念頭にUECのサイトを見ると、Founding MemberにOracleを加えた10社がSteering Membersで、General Membersが15社、Contributor Memberが14社と、まずまずのスタートとなっている。NVIDIAが入っていないのは当然と言えば当然であるが、今ではWorking Groupは先の4つにStorage/Mamagement/Compliance/Performance Debugを加えた8つが活動を行っているそうで、仕様の策定に向けて活発に活動している様子が伺える。

　端的に言えば、UECはPCI Expressに対するCXLみたいなもので、既存のEthernetのハードウェアの上に独自の軽量プロトコルを載せて、Cluster Interconnectを構築する、といった趣のものになっている。実はこのCluster InterconnectにEthernetを使うというのは、CerebrasのWSE/WSE 2とかIntelのGaudi 2、TenstorrentのWormholeなどさまざまなAIプロセッサーが実装済みである。

　例えばGaudi 2の場合、1つのチップから21本の100GbEが出ており、これを3本づつ束ねてGaudi 2同士の接続や外部接続に利用している（図10）。そんなわけで物理的にはEthernetだが、その上は各社独自のプロトコルで相互接続に利用している。ここを標準化したい、というのがUECの目的ということであり、何かあたらしいEthernetを開発したいというわけではない（逆にハードウェア的には可能な限り既存のEthernetを使うことでコストを抑えたいと考えていると思われる）。

図10：Gaudi 2チップ同士の接続構成図。この8つのチップがシャーシ内に収められ、シャーシ間はQSFP-DDコネクタ経由で接続される格好である

　そんなわけでUECはいわゆる新しいEthernet規格、というのとはちょっと毛色が違っているのがお分かりいただけるかと思う。個人的な感想を言えば、どこかがたたき台を持ってきて、それをベースに標準化を行うわけではなさそうなあたり、標準化までには結構時間が掛かりそうに思える（という話は、以前こちらに書いた）。さて標準化が終わるまで、マーケットは待っていてくれるだろうか？