Multipath Reliable Connection (MRC) 大規模AI学習ファブリックためマルチパスRoCEv2拡張トランスポート

顧客向け技術説明会（日本語）
OCP MRC Specification 1.0 (2026-03-21) ほか一次ソースに基づく技術解説
動作原理・パケットフォーマット・SRv6統合・UECとの比較

Transcript

1. Multipath Reliable Connection (MRC) 大規模AI学習ファブリックのためのマルチパスRoCEv2拡張トランスポート Technical Deep Dive 2026/06/30 Masayuki Kobayashi 01
2. Disclaimer: 仕様上の事実とポジショニングの分離 • 本資料の内容に関する最終判断では必ず原典を確認してください • 仕様上の事実は、主に OCP MRC 1.0 仕様書 [S1]、MRC Transport 論文 [S2]、OpenAI/Microsoft 運用論文 [S3] を基準に扱います • ベンダ文書・ブログ [S5]〜[S11][S17][S18] は、製品対応の自己申告やポジショニングを含む情報源として区別します • 第三者記事・分析は意見として扱い、仕様の根拠とは分けます • 文中の [Sx] は参考文献番号に対応します 02
3. Multipath Reliable Connection (MRC) とは • RoCEv2の拡張 に位置づけられる技術 • 主な用途を大規模 AI学習に限定 し、先行研究で成熟してきた仕組みを既存 RoCE環境へ早く投入するための production-orientedな限定実 装・仕様と整理できる • 目的は汎用RDMAではなく、大規模同期 AI学習ジョブ • 2026年にAMD・Broadcom・Intel・Microsoft・NVIDIA・OpenAIの共同貢献として OCP仕様化 Enabling AI Networking @ Scale with Multi-path Reliable Connections (MRC) [S7] 03
4. 1. MRC登場の背景と動機 なぜ大規模AI学習で新しいRoCE拡張が必要になったのか 04
5. 大規模分散学習における tail amplification ⼤規模な事前学習では、多数のGPUがほぼロックステップで動作する。 AllReduce、All-to-All、Send/Recv などの通信ラウンドでは、 最も遅い転送がいつ終わるかがステップ時間を決める。 OpenAIとMicrosoftの論⽂は、⾮常に⼤規模な事前学習ではtail latencyが ⽀配的になるとし、ネットワーク要件を次の3点に整理している。 1. フロー衝突による輻輳を避けネットワークを均等に利⽤する 2. incastを外れ値に発展させずに処理する 3. リンクやファブリックの障害で学習ジョブを停⽌させない 巨⼤クラスタでは、リンク‧optic‧switchのどこかが不安定であること は例外ではなく常態である。同期型の分散学習は、それをジョブ全体の 停⽌へ拡⼤する「failure amplifier (障害増幅器)」として作⽤する。 この前提がMRCの設計の出発点。 05
6. MRC登場に至る因果連鎖 1. 規模の拡大 学習用GPUクラスタの巨大化により、 tail latency（最遅遅延）と障害発生頻度が大幅に増大する。 2. 単一経路の限界 従来のSingle-path RoCE + ECMP構成では、ネットワーク内での経路の偏りや衝突を回避することが困難 になる。 3. 制御の限界 既存のPFC/DCQCNによる流量制御では、突発的な受信集中（ incast）や経路障害を十分に、かつ綺麗に 処理しきれない。 4. 構成上の制約 物理的なマルチプレーントポロジ（複数ネットワーク網）を構築しても、 1つのQP（Queue Pair）が複数経路や 複数planeを跨いで通信を分散利用できない。 解決策 (MRC) エンドポイント（ NIC）自身がパケット単位で細かく経路を能動的に分散し、輻輳や障害経路を即時に自動回 避するMRCが必要となる。 06
7. OpenAIのMRC開発の背景 背景と課題 ⼤規模AI学習では、多数のGPUが同期して処理するため、 ⼀部の通信遅延やリンク障害がクラスタ全体の性能低下につながる。 従来のRoCEネットワークでは、ECMPによって通信フローが特定経路に固定 されるため、次の課題があった。 • • • • ECMPハッシュの偏りによる局所的な輻輳 リンクやスイッチ障害時の通信性能低下 BGPなどの経路再収束にかかる時間 規模拡⼤に伴うネットワーク階層、機器数、消費電⼒の増加 10万GPUを超える環境では、障害を完全に防ぐのではなく、 障害や輻輳が発⽣しても学習ジョブへ影響させない仕組みが必要となった。 そこでOpenAIは、通信を多数の経路へ分散し、エンドポイント側で障害経 路を即座に回避できるMRCを開発した。 Supercomputer networking to accelerate large scale AI training [S4] 07
8. マルチプレーントポロジとの co-design MRCはトランスポート単独で考案されたのではなく、 マルチプレーンのトポロジとの共設計(co-design)である。 マルチプレーン構成には次の利点がある。 • switch tierを減らせる(経由switch数が減りlatencyが下がる) • opticsとswitch数を削減できる • 1本のlink障害が全帯域に占める割合が⼩さくなる • NICが複数の独⽴した物理経路を持ち、switch障害を別planeで回避できる 従来のRoCEはsingle-pathを前提としているため、1つのQPは通常1つのplaneしか使わない。 マルチプレーンを作っただけでは、plane間で負荷が偏り、そのplaneの故障がQPに波及する。 マルチプレーンを実⽤化するために、 1 QPを全planeへsprayできるトランスポートが必要だった。 08
9. なぜUltra Ethernet Transport (UET)を待たずに MRCなのか MRCとUltra Ethernet Transport (UET) は、 • packet spraying • out-of-order placement • SACK retransmission • packet trimming • sender-based CC • path-aware load balancing • best-effort Ethernet という考え方を広く共有する。実際、MRCのNSCC輻輳制御はUECの方式をそのまま利用している。 それでも別にMRCを作った理由は、主にスコープと導入時期だと考えられる。 MRCは、UETと競合する完全な別思想というより、 UETや先行研究で成熟してきた仕組みを、既存 RoCE環境へ早く投入するための production-orientedな限定実装・仕様 と見るのが適切。 09
10. MRCは大規模 AI学習に用途を限定 MRCは「RoCEを全面的に捨てて新しい汎用トランスポートを作る」のではなく、既存のRoCE RC、QP、RDMA Write、Verbs系ソフトウェア資 産を活用しながら、大規模AI学習に必要な部分だけを作り替えるという実用的な選択をしている。 MRCの出発点は「ネットワーク障害をなくす」ではなく、 「障害は常に起きるものとして、ジョブから見えなくする」という設計思想にある。 観点 RoCEv2 UET (UEC) MRC スコープ InfiniBand体系に由来するトランスポートス タック。 AIとHPCを含む汎⽤RDMAの業界標準 クリーンスレートの新トランスポートスタッ ク。 AI学習に必要な機能へ限定。 AIとHPCの両⽅が対象、Send/Recv‧Atomic等 RCのQP抽象とVerbs近似APIを維持 を広くカバー 狙い IBトランスポートを標準Ethernetで構築 次世代の汎⽤トランスポートとして体系化 既存RoCE資産を流⽤し、HWを早く製品化 し、実際のモデル学習へ早期投⼊する 10
11. 2. 従来RoCEv2とMRCの差分 Single path / lossless fabric 前提から、endpoint controlled multipathへ 11
12. RoCEv2 RC と MRC: 全体比較 RoCEv2 RC 観点 MRC 経路利用 1 QP = 1経路にECMP固定。QP scalingは確率的回避策 1 QPをパケット単位で数百経路へ spray。EVで経路を識別・回避 再送方式 go-back-N / in-order前提 SACK bitmapで欠落分だけ選択再送。再送は別 EVを使える 到着順序 in-order前提 順不同前提。全パケットが RETHを持ちメモリへ直接配置 輻輳/損失 PFC + DCQCNでlosslessを目指す PFC無効の best-effort。ECN/trimmingをシグナルとして利用 障害回避 BGP等の再収束に依存 EndpointがEVを即時回避し、 probeで復帰 対象オペレーション Read/Write/Send/Atomic Write / WriteIMM のみ 12
13. 差分1: 経路利用 — Single-path/ECMP固定 vs Packet spraying/EV • 標準的なRoCEv2 RCでは、通常1つのQPのパケットは同じ 5-tupleを持ち、 ECMPによって1つの経路へ固定される。 • RoCEで一般的な回避策は、 NCCLなどが1つの通信に複数 QPを作るQP scalingである。 QPごとにUDP source portを変えれば異なる ECMP経路へ分散される可能性 があるが、これは本質的に確率的な回避策にすぎない MRCではQPを増やす代わりに、 1つのQPの各パケットに異なる Entropy Value (EV) を付け、パケット単位で多数の経路へ送信 する。 Ultra Ethernet (UEC) で採用されている EVのメカニズムと共通する。 13
14. 差分2: 信頼性 — go-back-N/in-order前提 vs SACK選択再送 /OOO配置 パケットを複数経路へ sprayすると、到着順序は必ず入れ替わる。 標準RCの前提をそのまま使うと、先の PSNのパケットが届いていても途中のパケットが未達のため処理が進まなかったり、不要な再送 (go-back-N) が発生したりする。そこで MRCは信頼性方式を次のように変更した。 • 自己記述パケット : 各データパケットに宛先仮想アドレス(VA)とR_Keyを含める。受信NICはPSN順序を待たず、到着したパケットを直ちに最終メモリ位置へ 配置できる。OCP仕様上、通常のRCと異なり複数パケットWriteでもすべてのパケットにRETHが含まれ、VAがパケットごとに更新され る。 • SACK bitmapで受信済みPSNを通知し、欠落したパケットだけを選択再送する(cumulative ACKとselective ACKを併用、responder 側でout-of-order受信bitmapを保持)。 • 再送パケットは元と異なるEV、つまり異なる経路 を利用できる。 • 配送層とセマンティック層の分離 : MRCのReliability SACKは通常のRDMA ACKとは別物で、「パケットがレスポンダに到着したこと」と 「そのRDMA operationが意味的に成功したこと」を分離して扱う。 この変更により、あるパケットが失われても QP全体を止めず、失われたパケットだけを別経路で直ちに送り直すことが可能になった。 14
15. 差分3: 輻輳・損失制御 — PFC依存から best-effortへ 従来のRoCEでは、パケットロスを極力起こさないために PFC(lossless Ethernet)を用いる構成が一般的。 しかし、 MRCはPFCを無効にしbest-effort Ethernet (lossy) 上で動作させる ことを明示している。 Packet sprayingとPFCの相性が悪い : 1つのQPが数百経路を通ると、それらのパケットは最終的に同じ receiver-facing queueへ集中する。 どこかでPFCが発生すると、輻輳した通信だけでなく、同じ priorityや送信ポートを共有する無関係な通信まで停止しうる。 複数のcollectiveが同時に動く環境では、ある incastが無関係な「victim flow」を遅くする。 また、 DCQCNは経路選択を直接解決しない 。 DCQCNは送信レートを調整する仕組みで、基本的に「選ばれた経路上の輻輳」に反応する。物理的に空いている別経路が多数あっても、同じ QPが その経路へ移動するわけではない。 15
16. 差分4: 損失の意味の区別 — 輻輳loss vs 故障loss best-effortではlossが起こる。重要なのは、その lossが輻輳なのか故障なのかを区別する こと。 ACKが返らないだけでは、輻輳なのか故障なのか判断できない。 ここでUEC由来の packet trimmingが重要になる。 輻輳したswitchはパケット全体を dropする代わりに payloadを切り落とし、 headerを優先的にreceiverまで届ける。 receiverはTRIM NACKを返すため、senderは次を判断できる。 • TRIMされた → 経路故障ではなく輻輳の可能性が高い (ヘッダが届いた =経路は生きている ) • 何も届かず timeout → 経路障害の可能性を疑い、その EVを停止する MRCはこの考え方を RoCE拡張に取り込み、 ECNならEVを一時的にSKIP、無音の損失 (トリムなしのタイムアウト )ならEVをASSUMED_BAD、probeに 成功すればEVを復帰、packetは別EVで再送、という path-awareな動作を行う。 つまりMRCのEVは単なるhash seedではなく、小さな状態を持つ仮想経路識別子のようなもの。 16
17. RoCEv2 と MRC の比較まとめ 観点 従来の RoCEv2 RC MRC 経路利⽤ 1 QP = 1経路(5-tuple ECMPで固定) 1 QPをパケット単位で数百経路へ散布(EV) 再送⽅式 go-back-N(ウィンドウ全体を再送) SACKビットマップによる選択再送(別経路で) 到着順序 in-order前提 順不同前提。全パケットRETHでメモリ直接配置 ロスレス化 PFC(lossless)+ DCQCN PFC無効‧best-effort。ECN=負荷分散シグナル + trimming 輻輳制御 DCQCN(レート調整のみ) NSCC(送信側ウィンドウ)+ EV単位の経路回避 ロスの解釈 原因(輻輳/故障)を区別しない trim=輻輳、無トリム損失=故障、とEV状態で区別 障害回避 BGP等の再収束(秒オーダー) エンドポイントがEVを即時回避(数⼗μs)+ プローブ復帰 マルチプレーン 1 QPは基本1プレーンのみ 1 QPを全プレーンへ散布 対応操作 Read/Write/Send/Atomic(汎⽤) Write/WriteIMM のみ(AI学習に限定) 設計思想 正常でlosslessな網で⾼速に通信する 常時どこか故障‧混雑する前提でジョブを⽌めない 17
18. 3. MRCの基本設計 EVが本質 18
19. MRCの位置づけ ▪ RoCEv2 RC への「最⼩差分」として定義されている ‧ワイヤはRoCEv2/UDP/IPカプセル化のまま、新オペコード空間‧わずかなBTH変更‧新ヘッダ追加のみ ‧ソフトウェアモデルはVerbs互換のQP/CQ抽象を維持(libmrc) ▪ MRCがRCに追加する4つのCapability ‧接続単位の明⽰的マルチパス(パケットスプレー + マルチプレーン) ‧ベストエフォート向け信頼性(SACK/NACK、トリミング連携、受信側主導のインフライト制御) ‧送信側主導の輻輳制御(UEC由来のNSCCと、それを駆動するワイヤシグナルの標準化) ‧障害耐性(パス健全性追跡‧ポート状態通知‧データプレーン時間での⾼速フェイルオーバー) ▪ ⼀⽅でAI学習に不要な機能は⼤胆に削っている ‧RDMA Write と Write-with-Immediate のみサポート ‧Read / Send / Atomic / RNRフロー制御は⾮サポート ‧UEC (Ultra Ethernet) のクリーンスレート路線との最⼤の対⽐点 19
20. MRCの基本動作フロー 1つのQP 送信側: パケット毎にEV(エントロピー値)を切り替え 網内: 数百パス × 複数プレーンへパケットスプレー 到達成功 受信側への到達状況 未達 / 配置不可 ※送信側がSACK/NACK/タイマで観測 途中経路でECNマーキング？ [No] 受信側: [Yes] 受信側: 到着順不同のままメモリ直接配置 (⾃⼰記述パケット) 通常どおりメモリ配置し、即座にSACKを ⽣成 (Mフラグ=SKIP, 当該EVをエコー) 原因判定 NACK受信 サイレントドロップ (トリム = 輻輳損失、資源枯渇など) (SACKの⽳が残り続ける / タイムアウト) SACK = 到着確認 (配送層) ACK = 操作の実⾏確認 (セマンティック層) 送信側: 選択再送 + 当該パス(EV)を排除 (ASSUMED_BAD) 送信側: 送信側: 当該パケットのみ即時選択再送 SACKを受けて当該パス(EV)を⼀時スキップ (rtx=1、別EVで送信、⾼優先DSCP) ※損失ではないため再送は発⽣しない ヘッダが届いたパスは健全なので排除しない EVプローブで⽣存確認 → 成功したら復帰 (GOOD) 20
21. MRC 基本機構の全体像 MRCは、互いに独立な基本機構 (primitive) を複数組み合わせたものとして設計されている。 基本機構とは、パケットスプレーイング・ SACK・MPRのように、プロトコルを構成するそれ以上分解しない基本機能単位のこと。 EVがパケット毎にパスを決め、スプレーイングが負荷を分散する。その代償の順不同 到着にはMPRが上限を課す。SACK/NACK/トリミングが損失をRTT時間スケールで回 復し、NSCCが送信量を、EVエコーとECNがパス毎の負荷分散を調整する。トラ フィッククラス分離が制御ループ⾃体を輻輳から守り、EVプローブとPort Status Updateがパス‧ポートの健全性を通知する。 21
22. Entropy Value (EV): 3つの実現方式 MRCではリクエスタが各パケットにEntropy Value (EV) を付与し、パケット毎に変化させることで単一QPのパケット群を多数のファブリックパスへ分散させる。EVはエンドポイント が負荷分散とレジリエンスのために管理する値であり、MRCの本質である。 EVの実現方式には 3種類が定義 されている。 NICの実装次第で、トランスポート層のマルチパスロジックを変えずに暗黙ハッシュと明示ソースルーティングを入れ替えられる。 ⽅式 EVの符号化先 パス決定の仕組み ECMPハッシュ (レガシー) UDPソースポート (IPv4: 16bit)、 IPv6ではflow labelと合わせ32bit スイッチのECMPハッシュに委ねる EV→パスの対応は不可知だが安定 Structured EV UDPソースポート＋IPv6フローラベルの計32bit にホップ毎のサブフィールドを定義 各スイッチが⾃分担当のビットフィールドを読み 出してegressポートを決める決定的ホップバイ ホップ‧ソースルーティング SRv6 uSID 外側IPv6宛先アドレス (uSIDスタック) + 必要なら SRH (最⼤1個) SRv6マイクロセグメントによる明⽰パス指定 22
23. EV state machine: GOOD / SKIP / ASSUMED_BAD / DENIED EV選択はEVプロファイルで構成され、送信側が各EVを軽量なステートマシンで管理する。 SACK/NACKは、原因となった受信データパケットの転送パスEVをそのままエコー(echo)し、SACKにはさらに2bitのMフィールドが付く。 M=0b01 (SKIP) は「そのパスでECNマーク=一時的な混雑」、M=0b10 (ALWAYS_SKIP) は「既知の不良パス」を意味する。 これにより送信側はECNマーキングを特定パスに紐付けて解釈でき、パス確率の動的調整が可能になる。負荷分散アルゴリズム自体は実装定義である • GOOD: 送信候補として選択可能な EV GOODのみが送信対象 • SKIP: ECNやTRIM NACKなど、一時的な混雑を示すフィードバックで一時除外 実装定義の時間で GOODへ戻す • ASSUMED_BAD: timeoutやALWAYS_SKIPなど、到達不能が疑われる EV probe成功によりASSUMED_BADからGOODへ復帰できる • DENIED: controller/管理者により無効化された EV コントロールプレーン専用 23
24. 経路非対称と逆方向 EV • MRCは応答(制御)パケットのパス選択を順方向リクエストパスから分離している。 • 制御パケットはデータと異なるパス・異なるプレーンを使用でき、部分的なファブリック障害や非対称輻輳への耐性を高める。 • 制御パケットのEV生成は実装定義だが、 「現に有効なパスに対応するEVを使うべき(SHOULD)」とされる。 24
25. Multi-plane operation: EV空間を物理 planeで分割 • Multi-port NICでは、各portが異なるplaneに接続される • EV空間をport/planeごとに分け、単一 QPが複数planeへsprayする • MRC運用では、Active EVから外すときも同一 planeのEVで置き換え、plane間 負荷を均等に保つ • 利点: plane別統計が異常検知に使いやすい • 制約: 特定planeだけ劣化する gray failureは、外部監視 /denylistの助けが必 要になる場合がある 25
26. MPRとWriteIMM上限: 受信側主導のインフライト制御 ▪ スプレーしたパケットは順不同で到着する → 無制限に許すと受信側が破綻する • パス毎に遅延が異なるため、レスポンダにはパケットが送信順とは無関係の順序で到着する。 これ⾃体は設計どおりの挙動だが、順不同を許すと両端に新しいコストが発⽣する。 • レスポンダ側: 「どのPSNまで連続して受信したか」という1個の数値では⾜りず、 「⻭抜けの先のどのPSNが既に届いているか」を1パケット単 位で記憶しなければならない。 • リクエスタ側: 確認応答が返るまで、送信済みパケット毎に再送⽤の状態(タイマ、再送済みか、どのEVで送ったか等)を保持し続けなければなら ない。 どちらのメモリ消費も「同時に⾶⾏中(in-flight)でありうるパケット数」に⽐例する。 ここに上限を設けなければ、NICのオンチップメモリ設計が成⽴しない。 MRCはこの上限を受信側(レスポンダ)が広告するウィンドウとして仕様化したものが Maximum PSN Range (MPR) 26
27. MPRとWriteIMM上限: 受信側主導のインフライト制御 ▪ Maximum PSN Range (MPR) — レスポンダが広告するスライディング受信ウィンドウ • TCPの受信ウィンドウがバイト数で数えるのに対し、MPRはパケット数(PSNの範囲)で数える • リクエスタは、レスポンダのビットマップ上端を超えるPSNを送信してはならない(MUST) • 両端がPSN粒度のMPRサイズビットマップを維持。SACK/再送機構の基盤になる • NICのトランスポート実装の責任範囲 ▪ max_wimm_inflight (WriteIMMインフライト上限) — セマンティック操作粒度の別軸の制御 • レスポンダはMPRとは別に、max_wimm_inflight(WriteIMMインフライト上限)も広告する • WriteIMMは完了時に受信側にも完了通知(CQE)と32bitの即値(ImmDt)を届ける唯⼀の操作で、xCCLが「書き込み完了」を相⼿に 知らせる⼿段として多⽤される • パケットは順不同で届くが、WriteIMMの完了通知はリクエスタが発⾏した順序で配送しなければならない。 • 後発のWriteIMMが先に全パケット到着してしまった場合、レスポンダはそのImmDtと完了情報を、先⾏リクエストが揃うまで退 避(stash)しておく必要がある • この制御を⾏うためのウィンドウ • xCCLの責任範囲 上記が役割を引き継いだため、RCのクレジット制御は廃⽌された 27
28. 信頼性とリカバリ : SACK / NACK / トリミング / プローブ / タイマ MRCの損失回復系は 5つの部品から成る。 設計思想は一貫していて、「再送タイマの満了を待つ」という最も遅い回復手段を、可能な限り使わずに済ませることにある。 部品 向き 役割 SACK (4.5.2) 受信側 → 送信側 到着状況の精密なスナップショットを定期報告する（肯定応答） NACK (4.5.3) 受信側 → 送信側 「届かなかった／受け取れない」をイベント駆動で即時通知する（否定応答） トリミング (4.5.3) 網 → 受信側 スイッチが「破棄」を「通知」に変換し、 NACKの材料を作る Reliability Probe (4.5.4) 送信側 → 受信側 「いまどこまで届いたか」を能動的に問い合わせる タイマ (4.5.5) 送信側内部 上記すべてが機能しない「無音の損失」に備える最後の砦 28
29. 前提となる設計 : 「届いたか」と「処理できたか」の分離 RoCEv2 RCではACKが1つで「パケットが届いた」と「 RDMA操作として処理された」の両方を意味していた。 MRCはこれを2つの層に分ける。 • パケット配送層 : PSNが物理的に到着したかだけを追跡する。 SACK/NACKが担当 • セマンティック層 : RDMA操作としてメモリ書き込み・完了通知が正しく実行できたかを追跡する。従来型のトランスポート ACK/NAKが担当 例: パケットは到着したが R_KEYが無効 → 配送層はSACKで「届いた」、セマンティック層は NAKで「処理できない」と報告する。「 SACKされたがNAKさ れた」は矛盾ではなく正当な状態で、一方の層の結果から他方を推論してはならない (MUST NOT)。 利点: 再送判断がPSNの算術だけで完結し、メモリ /PCIe側の結果を待たずワイヤ速度で回せる。 この分離を物理的に可能にしているのが⾃⼰記述パケット（全ペイロードパケットにRETHが付く） 29
30. 制御パケット : SACK ▪ SACKは3つの情報を持つ 1. cack_psn — 「ここまでは1つの抜けもなく受信済み」の最⼤PSN(累積ACK) 2. sack_offset — cack_psnからの相対位置 3. 64bitビットマップ — sack_baseから64パケット分の到着有無(1bit=1PSN) 例: cack_psn=999でビットマップの1001だけが0 → 「1001だけ未達、1002以降は到着済み」と正確に分かり、1001だけを選択再送すればよい(go-back-Nでは 1001以降を全部再送)。同じ⽳が複数のSACKに残り続ければ「損失の疑い濃厚」、次のSACKで埋まれば「順序の⼊れ替わり」— 損失とリオーダリングを観測で 区別できる。 SACKは受信パケット毎に毎回返るものではない。1個のSACKがcack_psn+ビットマップで複数パケット分をまとめて確認する。 SACKは定期的な肯定報告 30
31. 制御パケット : NACK ▪ NACK: 決定論的イベントによる能動的な不達通知(即時再送をトリガ) • 7種類の理由コードを持つ: TRIMMED / NO_BITMAP / NO_PKT_BUFFER / PSN_OOR_WINDOW など • 最重要ユースケースがパケットトリミングで、UETのものをそのまま採⽤している nack_reason ニーモニック レスポンダ対応 リクエスタの挙動 0x01 TRIMMED Optional 再送+リトライカウンタ増。上限到達でQPエラー ("Retry Counter Exceeded")。EVは SKIPへ 0x02 TRIMMED_LASTHOP Optional 同上(最終ホップのインキャスト。EVステートには影響させない運⽤が典型) 0x06 NO_BITMAP Mandatory 再送+リトライカウンタ増(レスポンダの追跡資源⼀時枯渇) 0x07 NO_PKT_BUFFER Mandatory 再送+リトライカウンタ増(受信バッファー⼀時枯渇) 0x0A NO_RESOURCE Mandatory 再送+リトライカウンタ増(実装固有資源の⼀時枯渇) 0x0B PSN_OOR_WINDOW Mandatory 再送+リトライカウンタ増(追跡ウィンドウ外PSN) 0x19 UNEXP_EVENT Mandatory QPを即時エラー遷移("Remote Operation Error") トリミングが与えるものは2つある。 1. 速度: 損失の検出‧回復がタイムアウト(ミリ秒〜秒)からRTT(マイクロ秒)の時間スケールに変わる。 2. 診断情報: 「ヘッダは届いた」という事実は、そのパスが物理的に⽣きている証拠である。したがってトリム由来の損失では、パス(EV)を誤って不良と判定しない。 逆に、トリムなしの無⾳の損失はタイムアウトでしか検出できず、それは「パスの故障」を⽰唆する。「輻輳による損失」と「故障による損失」の区別 は、この仕組みで実装されている。 NACKは即時の否定通知 31
32. 制御パケット : Probe ▪ Reliability Probe: 送信側から発する能動的な問い合わせ • 専⽤ヘッダ(PETH)を持ちPSNを消費しないアウトオブバンドのパケットで、何度送ってもデータストリームには⼀切影響しない • レスポンダは通常のSACKで応答しなければならない(MUST) 以下のような使いどころがある: (1) データが流れていない接続の健全性監査 — ACKタイムアウトに頼らず「接続は⽣きているか、どこまで届いたか」を確かめられる。 (2) EVを指定して送れるため、特定パス1本の疎通試験になる — ASSUMED_BADに落としたEVが復活したかの判定 32
33. 輻輳制御 : NSCCとCC_STATE ▪ MRCはUECの NSCC (Network Signal Congestion Control) をそのまま採⽤する DCQCNがレートベース(ECN由来のCNPを受けて送信レートを上下する)のに対し、NSCCはTCPと同じウィンドウベース制御を⾏う。 ▶ MRCがやったのは「アルゴリズムの発明」ではなく「必要なシグナルの標準化」 ECN Request RTT 推定される網状態 調整 なし RTT < target ⾮輻輳 ⽐例増加 なし RTT ≥ target 輻輳は解消⽅向 公平増加 あり RTT ≥ target 輻輳中 乗算減少 あり RTT < target 輻輳の兆候(当該パケットは未遭遇) 変更なし ▪ シグナルはSACK内の CC_STATE サブヘッダ(8バイト)が運ぶ 33
34. RoCEv2のCNPはMRCに存在しない • DCQCNでは、受信側が ECNマーク(CE)付きパケットを受信すると CNP (Congestion Notification Packet) を送信元へ返していた。 • MRCにCNPというパケットは存在せず、その役割は SACKに統合 されている。 • ECNマーク付きパケットの到着は SACKの即時生成トリガ の1つであり、生成された SACKは当該パケットの EVをentropyフィールドにエコーし (MUST)、Mフィールドに「このパスで ECNマークあり(SKIP)」を立てて返す。 • CNPが伝えていた「この接続で輻輳が起きた」という QP粒度の通知は、 MRCでは「どのパスで混雑したか」まで特定できるパス粒度の通知に 置き換え られている。 34
35. 4. パケットフォーマット RoCEv2のwireを残しつつ、MRC専用opcodeとヘッダを追加 35
36. MRCのパケットフォーマット MRCパケットの全体スタック Ethernet IP (v4/v6) UDP (dport=4791, sport=EV) BTH (0xDC/DD/DE) iCRC Ethernet FCS Reliability Header (SETH / NETH / PETH) 標準のRoCEv2/UDP/IPカプセルを維持し、変更が⼊る既存ヘッダはBTH(ビット追加‧流⽤)とRETH(搬送規則の再定義)の2つのみ。 残りはすべてBTHペイロードとして追加された新設ヘッダ。 UDPチェックサムは0(不使⽤)をMUSTとし、UDPソースポートはEV選択により設定される。 36
37. MRCのパケットフォーマット : RoCEv2からの新設・変更 ▪ 変更が⼊る既存ヘッダは BTH と RETH の2つだけ。残りはBTHペイロードとして追加された新設ヘッダ ‧既存パーサから⾒ると「DSCPの検査が増える点を除けば、普通のRoCEv2パケット」 ‧DSCPは制御(⾼優先‧トリムしない)/データ/再送/トリム済みを分離する。このQoS設計は導⼊の前提条件 区分 ヘッダ 内容 無変更 Ethernet / IP / UDP / iCRC / FCS RoCEv2のカプセル化規則そのまま。UDP宛先ポート既定4791 無変更 AETH / ImmDt フォーマットは同⼀(AETHのクレジット欄は常に0x1F固定) 変更 BTH rtx / tsh ビットを追加。PSNフィールドをプローブ⽤途に流⽤ 意味再定義 RETH フォーマットは同⼀。全リクエストパケットに搬送し、VAをパケット毎に更新 新設 METH WriteIMM追跡⽤のMSN / RQMSN(全リクエストパケットに搬送) 新設 TSETH タイムスタンプ / サービスタイム(オプション) 新設 SETH + CC_STATE SACKヘッダと輻輳制御テレメトリ 新設 NETH / PETH NACKヘッダ / Reliability Probe要求ヘッダ 新設 ERTH / EETH Endpoint操作の要求‧応答ヘッダ フィールド 標準RoCEv2での⽤途 MRCでの⽤途 区分 OpCode トランスポート種別+操作 MRC専⽤空間(上位3bit=0b110)。RCと⾮互換 ⽤途変更 SE / M Solicited Event / MigReq 未使⽤(送信時0‧受信時無視)。パス制御はEVが担う 廃⽌ reserved(7) 予約(iCRC対象) rtx(再送フラグ)+ tsh(TSETH存在)を新設 新設ビット PSN パケットシーケンス番号 データは同⼀。プローブ/EP操作では識別⼦として流⽤ ⽤途拡張 37
38. オペコード空間 MRCオペコードは上位3bit= 0b110 の専用空間を使い、RoCE RCとは意図的に非互換 (RC/MRCエンドポイントは相互運用しない)。 MRCはAI学習用途に限定しているため、RDMA Write系(Write / WriteIMM)のオペレーションにしか対応していない。 Opcode 種別 BTHに続くヘッダスタック 0xC6 RDMA WRITE First METH, [TSETH], RETH, PayLd 0xC7 RDMA WRITE Middle METH, [TSETH], RETH, PayLd 0xC8 RDMA WRITE Last METH, [TSETH], RETH, PayLd 0xC9 RDMA WRITE Last with Immediate METH, [TSETH], RETH, ImmDt, PayLd 0xCA RDMA WRITE Only METH, [TSETH], RETH, PayLd 0xCB RDMA WRITE Only with Immediate METH, [TSETH], RETH, ImmDt, PayLd 0xD1 Acknowledge (RDMA トランスポート ACK) AETH 0xD8 Endpoint Request ERTH 0xD9 Endpoint Response EETH 0xDC Reliability SACK SETH, CC_STATE 0xDD Reliability NACK NETH 0xDE Reliability PROBE Request PETH 38
39. BTHの変更点 — 標準RoCEv2 BTHとの比較 (1/2) (a) 標準RoCEv2 BTH (IBTA) Byte 0 OpCode (8) RC=0b000xxxxx等 Byte 1 Byte 2 SE | M | Pad (2) | TVer (4) Byte 3 P_Key (16) — パーティションキー reserved (8, variant) DestQP — 宛先QP (24) A (AckReq) | reserved (7) PSN (24) — パケットシーケンス番号 (b) MRC BTH Byte 0 opcode = MRC Opcode (8) 専用空間 0b110xxxxx var-res (8) a | R | rtx | tsh | inv-res (4) Byte 1 SE | M | pad (2) | tver=0 (4) Byte 2 Byte 3 p_key (16) — 制御パケットでは信頼性ヘッダ存在を示す予約値 dqp (24) — Endpoint操作では予約 QPN 0x2 psn (24) — データ: PSN / プローブ・ EP操作: 識別子 39
40. BTHの変更点 — 標準RoCEv2 BTHとの比較 (2/2) フィールド 幅 (bit) 標準RoCEv2 BTHでの⽤途 MRC BTHでの⽤途 区分 OpCode 8 トランスポート種別+操作 (RC Writeなど) MRC専⽤オペコード空間 (上位3bit=0b110)。RCと意図的に⾮互換で、 RC/MRCエンドポイントは相互運⽤しない ⽤途変更 SE 1 Solicited Event (受信側CQイベント要求) 未使⽤。送信時0‧受信時無視 廃⽌ M 1 MigReq (APMパスマイグレーション状態) 未使⽤。送信時0‧受信時無視 (パス制御はEVが担う) 廃⽌ Pad / TVer 2+4 パディング / ヘッダバージョン 同⼀ (TVer=0) 流⽤ P_Key 16 パーティションキー 制御パケット (SACK/NACK/プロローブ等) では「信頼性ヘッダが続くこ と」を⽰すプロビジョニング予約値として使⽤ ⽤途変更 reserved 8 予約 (iCRC対象外) 同⼀ (var-res) 流⽤ DestQP 24 宛先QP番号 同様。ただしEndpoint操作 (EV Probe / Port Status Update) では予約 QPN 0x2で識別 ⽤途拡張 A (AckReq) 1 ACK⽣成要求 同様 (SACK⽣成トリガの⼀つ。送信側アイドル時に全パケット確認を保 証する⽤途) 流⽤ reserved 7 予約 (iCRC対象外) R(予約1) + rtx(再送フラグ、新設) + tsh(TSETH存在、新設) + inv-res(4) 新設ビット×2 24 パケットシーケンス番号 データ: PSN (同⼀)。Reliability Probe / Endpoint操作: リクエストロー カル識別⼦ (PSN[15:0]=probe_id) として流⽤し、PSNを消費しない ⽤途拡張 (variant) (invariant) PSN (制御) 40
41. RETH: 全パケットが自己記述になる 全リクエストパケットは統一ヘッダスタックBTH(12B) → METH(4B) → [TSETH(4B)] → RETH(16B) → [ImmDt(4B)] → ペイロードをとる。RETHが全パケットに 含まれる点が標準IBTAとの最大の違いで、これにより各パケットが自己記述となり順不同のメモリ直接配置が可能。 項⽬ 標準IBTA RC (RoCEv2) 搬送されるパケット First / Onlyパケットのみ。Middle/LastはRETHを持たず、 受信側がメッセージ内オフセットを順序から導出する 全リクエストパケット (MUST) 各パケットが⾃⼰記述となり、到着順に依存せずメモリ直接配置できる メッセージ先頭のリモート仮想アドレス (1回だけ宣⾔) 当該パケットのペイロード配置先アドレス。複数パケットメッセージでは PMTU分ずつパケット毎に更新(インクリメント)される (MUST) r_key (32bit) アクセスを許可するリモートキー 同じ。同⼀メッセージ内で不変 dmalen (32bit) DMA操作(メッセージ)全体の⻑さ。First/Onlyでのみ検証 意味は同じ(WR定義のDMA操作全体⻑)だが全パケットで搬送され、⻑さ検 証は各パケットで⾏われる (IBTAV18から修正された条件 MR境界チェック メッセージ単位 パケット毎に必須(MUST) va (64bit) MRC 41
42. MRCで新定義されたヘッダ MRCで新定義されたヘッダ METH 新設 Message Extended Transport Header 「このパケットがどのメッセージに属するか」をパケット⾃⾝に名乗らせるヘッダ TSETH 新設 Timestamp Extended Transport Header パケットに送信時刻を載せてエコーで返してもらう⽅式を使う場合に必要 SETH 新設 Reliability SACK Header 到達情報を詰め込んだ情報密度の⾼いSACKに必須のヘッダ CC_STATE 新設 SACK内の輻輳制御テレメトリサブヘッダ NSCCのRTTなどのシグナルの搬送に利⽤ NETH 新設 Reliability NACK Header 「このPSNがこの理由で受け取れなかった」という通知でNACKに必須のヘッダ PETH 新設 Reliability Probe Request Header 受け取ったらSACKで返す ERTH / EETH 新設 Endpoint Request/Response Header (EV Probe / Port Status Updateなどで利⽤) どのQPにも属さない 42
43. DSCPとtraffic class設計 DSCPコードポイント 要否 ⽤途 DSCP_NO_TRIM Required トリミング⾮対象データ DSCP_TRIMMABLE Optional トリミング利⽤時のデータ既定値(Reliability Probe要求もこれ) DSCP_TRIMMABLE_RETX Optional 再送データ(BTH.rtxと併⽤)— 再送の優先処理に使⽤ DSCP_TRIMMED Required 網内でトリムされたパケットの表⽰ DSCP_TRIMMED_LASTHOP Optional 最終ホップスイッチでのトリムの表⽰ DSCP_CONTROL Required 制御トラフィック(SACK/NACK/RoCE ACK)— Highクラス 43
44. 5. SRv6とMRC SRv6はオプション。ただし大規模運用の単純化に強い意味を持つ 44
45. SRv6はMRCに必須か？ 結論: 必須ではない。SRv6はオプションの1つ ▪ OCP仕様は3つの転送モードを等格に定義している 転送モード EVの符号化先 パス決定の仕組み ① ECMPハッシュ (レガシー) UDPソースポート(IPv4:16bit) IPv6ではフローラベルと合わせ32bit スイッチのECMPハッシュに委ねる EV→パスの対応は不可知だが平常時は安定 ② Structured EV UDPソースポート + IPv6フローラベルの 計32bitにホップ毎のサブフィールドを定義 各スイッチが⾃分の担当ビットを読み、 出⼒ポートを決める決定論的ソースルーティング ③ SRv6 uSID 外側IPv6宛先アドレス(uSIDスタック) + 必要ならSRH(最⼤1個) SRv6マイクロセグメントによる明⽰パス指定 ▪ MRCトランスポート論⽂でも、ソースルーティングは Optional に分類されている ‧必須なのは「EVによるパケットスプレー」そのもの。ECMPモードだけでMRCは完結する ▪ 「MRC = SRv6」はOpenAI等の著名なデプロイに引きずられた誤解 45
46. 3つのルーティングモードの制約 • ECMPモード : 既存のClosファブリックに一切のデータプレーン変更なしに MRCを導入可能 EVからパスを逆算できないため、 「どのリンクが悪いのか」の特定には別途テレメトリが要る • Structured EVモード : SRv6の「決定論的パス指定」を IPv6拡張なし(=外側カプセル化なし、 IPv4でも部分的に )得られる中間解 MRCの固有機能をスイッチ側に要求するため、 EVビットを解釈する対応スイッチが必要 • SRv6 uSIDモード : 送信元での明示的パスプログラミングにより、決定論的負荷分散、パスの完全な可観測性、 gray failure耐性を得る Closファブリックのルーティングプロトコルとして のBGPを無効化可能 Mode スイッチ要件 長所 制約 EV→物理pathが不可知。リンク増減時のECMP再 hashで学習が崩れる ECMP hash 通常のIP ECMP + ECN + 可能ならtrimming 既存fabricに導入しやすい Structured EV EV bit fieldをswitchが解釈 決定論的path指定をIPv6拡張なしに近い形で実 MRC固有機能をswitchに要求 現 SRv6 uSID SRv6 uSID line-rate forwarding EV⇔pathの決定論、可観測性、静的CP化 uSID番号計画、IPv6-in-IPv6、静的route設計が必要 46
47. SRv6を使う場合のデータプレーン詳細 ▪ uSID形式で、経路上の各スイッチを明⽰的に指名する • 宛先IPv6アドレス = 32bitロケータ + 16bit uSIDの列(F3216形式で最⼤6個) • MRCパケットは IPv6-in-IPv6 カプセル化。外側=SRv6経路、内側=宛先NICアドレス • encap/decapはNICが⾏い、スイッチは純粋なSRv6トランジットノードになる ▪ スイッチの転送動作は pop & left-shift のみ • 先頭48bit(ロケータ+⾃uSID)を照合 → uSID部を16bit左シフト → 静的テーブルで/48ルックアップ • この uN 転送はSRv6 uSID対応シリコンスイッチでラインレート処理できる • 受信NIC側では、外側ヘッダが残ったまま届くEnd/End.X形態と、外側が除去されたEnd.DX/End.DT形態の両⽅の処理をサポートしなければならない (MUST) 1. スイッチは宛先アドレス先頭48bit(ロケータ32bit+⾃ uSID 16bit)を⾃⾝の設定値と照合。⼀致すれば⾃分宛のSRv6パケット 2. uSID部を16bit左シフトし、次ホップのuSIDを先頭48bitへ移動(末尾は0詰め) 3. シフト後のアドレスを静的転送テーブルで/48ルックアップし、egressポートを決定 4. uSIDが尽きた時点でSRHがあれば、SRH内のセグメントをSRv6アドレスへ昇格(promote)して続⾏ 47
48. SRv6を使う場合のデータプレーン詳細 ▪ EVとSRv6アドレスのアルゴリズム的対応 OpenAIの実装例:EV(32bit、UDPソースポート+フローラベル)はパケットに搬送され続ける。SRv6アドレス⾃体は転送中のシフトで消えるためエコーできず、 SACK/NACKでパス識別⼦としてエコーされるのはEVである。パス毎に「SRv6アドレス+EV」の両⽅の状態を持つ無駄を避けるため、OpenAIのデプロイは EV→SRv6アドレスのアルゴリズム的マッピングを使う。 1. uSID番号体系をネットワークトポロジに沿って割り当てる (ノードの16bit uN値の特定ビットがプレーン番号とトポロジ上の位置を符号化する) 2. QP起動時、NICはノード固有の設定ファイルから宛先プレフィクスに対応するSRv6アドレステンプレートを取得し、 宛先IPアドレスから最終ホップのダウンリンク番号をdst uSIDに埋める 3. パケット送信毎に、選択したEVから「パス間で変化するビット」(全uSID共通のプレーン番号、T1 uSIDに⼊るT0アップリンク番号)をテンプレートに書 き込み、最終的な外側宛先アドレスを⽣成する EVは「その宛先へのSRv6パス群の中で変化するビット+使⽤NICポート」の圧縮表現となり、キャプチャした任意のパケットのEVから元の完全なSRv6パスを 逆算できる。クラスタ間転送もこのスキームの拡張で⾏われる。 48
49. SRv6を使う場合のコントロールプレーン詳細 ▪ 動的ルーティングプロトコルは無効 • バックエンドのSRv6転送プレーンにBGP等は不要。静的ルートを起動時にプリプロビジョニング • 各スイッチのIPv6アドレスと隣接ノードへの静的ルートは、設置時に構成され以後変更されない ▪ NIC側の構成 • QP接続確⽴はアウトオブバンド(各QPはコントローラAPIで事前構成されたEVプロファイル/CCプロファイルを利⽤する) • ノード毎に特権コントローラ(CAP_NET_ADMIN)がEV/CCプロファイルとEV状態を管理する ▪ パス排除リストと外部監視 (Clustermapper) • MRCはコントローラからのデニーリスト(既知障害リンクを通るパスの事前排除)をサポートする • OpenAIは全ノードにClustermapperエージェントを置き、SRv6セルフループプローブで全リンクを毎ミリ秒プローブして障害リンクマップを作成 「静的ルーティング +SRv6」はMRCの標準構成ではなく、 MRCデプロイの一形態。この構成は MRCのパス回避能力とマルチプレーントポロジの冗長性が前提であり、これを欠く環境で動的ルーティングを 外すことは推奨できない。 また、この構成の恩恵 (可観測性・グレー障害耐性 )の多くは SRv6そのものではなく「 EV⇔パスの決定論」に由来する — Structured EVでも原理的には同種の決定論が得られる。 49
50. OpenAI/MicrosoftのSRv6 uSIDデプロイの詳細 詳細は⼀次ソースとしての論⽂を参照 Resilient AI Supercomputer Networking using MRC and SRv6 これはMRC仕様の必須構成ではなく、大規模 SRv6デプロイの一形態です。 50
51. 6. 適用領域とトレードオフ MRCは強力だが、汎用RDMAの置き換えではない 51
52. MRCが適する用途 用途 大規模同期 AI事前学習 (数千〜10万+ GPU/XPU) 理由 MRCの設計対象そのもの。100パーセンタイル転送性能がジョブ性能を決める同期集団通信で、フロー衝突排 除（スプレー）、インキャスト耐性（トリミング）、障害透過（EVステート＋Endpoint操作）が直接効く[S2 §II, S3]。 42K GPUスケールのNCCL send/recvで大メッセージ92GB/s/NICが実証済み[S3 §5.2.6] マルチプレーン Closのスケールアウト 網 プレーン対応トランスポートの存在がマルチプレーン設計（2層で131K XPU）を実用化する。EVのプレーン分割 ・Port Status Update・プレーン均等維持はこのトポロジー専用に設計されている[S3 §2, S5] 単一プレーンの既存 RoCEファブリック 改善 ECMPモードならスイッチ変更なしで導入でき、1QPのスプレーだけでQPスケーリング（16QP）を上回るロードバ ランスと、0.1%損失下でもほぼ性能を維持する耐損失性が得られる[S3 §5.2.7] PFCを撤廃したい lossy Ethernet運用 MRCはPFC無効・ベストエフォート動作が前提。DCQCNチューニング地獄とPFCの巻き添え被害（victim flow） を構造的に回避する[S3 §2.1, §5.2.8] 運用簡素化を最優先する超大規模サ イト リンクフラップ常態下での「修理より放置」運用、スイッチの無調整再起動、静的コントロールプレーン。少人数 チームによる複数スーパーコンピュータ運用が実証されている[S3 §3] HPC(MPI主体)ワークロードについて : UETがHPCとAIの両方を明示的な設計対象とするのに対し、 MRCはAI学習の集団通信 (実質的に Writeベースの大転送 )に特化している。 Send/Recvセマンティクスやタグマッチングを使う HPC通信スタックは MRCの対象外であり、この領域では UETまたは既存 RC/InfiniBandが引き続き適切。 52
53. MRCが適さない用途 用途 理由 RDMA Read / Send / Atomicを必要 とする汎用 RDMAアプリケーション MRCはWrite/WriteIMMのみサポート。Read・Send・Atomicの受信はレスポンダQPをERROR遷移させる[S1 §5.1, §10.2.1]。 分散ストレージ、既存MPI片側通信の全機能、汎用verbsアプリはそのままでは動かない 受信側RQフロー制御 (RNR-NAK)前提 のアプリ RNR-NAKリトライ・メッセージレベルクレジットは非サポート。WriteIMMのインフライト管理は上位ソフトウェア (*CCL等)の責務になる[S1 §6.3.3, §6.4] ネットワークからの in-order配送に依 存する設計 順不同配置が前提。到着順に意味を持たせている(例: 最終パケット到着=全データ到着とみなす)実装は書き直 しが必要。 順序保証はWriteIMM完了通知(送信順で配送)でのみ得られる[S1 §6.3.2] 汎用マルチテナント DC/フロントエンド 網 MRCはAI学習向けに意図的に単純化されたトランスポートであり、テナント分離・多様なトラフィッククラス・ショー トフローが混在する汎用DCの要件は対象外。 フロントエンドは従来どおりECMPが推奨される[S5] 単一パストラフィックと共存するバック エンド網 (注意付き ) プレーン均等維持の設計により、非MRCの単一パストラフィックが同居するとMRCは最混雑プレーンに律速され る[S3 §4]。バックエンドをMRC専用にできない場合は性能設計に注意 小規模クラスタ (数十〜数百 GPU)での 新規導入 技術的には動作するが、RC+ECMP+QPスケーリングで十分な規模ではMRC対応NIC/運用体制への投資対効 果が薄い。 MRCの価値は障害・衝突・テールが支配的になるスケールで顕在化する(論文著者評価) 53
54. プロトコル設計上のトレードオフ 得たもの ⽀払った対価 パケットスプレーによる均等負荷分散 恒常的なリオーダリング。レスポンダはMPR分のPSNビットマップとOOO配置能⼒、WriteIMMのImmDt退避 資源が必須になる。MPR/WriteIMM資源はNICオンチップ状態であり、QP数×MPRでスケールする(Dynamic MPRはこの資源の多重化のための追加複雑性) [S2 §II-B] 全パケット⾃⼰記述(RETH毎パケット搬送) パケットあたり16バイト級のヘッダオーバーヘッド増。RoCE RCではFirst/Onlyのみが運んだRETHを全パケッ トが運ぶ [S1 §6.2.2.2] lossy動作(PFC廃⽌)によるHoL/巻き添え排 除 損失が常態化し、回復性能がプロトコル品質に直結する。SACK/NACK/トリミング/プローブという回復機構群 の実装複雑性はRC⽐で⼤幅増。1%級の持続損失ではMRCでも1/3程度まで性能低下する(0.1%ならほぼ無影響) [S3 §5.2.7] 機能削減による単純化(Write/WriteIMMの み) RCとの相互運⽤性‧アプリ互換性の放棄。RC/MRCはオペコード空間から⾮互換で、既存verbsアプリは移植が 必要。libmrcという新ライブラリ層とアウトオブバンド接続確⽴(RDMA-CMなし)が要る [S1 §10] エンドポイント主導の障害処理 NICへの状態集中。EVステート、QPCC、逆⽅向EV管理、probeエンジンなどNIC実装の負担が⼤きい。CX8実 装ではNICリンク断時の全QP EV再マッピングが⾮瞬時で、スループットグリッチの原因になると報告される [S3 §3] 54
55. ネットワーク/運⽤上のトレードオフ 得たもの ⽀払った対価 マルチプレーンによる冗⻑性‧2層化 プレーン数×スイッチ台数‧ケーブリングの管理対象増。NICの8分割光学系ではNICトランシーバ⾃体が 単⼀障害点として残る(全ポート同時喪失はQP障害になる)[S3 §5.1] プレーン均等負荷の不変条件 (運⽤の単純さ) プレーン⾮対称な障害への適応⼒を意図的に放棄。特定プレーンの部分劣化(グレー障害)はMRC単独で回 避できず、外部監視(Clustermapper)+デニーリストに委ねる[S3 §4] トリミングによる⾼速‧正確な損失分類 効果を最⼤化するにはUETトリミング対応スイッチが必要(受信対応は必須だが、網がトリミングしなけ れば恩恵なし)。トリミング‧専⽤DSCP‧制御⽤⾼優先クラスなどQoS設計が前提になる[S1 §7.5.3, §7.5.5.1] ECNの負荷分散シグナル化 (最終ホップ無効) ECN=輻輳通知という従来運⽤からの転換。フルバイセクション(⾮オーバーサブスクリプション)設計が 事実上の前提となり、オーバーサブスクライブ網ではこの意味論は成⽴しない[S3 §2.1] 55
56. 7. 類似技術・評価・エコシステム UETとの補完関係、本番実装、標準化の現状 56
57. MRCとUETの関係 観点 MRC (OCP) UET (UEC) 設計アプローチ RoCEv2 RCへの増分拡張(最⼩差分)。既存RoCE NICパイプライン ‧Verbsモデルを再利⽤ クリーンスレートの新トランスポート(PDS/SES等の新レイヤ構 成)。RoCEv2を置換 対象ワークロード AI学習に特化(Write/WriteIMMのみ) AIとHPCの両⽅(Send/Recv、タグマッチング等を含む豊富なセマ ンティクス) API Verbs系(libmrc、mrc_qp/mrc_cq、libibverbs併⽤) libfabric系 マルチパス EV(3モード: ECMP/Structured EV/SRv6 uSID)。SRv6ソースルー ティングを標準に内包する点はMRC固有 パケットスプレーイング＋エントロピー(ECMPベース)。SRv6 ソースルーティングは仕様の中核ではない 輻輳制御 NSCC(UETから採⽤)。代替アルゴリズムも許容 NSCC(本家)ほか 損失回復 SACK/NACK＋トリミング(UETから採⽤)＋Reliability Probe 選択的再送＋トリミング(標準次元) 障害対応 EVステートマシン、GIDスコープEndpoint操作(EV Probe / Port Status Update)による⾼速フェイルオーバをプロトコル内蔵 (相当する明⽰的なエンドポイントスコープの到達性シグナリング はMRCの差別化点として提⽰される[S2 §I]) 接続確⽴ アウトオブバンド(RDMA-CMなし) エフェメラル接続確⽴を含む新設計 導⼊コスト RoCE資産流⽤で増分導⼊可(仕様の主張) 新HW/新SWスタック。相互運⽤成熟に時間 標準化主体 OCP(OWFa 0.9ライセンスのオープン仕様) Ultra Ethernet Consortium(Linux Foundation傘下) 57
58. Google Falconなど学術系・先行技術との比較 以降、非公開 IRN/MPRDMA/NDP/REPS/Hermes/Strack/CONGA 58
59. NIC対応状況 ベンダ 製品 NVIDIA ConnectX-8 (CX8) 800Gb/s 状況 (情報源) MRC実装済み。OpenAI/Microsoftの本番クラスタ（GB200世代）で⼤規模運⽤中 [S3 §1, S4]。 S3のクラスタA/B（4×200G / 8×100Gマルチプレーン）がCX8構成。 AMD⾃⼰申告：MRC標準に先⾏するpre-standard実装を搭載し、MRCを完全サポート。 AMD Pensando Pollara 400 400Gb/s MI350/MI355クラスタでOpenAIと共同検証（AMDラボおよび⼤規模テストクラスタでの検証であり、本番運⽤の主張はない） [S8][S9]。 S3のクラスタC（64GPU、4×100Gプレーン）でMRC評価に使⽤ [S3 §5]。 AMD Pensando Vulcano 800 800Gb/s Broadcom Thor Ultra 800Gb/s Intel — AMD⾃⼰申告（ロードマップ）：MRC対応。 2026年5⽉時点でMI400世代向けに認定（qualification）中、4×200G/8×100Gマルチプレーン構成対応 [S9]。S3も実装NICと して⾔及 [S3 §1]。 Broadcom公式表明：MRC対応。 SRv6ソースルーティングとECMPの両モード、2/4/8プレーン、接続あたり128パスをサポート [S7]。S3のクラスタDで運⽤実証 [S3 §5]。 仕様共同作成者（S1カバーページの著者にIntel所属のTony Hurson、Vivek Kashyapが含まれ、OWF CLA署名企業にIntel Corporationが含まれる [S1 §1.1, S2]）だが、2026年7⽉時点でIntelのMRC対応製品の公表は確認できない。 OCPリポジトリのコード著作権表記（NVIDIA/Broadcom/AMD 2024‒2026）にもIntelは現れない [S12]。 ベンダ対応状況は 2026年6月19日時点の情報です。 59
60. スイッチ対応状況 ベンダ 製品/OS 状況（情報源） NVIDIA Spectrum-4 / Spectrum-5 (Cumulus Linux / SONiC) Broadcom (ASIC) Tomahawk 5 (51.2T) / Tomahawk 6 (102.4T) Arista EOS (7060X6/7060XE7、7800R4、 DES-7700等のAI Etherlink系) OpenAIと協業しTomahawk 5ベースのEOSにSRv6実装 [S3 §1]。⾃社WPでMRC向け機能（uN uSID透過転送、トリミング、 ECN）と多プレーン設計を解説（ベンダ⽂書） [S5]。OCI Stargateで採⽤ [S10][S4]。 HPE Juniper QFX5240 / QFX5241 (Tomahawk 5搭載、Junos OS Evolved)、QFX5250 ベンダ⾃⼰申告: MRCに必要なスイッチ側機能（ECNマーキング、パケットトリミング=DCN、SRv6 uSIDラインレート転送）を 提供済みで「MRC ready」。NACK/SACKはNIC側機能のためスイッチ対応不要と明記 [S6]。 Cisco — 2026年7⽉のブログでMRC/SRv6を「SRv6標準策定者」の⽴場から⽀持する内容を発信しているが、Silicon One/Nexus等での MRC対応製品‧ロードマップの表明はない（調査時点） [S17]。 SRv6サポートを実装し、OpenAI/Microsoftの本番MRCファブリックで運⽤ [S3 §1]。 Broadcom公式表明（3-0検証済み）: MRC対応（ECN、トリミング、SRv6等のスイッチ側機能）[S7]。 ベンダ対応状況は 2026年6月19日時点の情報です。 60
61. 実運用実績として報告されているもの ▪ 本番デプロイ(当事者の公表ベース) • OpenAI Stargate (OCI Abilene, Texas): GB200クラスタ群で本番運⽤。フロンティアモデルの学習に使⽤ • Oracle Cloud Infrastructure: Acceleron Multiplanar網でMRCを本番運⽤と表明 • Microsoft Fairwater: 42,020 GPUでNCCL send-recv理論ピークの最⼤92%を⾃⼰申告 • NIC 3社 × スイッチ複数系統の組み合わせが本番‧テストベッドで動作している Stargate supercomputer built by Oracle Cloud Infrastructure (OCI) in Abilene, Texas 61
62. MRCはどの程度「オープン」か • 公式GitHubリポジトリ ◦ • https://github.com/opencomputeproject/OCP-Multipath-Reliable-Connection 現時点でフル実装は未公開 NDA is required. 62
63. 参考文献 (1/4): 一次ソース [S1] R. Sohan, E. Spada, E. Davis, M. Handley, I. Burstein, T. Hurson, J. Jose, V. Kashyap, R. Pan, S. Sur et al., Open Compute Project: Multipath Reliable Connection (MRC) Specification, Revision 1.0, OCP Foundation, 2026-03-21. https://www.opencompute.org/documents/ocp-mrc-1-0-pdf [S2] R. Sohan et al. (AMD/Broadcom/Microsoft/NVIDIA/OpenAI/Intel), "The Multipath Reliable Connection (MRC) Transport," arXiv:2606.18170, 2026-06-16. https://arxiv.org/abs/2606.18170 [S3] J. Araujo et al. (OpenAI/Microsoft/AMD/Broadcom/NVIDIA), "Resilient AI Supercomputer Networking using MRC and SRv6," arXiv:2605.04333, 2026. https://arxiv.org/abs/2605.04333 / https://cdn.openai.com/pdf/resilient-ai-supercomputer-networking-using-mrc-and-srv6.pdf [S4] OpenAI, "Supercomputer networking to accelerate large scale AI training," 2026-05-05. https://openai.com/index/mrc-supercomputer-networking/ [S12] Open Compute Project, "OCP Multipath Reliable Connection" (GitHub repository: libmrc API headers, samples, BSD-2-Clause, latest tag v1.0.1). https://github.com/opencomputeproject/OCP-Multipath-Reliable-Connection 63
64. 参考文献 (2/4): 一次ソース・規格・関連 draft [S13] Ultra Ethernet Consortium, Ultra Ethernet Specification v1.0.2, 2026-01-28 (v1.0: 2025-06-11, v1.0.1: 2025-09-05). https://ultraethernet.org/wp-content/uploads/sites/20/2026/01/UE-Specification-1.0.2-1.pdf [S14] C. Filsfils, P. Camarillo, A. Abdelsalam (Cisco), G. Lu (Microsoft), J. Brar, D. Becker, A. Jouhari (Oracle), J. Tantsura (NVIDIA), K. Pillai (IBM), K. Patel (Arrcus), "SRv6 for Deterministic Path Placement in AI Backends," draft-filsfils-srv6ops-srv6-ai-backend-04, 2026-06-03. https://datatracker.ietf.org/doc/draft-filsfils-srv6ops-srv6-ai-backend/ [S15] P. Camarillo (Cisco), R. Hui (Microsoft), "SRv6 uSID / SONiC for AI Backend Networks," NANOG 96, 2026-02. https://nanog.org/events/nanog-96/content/5611/ / https://www.segment-routing.net/images/202602-NANOG96-SRv6-AI-Backend.pdf [S20] Open Compute Project, "OCP Software GitHub Process — License." https://github.com/opencomputeproject/OCP-Software-GitHub-Process/blob/master/License.md 64
65. 参考文献 (3/4): ベンダ文書 [S5] Arista Networks, "Multiplanar Scale Out fabrics with MRC" (white paper), 2026-06-09. https://www.arista.com/ (元資料はローカル入手PDFを参照) [S6] HPE Juniper Networking, "MRC: The next evolution in AI data center networking," HPE Community Blog, 2026-06-16. https://community.hpe.com/t5/networking/mrc-the-next-evolution-in-ai-data-center-networking/ba-p/7268667 [S7] Broadcom, "Enabling AI Networking @ Scale with Multi-path Reliable Connections (MRC)," 2026-05-06. https://www.broadcom.com/blog/enabling-ai-networking-scale-with-multi-path-reliable-connections-mrc [S8] AMD, "AMD Advances AI Networking at Scale with MRC," 2026-05-06. https://www.amd.com/en/blogs/2026/amd-advances-ai-networking-at-scale-with-mrc.html [S9] AMD, "Next-Gen Networking Transport for Large-Scale AI Training," 2026. https://www.amd.com/en/blogs/2026/next-gen-networking-transport-for-large-scale-ai-training.html [S10] Oracle, "First Principles: Unlocking Oracle Acceleron Multiplanar Fabric with Multipath Reliable Connection," Oracle Cloud Infrastructure Blog, 2026. https://blogs.oracle.com/cloud-infrastructure/first-principles-multipath-reliable-connection [S11] Microsoft, "Building Resilient Networks for AI Supercomputers," Azure High Performance Computing Blog, 2026. https://techcommunity.microsoft.com/blog/azurehighperformancecomputingblog/building-resilient-networks-for-ai-supercomputers/4516919 [S17] Cisco, "MRC and SRv6: How foundational networking innovations are enabling the next generation of AI supercomputers," 2026-07. https://blogs.cisco.com/datacenter/mrc-and-srv6-how-foundational-networking-innovations-are-enabling-the-next-generation-of-ai-supercomputers [S18] Keysight, "MRC: A New Transport for AIDC," 2026-06-04. https://www.keysight.com/blogs/en/tech/traf-gen/2026/06/04/mrc-a-new-transport-for-aidc 65
66. 参考文献 (4/4): 第三者分析・関連規格・論文 [S16] T. P. Morgan, "OpenAI, Microsoft, And Friends Build A Better, More Scalable Ethernet," The Next Platform, 2026-05-12. https://www.nextplatform.com/connect/2026/05/12/openai-microsoft-and-friends-build-a-better-more-scalable-ethernet/5239078 [S19] G. Lockwood, "MRC" (technical note). https://glennklockwood.com/garden/MRC RFC 8986: Segment Routing over IPv6 (SRv6) Network Programming, 2021-02. RFC 9800: Compressed SRv6 Segment List Encoding, 2025-06. IBTA, InfiniBand Architecture Specification, Volume 1, Release 1.8, 2025. A. Singhvi et al., "Falcon: A Reliable, Low Latency Hardware Transport," ACM SIGCOMM 2025. J. Lu et al., "Alibaba Stellar: A New Generation RDMA Network for Cloud AI," ACM SIGCOMM 2025. T. Hoefler et al., "Ultra Ethernet's Design Principles and Architectural Innovations," arXiv:2508.08906, 2025. R. Mittal et al., "Revisiting Network Support for RDMA (IRN)," ACM SIGCOMM 2018. Y. Lu et al., "Multi-Path Transport for RDMA in Datacenters (MPRDMA)," USENIX NSDI 2018. M. Handley et al., "Re-architecting Datacenter Networks and Stacks for Low Latency and High Performance (NDP)," ACM SIGCOMM 2017. C. Filsfils et al., "Toward Deterministic Path Placement in AI Backends: A Practical SRv6-based Architecture," IFIP CNSM 2025. 66