RoCE設計課題 - yuuk1's Digital Garden

# RoCE設計課題 ## 定義 RoCE(RDMA over Converged Ethernet)の設計課題とは、InfiniBand 由来のプロトコル設計がハイパースケールデータセンタの実運用環境で引き起こす構造的な非効率・不整合の総体である。[[@2023__IEEE Computer__Datacenter Ethernet and RDMA - Issues at Hyperscale]] は 8 項目に体系化した。RoCE は 2000 年代〜2010 年代初期の単純 HPC 向けハードウェアを前提として設計されており、帯域が 100 倍、メッセージレートが 10 倍以上拡大した現在の環境に適合しなくなっている。 ## 8 つの設計問題(Hoefler+ IEEE Computer 2023 より) 1. **PFC の過大なヘッドルームバッファ要求** — 無損失転送のためスイッチに `BW×RTT + MTU` 以上のバッファを専有させる。スイッチ帯域が 2 年ごとに 2 倍(Tomahawk 系列)になるとヘッドルームも比例拡大し、転送用バッファが圧迫される。 2. **被害フロー・輻輳ツリー・PFC ストーム・デッドロック** — PFC は 3 ビットのトラフィッククラス単位で停止するためヘッドオブラインブロッキングを生じ、輻輳が上流へ伝播する「輻輳ツリー」を形成する。 3. **Go-back-N 再送** — パケット 1 つの喪失で `BW×RTT` 全量を再送し、マルチパスやアウトオブオーダー配送と本質的に非互換。 4. **輻輳制御と他トラフィックとの共存の困難さ** — ECN ベースの速度制御は lossless 前提と密結合でベンダー間互換性がなく、OBS ワークロードの静的通信パターンを活かせない。 5. **大きなヘッダとスケーラビリティ課題** — RoCEv2 の 66 B ヘッダは 8 B メッセージ時に 90% 近くをヘッダが占め、キューペアベースの接続状態も大規模展開でスケールに課題を持つ。 6. **スマートスタックのサポート不足** — ハードウェアアクセラレーション前提でプロトコル定義の柔軟性がなく、Smart NIC の拡張性や QUIC のようなアプリ定義プロトコルに対応できない。 7. **セキュリティの設計上の弱さ** — マルチテナント環境での認証・暗号化が後付けになり、メモリリージョンの仮想アドレス公開によるプロセスレイアウト漏洩リスクがある。 8. **リンクレベル信頼性の複雑化** — PAM4 エンコードで BER が 1e-4 に達しうる中で RS544 FEC は帯域増大にも一定のレイテンシコストを持ち、将来の 100G/200G レーンでは不十分になる可能性がある。 ## 横断的知見 - **長距離RDMAではPFC headroomとトランスポート完了遅延が同じBDPの影響を受ける**: [[@2025__JANOG55__AI ML基盤におけるGPU間ネットワークの負荷と性能影響を探る]]は、札幌〜稚内約300kmで片道約1.5msの光遅延を想定し、RDMA WriteのWrite Lastに対するACKが返るまで処理が完了しないことを示す。また、PAUSE後のin-flightパケットを吸収するheadroom bufferの必要量が距離・帯域・流量で変化すると整理する。Azure Storageの最大100km事例が数GBのPFC headroomを必要とするのと合わせると、長距離化は単に帯域を増やす問題ではなく、ACK待ち時間と無損失バッファを同時に設計する問題になる。(Source: [[@2025__JANOG55__AI ML基盤におけるGPU間ネットワークの負荷と性能影響を探る]], [[@2023__NSDI__Empowering Azure Storage with RDMA]]) - **RoCE の 3 大問題(フロー衝突・インキャスト・障害収束)は上位レイヤで吸収する方向へ分岐している**: Hoefler+ 2023 はプロトコル自体の再設計を処方箋として示す一方、[[@2026__LinkedIn__Resilient AI Supercomputer Networking - How MRC and SRv6 Keep 100,000+ GPUs Training]] の [[MRC]] は RC トランスポートをパケットスプレー型に拡張しアプリ層で吸収する。「プロトコルの下を変える」(次世代 Ethernet)vs「プロトコルの上で吸収する」(MRC/SRv6)の二方向が並走している。(Source: [[@2023__IEEE Computer__Datacenter Ethernet and RDMA - Issues at Hyperscale]], [[@2026__LinkedIn__Resilient AI Supercomputer Networking - How MRC and SRv6 Keep 100,000+ GPUs Training]]) - **PFC 問題は診断の難しさとしても現れる**: Hoefler+ 2023 が設計欠陥として挙げる PFC の輻輳ツリーとストームは、[[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]] が「P4 データプレーンで PFC 因果来歴を追跡しなければリアルタイムに診断できない」という形で観測困難性として再確認している。設計欠陥が診断の複雑性を直接引き起こしている。(Source: [[@2023__IEEE Computer__Datacenter Ethernet and RDMA - Issues at Hyperscale]], [[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]]) - **ヘッダサイズ問題は AI 学習の集合通信での fine-grained な通信にとって特に深刻**: 問題 5 で論じられる 8 B メッセージ時の 90% ヘッダオーバーヘッドは、[[集合通信]] における単一要素削減(allreduce の最小メッセージ)や細粒度グラフ更新で顕現する。これは [[集合通信]] ページで議論する帯域対レイテンシのトレードオフの根本にある。(Source: [[@2023__IEEE Computer__Datacenter Ethernet and RDMA - Issues at Hyperscale]]) - **PFC の最適バッファプロファイルはケーブル長・スイッチ種別で異なり、単一の万能設定が存在しない**: [[@2025__SpeakerDeck__AIインフラを考える]] は、同一 DC ルーム内(ケーブル長 50m 未満)ではデフォルト値で問題にならない一方、コンテナ DC のような物理制約下で長距離接続(300m 超)が混在すると回線帯域・正確な線路長・Switch ASIC 固有パラメータからの計算が必要になり、さらに Shallow Buffer Switch と Deep Buffer Switch が混在する経路(スイッチ A・B・C)では A〜C それぞれで適切なバッファプロファイルが異なることを示した。これは Hoefler+ 2023 が指摘する「PFC の過大なヘッドルームバッファ要求」(問題 1)が、単一クラスタ内でも配線トポロジの異種性によって一様な解を持たないことを実運用の視点から補強する。(Source: [[@2025__SpeakerDeck__AIインフラを考える]], [[@2023__IEEE Computer__Datacenter Ethernet and RDMA - Issues at Hyperscale]]) - **10 万+ GPU クラスタが単一建屋を超えると、レイテンシ階層そのものがネットワーク階層(ラック→AI Zone→建屋)に沿って定量化可能な構造を持つ**: [[@2026__SIGCOMM__Connecting 100K+ GPUs - Building the Communication Stack for Large-Scale LLM Training]] は、Meta の多建屋 RoCE ファブリックでラック内比のレイテンシがラック間で約 7×、AI Zone 間(同一建屋内)で約 15×、建屋間で約 30× に増加することを報告し、これが「クラスタ規模拡大に伴う本質的な帰結であり、同一建屋内でも発生する」と明記する。本ページが集約してきた RoCE の設計課題(PFC ヘッドルーム・輻輳ツリー・ヘッダオーバーヘッド等)は主にプロトコルレベルの構造的欠陥を扱うのに対し、この知見は「トポロジの階層深さそのものが BDP(帯域幅遅延積)を規定し、フロー制御パラメータ(DQPLB の QP 数・セグメントサイズ)を接続種別ごとに変える必要がある」という、物理的スケールアウトが RoCE 設計に課す追加制約を加える。(Source: [[@2026__SIGCOMM__Connecting 100K+ GPUs - Building the Communication Stack for Large-Scale LLM Training]], [[@2023__IEEE Computer__Datacenter Ethernet and RDMA - Issues at Hyperscale]]) - **問題 1(PFC ヘッドルーム)と問題 3(go-back-N)は、2018 年時点で既にプロトコル自体の変更ではなく NIC ファームウェアレベルの変更で解消可能だと実証されていた**: [[@2018__SIGCOMM__Revisiting Network Support for RDMA]](IRN、SIGCOMM '18)は、Hoefler+ 2023 が体系化する 8 項目のうち問題 1(PFC ヘッドルーム)・問題 2(輻輳ツリー・PFC ストーム)・問題 3(go-back-N 再送)を、スイッチ側の変更なしに RoCE NIC への 2 つの小変更(SACK ベースロス回復・BDP-FC)だけで解消できることを実証し、追加ハードウェアオーバーヘッドは NIC リソースの 3〜10% に留まると FPGA 合成で定量化した。Ultra Ethernet(UE 1.0)がこれらの問題をプロトコル全体の再設計(NSCC+RCCC 等)で解決するのに対し、IRN は「現行 RoCE の枠組みを保ったまま NIC のみを変更する」という、より軽量な解決経路が 5 年以上前から存在していたことを示す。UE の設計判断(パケットスプレー・SACK・ゼロ RTT)の一部は、IRN が示した「ロス回復の効率化が輻輳制御より寄与が大きい」という要因分析結果と方向性が一致する。(Source: [[@2018__SIGCOMM__Revisiting Network Support for RDMA]], [[@2023__IEEE Computer__Datacenter Ethernet and RDMA - Issues at Hyperscale]], [[@2025__arXiv__Ultra Ethernet's Design Principles and Architectural Innovations]]) - **技術的実証(2018)から業界の課題体系化(2023)まで 5 年の遅延があり、その間 IRN は実運用へ展開されなかった**: IRN は Mellanox を含む商用 NIC ベンダーとの議論を経て「次リリースでの実装を検討」と論文に記載されたが、Hoefler+ 2023 が同じ問題(PFC・go-back-N)を依然として未解決の設計課題として報告していることから、少なくとも 2023 年時点では RoCE の主流実装に反映されていなかったことがわかる。これは、単一の学術的実証が業界標準を変えるには、NIC ベンダーのロードマップ・後方互換性・エコシステム全体の足並みという別の障壁が存在することを示唆する。(Source: [[@2018__SIGCOMM__Revisiting Network Support for RDMA]], [[@2023__IEEE Computer__Datacenter Ethernet and RDMA - Issues at Hyperscale]]) - **RoCE のロス回復方式(go-back-N)がロスレス前提を要求するという因果関係は、学術的体系化(2023)に先立って実務者コミュニティでも認識されていた**: [[Masayuki Kobayashi]] は2023年6月12日の「AI/ML/HPCネットワーク分科会」発表で、「通常のIPネットワークであればパケットドロップをTCPの仕組みなどで回復させるが、RDMAのキューではそれは不可能であり、パケット損失による性能低下が著しい」「RDMAはロスレスネットワークを前提として考案された手法」と述べ、Go-Back-Nの再送方式そのものを図解した。これは Hoefler+ 2023(問題3)がまとめる論点を、体系化論文の公刊に先立ち実務者が自らの言葉で整理していたことを示す。同発表はさらに「Web Scale Network はフローを区別しないため RDMA を支援できず、マルチテナントクラウドは非常に "Lossy" なネットワークになる」と述べ、フロントエンド(Web Scale)/バックエンド(AI/ML)ネットワークの分離を独立に提唱していた。(Source: [[@2023__SpeakerDeck__クラウドデータセンターネットワークのいまとこれから]], [[@2023__IEEE Computer__Datacenter Ethernet and RDMA - Issues at Hyperscale]]) - **PFC の Head-of-Line Blocking と輻輳ツリー(問題2)を回避するための実践的スペクトラムとして、Lossless/Semi-lossless/Lossy-1/Lossy-2 という段階的構成が存在する**: [[@2023__SpeakerDeck__RDMAネットワークアーキテクチャ基礎 - IB／RoCE 編 -]] は、PFC が3ビットのトラフィッククラス単位で停止するために生じる Head-of-Line Blocking を図解した上で(Hoefler+ 2023 の問題2と同じ現象)、全 switch/NIC で ECN+PFC を有効化する Lossless 構成が「NIC受信輻輳」「スイッチ輻輳」「PFCの他スイッチ/NIC送信側への伝播」という3つのリスクを持つことを示す。これに対し、NIC-スイッチ間のみ単方向PFCとする Semi-lossless、PFCを排し End-to-End ECN のみとする Lossy-1、PFC/ECNいずれも使わずSelective Repeatに委ねる Lossy-2 という緩和構成を並置する。これは Hoefler+ 2023 が「PFCの構造的欠陥」として体系化した問題2に対し、プロトコル自体を変えずに構成(configuration)のレベルで段階的にリスクを引き下げる実務上の対処法を具体化するものであり、[[@2018__SIGCOMM__Revisiting Network Support for RDMA]](IRN)の「NICのみの変更でPFC依存を解消する」というハードウェアレベルの解法とも、Ultra Ethernet の「プロトコル全体を再設計する」という解法とも異なる、第三の軽量な対処(運用構成の選択)を追加する。(Source: [[@2023__SpeakerDeck__RDMAネットワークアーキテクチャ基礎 - IB／RoCE 編 -]], [[@2023__IEEE Computer__Datacenter Ethernet and RDMA - Issues at Hyperscale]]) - **DCB(Data Center Bridging)は ETS+PFC+CN の3規格の組み合わせとして定義され、RoCEv1/v2 で使用する優先度フィールド(PCPベース/DSCPベース)が異なる**: [[@2023__SpeakerDeck__RDMAネットワークアーキテクチャ基礎 - IB／RoCE 編 -]] は、ロスレスイーサネットが 802.1Qaz(ETS)+802.1Qbb(PFC)+802.1Qau(CN)の3技術で実現されることを整理し、PCPベースPFC(VLANタグの3bit、RoCEv1で使用)とDSCPベースPFC(IPヘッダ、RoCEv2で使用、DSCP 26でマーキング)の違いを明示する。これは RoCEv1→v2への移行がL3フォワーディング対応だけでなく、優先度制御の情報源をL2フィールド(PCP)からL3フィールド(DSCP)へ移す変更を伴うことを示し、Hoefler+ 2023 が問題4として挙げる「ECNベースの速度制御とlossless前提の密結合」の具体的な設定機構(どのフィールドで輻輳制御と優先度制御を紐付けるか)を補足する。(Source: [[@2023__SpeakerDeck__RDMAネットワークアーキテクチャ基礎 - IB／RoCE 編 -]], [[@2023__IEEE Computer__Datacenter Ethernet and RDMA - Issues at Hyperscale]]) - **IRN(RNIC-SR)の「NIC のみの変更で PFC 依存を解消する」という軽量解決経路には、パケットレベル負荷分散(LB)との構造的非互換という未解決の技術的限界があった**: [[@2025__SIGCOMM__Revisiting RDMA Reliability for Lossy Fabrics]](DCP、SIGCOMM '25)は、IRN が前提とする単一経路(ECMP)伝送とビットマップベースの選択的再送(SR)が、パケットレベル LB(adaptive routing 等)と組み合わさると OOO(out-of-order)到着を誤ってロスと判定し、大量の偽の再送(spurious retransmission)を引き起こすことを NS3 実験で定量化した(フローサイズ帯に応じ 50〜90% のフローが影響を受ける)。これは 3 未解決の問いで提起した「IRN が 2026 年時点で主流展開に至っていない理由」の一部に技術的回答を与える——IRN の限界は「集合通信パターンへの影響が未評価」という一般論ではなく、**パケットレベル LB という 2018 年当時まだ普及していなかった技術との非互換性**という具体的な構造的欠陥だった。DCP は「制御プレーンのみを無損失に保ち、データプレーンは有損失のまま許容する」という非対称設計でこの非互換性を解消し、IRN が示した「NIC のみの変更で PFC 依存を解消する」という方向性を維持したまま、パケットレベル LB 互換性(Ultra Ethernet や MRC が目指す方向性の一部)を追加で満たす後継設計として位置づけられる。(Source: [[@2025__SIGCOMM__Revisiting RDMA Reliability for Lossy Fabrics]], [[@2018__SIGCOMM__Revisiting Network Support for RDMA]]) - **RoCEv2の閉域化は、設計上の課題を消すのでなく適用範囲と障害ドメインを限定する**: [[@2025__LY Corporation__AIインフラ革命 ─ 米国データセンターとGPUを支える技術基盤（Rethinking AI Infrastructure Part 1）]]は、サービス用100Gbps網とGPU間400Gbps RoCEv2網を分離し、後者を閉じた3層Closとして構成する。[[RoCE設計課題]]が扱うPFC、輻輳ツリー、リンク信頼性の問題は残るが、汎用サービス網へ同じ前提を広げず、GPU間通信の閉じた領域へ限定する運用上の緩和策になる。(Source: [[@2025__LY Corporation__AIインフラ革命 ─ 米国データセンターとGPUを支える技術基盤（Rethinking AI Infrastructure Part 1）]]) - **RoCEv2の性能優位性は、ロスレス性だけでなくnetdev制御経路とIB verbsデータ経路の分離に依存する**: [[@2025__Netdev 0x19__AI Networking - RoCEv2 and netdev]] は、同一ConnectX-7でsocket networkingの単一フロー215-220Gbpsに対してRoCEv2が392Gbpsに達する比較を示す。socket経路の`skb`生成、ページプール、softirq、システムコールを避け、ユーザー管理キューとNICオフロードでペイロードを順序どおりに配置するためである。したがってRoCEの課題をPFC・Go-Back-Nだけで評価せず、制御情報をnetdevへ、データ処理をIB hardwareへ配置する責任境界も含めて評価すべきである。(Source: [[@2025__Netdev 0x19__AI Networking - RoCEv2 and netdev]]) - **400GbE RoCEv2 の実運用課題は、プロトコル仕様だけでなく物理部材と検証工程へ広がる**: [[@2023__JANOG52__AI ML基盤の400G DCネットワークを構築した話]] は、PFC・ECN/CNP・ETS の動作に加えて、400G-DR4 の規格差、OSFP-RHS と QSFP-DD の相互接続性、純正品と 3rd party 製品のリンクアップ挙動を事前検証の対象にした。RoCEv2 の性能・信頼性は、スイッチや NIC の論理設定だけでなく、光部材の組み合わせと運用時に取得できる光レベル・温度・シリアル番号にも依存する。(Source: [[@2023__JANOG52__AI ML基盤の400G DCネットワークを構築した話]]) - [8 つの設計問題] MRC 自身の一次資料([[@2026__arXiv__The Multipath Reliable Connection (MRC) Transport]])は、UE のようなクリーンスレート仕様ではなく RC を直接拡張する漸進的アプローチを明示的に選択理由として述べる: クリーンスレート設計は新規ハードウェア・新規ソフトウェアスタック・数年規模の相互運用性成熟を要するのに対し、MRC は RC のセマンティクス・ソフトウェアモデルを保持しつつ単一パス(問題3: Go-back-N)・輻輳制御(問題4)・障害脆弱性(問題2)に対応する直交プリミティブを追加する設計を取る。MRC は AMD・Broadcom・Microsoft・NVIDIA・OpenAI・Intel の 6 社が共著し Open Compute Project の下で標準化されており、既に本番稼働している点も明記されている。「UE・Falcon v1.1・MRC のいずれが主流になるか」という既存の未解決の問いに対して、MRC は業界の非互換な選択肢の一つではなく『既存 RC ハードウェアからの漸進的移行経路』という差別化軸を主張していることが分かる。ただし RC-MRC 間は非互換な新オペコード空間を用いるため、RC からの移行自体はエンドポイント双方の更新を要し、UE との相互運用性についても本論文は言及していない。 - [Go-back-N再送とヘッダ/接続状態スケーラビリティ] IRN(SIGCOMM'18)がgo-back-Nをselective repeatへ置き換えPFCを排除する一方で新たなオンチップデータ構造(bitmap・reordering buffer・outstanding request table)を追加し3〜10%のメモリオーバーヘッドを生む。SRNICはヘッダ拡張(未処理要求メタデータをパケットヘッダに載せる)とbitmap onloading(ホストメモリへの退避)によりこれらのデータ構造をオンチップから完全排除し、selective repeat採用によるメモリ増大という課題5(スケーラビリティ)の一側面を定量的に解消した(Source: [[@2023__NSDI__SRNIC - A Scalable Architecture for RDMA NICs]])。 ## 未解決の問い - 400GbE 世代の RoCEv2 構築で確認された、Go-back-N による損失影響、PFC/ECN/ETS の QoS 設定、トランシーバー相互接続性の検証項目は、800GbE・1.6TbE 世代でどのように再定義されるか。([[@2023__JANOG52__AI ML基盤の400G DCネットワークを構築した話]], [[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]]) - 100km超のRDMAで、PFC headroom、ACK遅延、Work Request/Completion Queueの滞留を、AI/MLジョブの計算時間とどう統合して性能限界として評価するか。([[@2025__JANOG55__AI ML基盤におけるGPU間ネットワークの負荷と性能影響を探る]]) - Lossless/Semi-lossless/Lossy-1/Lossy-2 という構成スペクトラムは、どの規模・トポロジ・ワークロード特性でどの構成が最適になるかの定量的な判断基準を持つか。[[@2023__SpeakerDeck__RDMAネットワークアーキテクチャ基礎 - IB／RoCE 編 -]] は定性的な選択肢の提示に留まり、実運用でのトレードオフ(スループット・レイテンシ・パケットロス率)の定量比較は示していない。 - ~~次世代 Ethernet が「lossy/lossless 選択可能」になった場合、現在の DCQCN/TIMELY/HPCC のような輻輳制御は何が変わるか~~ → UE 1.0 は NSCC(ECN+RTT)と RCCC(受信クレジット)の 2 アルゴリズムを定義した。PFC なしで有損失ネットワーク上で動作する設計が実装に向かっている。残課題は「NSCC+RCCC 同時動作の収束安定性」の定量検証。([[@2025__arXiv__Ultra Ethernet's Design Principles and Architectural Innovations]])。[[HPCC]]([[@2019__SIGCOMM__HPCC - High Precision Congestion Control]])はロスレス(PFC 前提)環境での INT ベース高精度制御であり、UE の lossy 設計とは前提が異なる——INT による直接測定という発想が UE の NSCC(ECN+RTT の組み合わせ)にどこまで応用可能かは未検証。 - RoCE の設計限界はスーパーコンピュータ向け InfiniBand / HPE Slingshot との競争でどう位置づけられるか。Slingshot のチームが本論文を共著しているのは、Ethernet 側の改革を求める訴求か。 - セキュリティ(問題 7)は、機密コンピューティング(Confidential Computing)が普及した場合にどう変わるか。RDMA + TEE の組み合わせは実現可能か。UE TSS は PCIe TDISP との連携を視野に入れているが、実装がどこまで進むか。 - FEC の選択(RS544 vs LL-FEC vs Firecode)はレイテンシとエラー訂正能力のトレードオフを生じる。400G/800G 超での最適解はあるか。 - UE・Falcon v1.1・MRC という 3 つの「RoCEv2 代替」はそれぞれ異なる組織が独立開発したが、AI クラスタの主流はどれになるか。相互運用性はどこまで実現されるか。 - ~~IRN(2018)が示した「NIC のみの変更で PFC 依存を解消できる」という軽量な解決経路は、2026 年時点でなぜ主流展開に至っていないのか。UE・Falcon・MRC のようなプロトコル全体の再設計が優先された理由は、IRN のアプローチに何らかの技術的限界(集合通信パターンへの影響が未評価、OOO 配送のメモリ上書き問題をアプリケーション任せにしている等)があったためか~~ → 技術的限界の一つが特定された:IRN(RNIC-SR)はパケットレベル LB と構造的に非互換で、組み合わせると偽の再送を大量発生させる([[@2025__SIGCOMM__Revisiting RDMA Reliability for Lossy Fabrics]])。ただし業界の意思決定プロセス(標準化・ベンダー間協調)側の障壁が主因かどうかは依然未検証。残る問い: DCP(2025)自身も IRN と同じく学術プロトタイプ段階(P4 スイッチ+FPGA)に留まり、商用 RNIC ベンダーとの統合表明はない。DCP は IRN と同じ「実証から商用化までの遅延」を繰り返すのか、それとも UE のような業界コンソーシアム主導の標準化と接続する経路を持つのか。 - DCP のビットマップフリーなパケット追跡は「無損失制御プレーン(exactly once)」という前提に強く依存し、この前提が破れる(リンク/スイッチ障害)場合はコースグレインタイムアウトへフォールバックせざるを得ないと論文自身が認めている。IRN のビットマップベース SR がステートフルだが障害に対して local に頑健なのに対し、DCP のステートレス設計は無損失 CP という**グローバルな不変条件**に依存する。この依存が実運用のスイッチ故障率・リンク不安定性のもとでどの程度の頻度でフォールバックを引き起こすかは、testbed 実験(§6)でも定量化されていない。([[@2025__SIGCOMM__Revisiting RDMA Reliability for Lossy Fabrics]]) - RoCEv2を閉域GPU網へ限定する設計は、PFC・ECN・FECなどの障害対応をどの運用境界で担うかを明確にする一方、GPU網とサービス網の間にまたがる障害・テナント通信・監視をどう統合するか。 ## 関連 - 概念: [[RDMA]] / [[RDMAネットワーク監視]] / [[オープンネットワーキング]] / [[集合通信]] / [[Ultra Ethernet]] / [[マルチテナントRDMA性能分離]] - ソース: [[@2025__LY Corporation__AIインフラ革命 ─ 米国データセンターとGPUを支える技術基盤（Rethinking AI Infrastructure Part 1）]] / [[@2026__arXiv__The Multipath Reliable Connection (MRC) Transport]] / [[@2023__NSDI__SRNIC - A Scalable Architecture for RDMA NICs]] - エンティティ: [[Torsten Hoefler]] / [[ETH Zürich]] / [[Hewlett Packard Enterprise]] / [[Broadcom]] / [[Microsoft]] / [[Google]] / [[Masayuki Kobayashi]] / [[DCP]] - ソース: [[@2023__IEEE Computer__Datacenter Ethernet and RDMA - Issues at Hyperscale]] / [[@2025__arXiv__Ultra Ethernet's Design Principles and Architectural Innovations]] / [[@2025__SpeakerDeck__AIインフラを考える]] / [[@2026__SIGCOMM__Connecting 100K+ GPUs - Building the Communication Stack for Large-Scale LLM Training]] / [[@2019__SIGCOMM__HPCC - High Precision Congestion Control]] / [[@2018__SIGCOMM__Revisiting Network Support for RDMA]] / [[@2023__SpeakerDeck__クラウドデータセンターネットワークのいまとこれから]] / [[@2023__SpeakerDeck__RDMAネットワークアーキテクチャ基礎 - IB／RoCE 編 -]] / [[@2025__SIGCOMM__Revisiting RDMA Reliability for Lossy Fabrics]] ## 出典 - [[@2023__IEEE Computer__Datacenter Ethernet and RDMA - Issues at Hyperscale]] — 8 項目の課題分類と次世代 Ethernet 予測の主出典 - [[@2025__arXiv__Ultra Ethernet's Design Principles and Architectural Innovations]] — UE 1.0 が問題 1(PFC)・3(Go-back-N)・5(スケーラビリティ)・7(セキュリティ)を具体的に解決した設計の主出典 - [[@2025__SpeakerDeck__AIインフラを考える]] — PFC バッファプロファイルがケーブル長・スイッチ種別で異なる実運用課題を具体化 - [[@2026__SIGCOMM__Connecting 100K+ GPUs - Building the Communication Stack for Large-Scale LLM Training]] — 多建屋 RoCE ファブリックのレイテンシ階層(ラック内比 7×/15×/30×)を定量化し、DQPLB の接続種別別パラメータ設計の直接の根拠とする - [[@2018__SIGCOMM__Revisiting Network Support for RDMA]] — 問題 1・2・3(PFC ヘッドルーム・輻輳ツリー・go-back-N)を NIC のみの変更(SACK ベースロス回復 + BDP-FC)で解消できることを 2018 年時点で実証した先行研究 - [[@2025__SIGCOMM__Revisiting RDMA Reliability for Lossy Fabrics]] — IRN(RNIC-SR)がパケットレベル LB と構造的に非互換であることを実証し、スイッチと RNIC の共設計([[DCP]])でこの限界を解消した後継研究 - [[@2023__SpeakerDeck__クラウドデータセンターネットワークのいまとこれから]] — go-back-N とロスレス前提の因果関係、Web Scale/AI-ML ネットワーク分離を学術的体系化に先立ち実務者視点で整理した資料 - [[@2023__SpeakerDeck__RDMAネットワークアーキテクチャ基礎 - IB／RoCE 編 -]] — DCB(ETS+PFC+CN)の構成要素、PFCのHead-of-Line Blocking、Lossless/Semi-lossless/Lossy-1/Lossy-2という運用構成スペクトラムを整理した基礎資料 - [[@2025__LY Corporation__AIインフラ革命 ─ 米国データセンターとGPUを支える技術基盤（Rethinking AI Infrastructure Part 1）]] — 400Gbps閉域RoCEv2 GPU間網と100Gbpsサービス網の分離構成。 - [[@2023__NSDI__SRNIC - A Scalable Architecture for RDMA NICs]](selective repeat採用時のオンチップメモリオーバーヘッドを解消する具体設計)