# MRC ## 定義 MRC（Multipath RC）は [[RDMA]] の RC（Reliable Connection）トランスポートを拡張した新トランスポート機構である。従来の RC は 1 キューペアが 1 パスに固定される単一経路転送だが、MRC では 1 キューペアが数百の並列パスへ同時にパケットスプレーを行う。[[OpenAI]] が開発し、10 万 GPU 超の LLM 訓練クラスタで本番実証した。(Source: [[@2026__LinkedIn__Resilient AI Supercomputer Networking - How MRC and SRv6 Keep 100,000+ GPUs Training]]) 主要特性: - **自動輻輳回避**: 輻輳したパスを動的に避けてトラフィックを再分散する - **マイクロ秒級回復**: リンク障害時に再訓練なしでマイクロ秒単位で回復する - **フロー衝突排除**: 均等分散により単一パス過負荷を防ぐ ## 仕様レベルの機構(OCP MRC Specification 1.0 準拠) - **EV(Entropy Value)の3実現方式**: EV はエンコード先とパス決定の仕組みが異なる3方式が定義される。(1) ECMPハッシュ(レガシー、UDPソースポート+IPv6ならflow labelの32bit、スイッチのECMPハッシュに委ねる可知不能だが安定した方式)、(2) Structured EV(ホップ毎のサブフィールドを各スイッチが読み出す決定的ソースルーティング、EVビットを解釈する対応スイッチが必要)、(3) SRv6 uSID(外側IPv6宛先アドレスのuSIDスタックによる明示パス指定)。3方式は等格に定義され、NIC実装次第でトランスポート層のマルチパスロジックを変えずに入れ替えられる。(Source: [[@2026__SpeakerDeck__Multipath Reliable Connection (MRC) 大規模AI学習ファブリックのためのマルチパスRoCEv2拡張トランスポート]]) - **EVステートマシン**: 送信側は各EVを GOOD(送信可能)/ SKIP(ECNやTRIM NACKによる一時除外、実装定義の時間でGOODへ復帰)/ ASSUMED_BAD(timeoutなど到達不能疑い、probe成功でGOODへ復帰)/ DENIED(controller/管理者による無効化) の4状態で管理する軽量ステートマシンとして扱う。SACK/NACKは原因となった受信データパケットの転送パスEVをそのままエコーし、2bitのMフィールド(SKIP/ALWAYS_SKIP)でECNマーキングをパス単位に紐付ける。(Source: [[@2026__SpeakerDeck__Multipath Reliable Connection (MRC) 大規模AI学習ファブリックのためのマルチパスRoCEv2拡張トランスポート]]) - **配送層とセマンティック層の分離**: RoCEv2 RCのACKは「パケット到達」と「RDMA操作の意味的成功」を1つの信号で兼ねるが、MRCはこれを配送層(PSN到達をSACK/NACKで追跡)とセマンティック層(メモリ書き込み・完了通知の成否を従来型ACK/NAKで追跡)に分離する。「SACKされたがNAKされた」(パケットは届いたがR_KEYが無効等)は矛盾ではなく正当な状態であり、一方の層から他方を推論してはならない(MUST NOT)。この分離を可能にしているのが全リクエストパケットへのRETH搬送(自己記述パケット)である。(Source: [[@2026__SpeakerDeck__Multipath Reliable Connection (MRC) 大規模AI学習ファブリックのためのマルチパスRoCEv2拡張トランスポート]]) - **MPRとWriteIMMインフライト上限**: パケットスプレーによる順不同到着を無制限に許すとNICのオンチップメモリ設計が破綻するため、レスポンダが広告するスライディング受信ウィンドウ Maximum PSN Range(MPR、パケット数=PSN範囲で計数、TCP受信ウィンドウのバイト数版に相当)で上限を設ける。これとは別に max_wimm_inflight がWriteIMMの完了通知(送信順配送が必須)をセマンティック操作粒度で制御する。これによりRCのクレジット制御は廃止された。(Source: [[@2026__SpeakerDeck__Multipath Reliable Connection (MRC) 大規模AI学習ファブリックのためのマルチパスRoCEv2拡張トランスポート]]) - **パケットフォーマット**: 変更が入る既存ヘッダはBTH(rtx/tshビット追加、PSNフィールドのプローブ用途流用)とRETH(全リクエストパケットへの搬送に意味再定義)の2つのみ。METH/TSETH/SETH+CC_STATE/NETH/PETH/ERTH・EETHが新設ヘッダとして追加される。MRCオペコードは上位3bit=`0b110`の専用空間を使いRC非互換、対応操作はRDMA WRITE系(Write/WriteIMMのみ)とAcknowledge/Endpoint Request-Response/Reliability SACK-NACK-PROBEの11種類に限定される。(Source: [[@2026__SpeakerDeck__Multipath Reliable Connection (MRC) 大規模AI学習ファブリックのためのマルチパスRoCEv2拡張トランスポート]]) ## 横断的知見 - MRC は [[RDMA]] の単一パス制約を「1 キューペア = 数百パスのスプレー」として解くアプローチであり、既存の ECMP ハッシュベース多経路と根本的に異なる。ECMP はフロー単位で経路を固定するため衝突が生じるが、MRC はパケット粒度で分散する。(Source: [[@2026__LinkedIn__Resilient AI Supercomputer Networking - How MRC and SRv6 Keep 100,000+ GPUs Training]]) - [[RDMA]] ページで示された PFC pause や head-of-line blocking 問題は、MRC のパス分散によって根本的に緩和できると考えられるが、PFC との相互作用は未確認。(Source: [[@2026__LinkedIn__Resilient AI Supercomputer Networking - How MRC and SRv6 Keep 100,000+ GPUs Training]], [[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]]) - JANOG58 の発表は MRC を「OpenAI 主導で AMD・Broadcom・Intel・Microsoft・NVIDIA と連携開発するオープンプロトコル」と位置づけ、UEC(Ultra Ethernet Consortium)による UET(Ultra Ethernet Transport)の仕様の一部(packet spraying・congestion notification・packet trimming)を取り込んでいると説明する。これは LinkedIn 記事にはない「業界標準化(UEC/UET)との関係」という新たな横断的視点であり、MRC が単独技術ではなくオープンな業界連携の中に位置づけられていることを示す。(Source: [[@2026__JANOG58__AIインフラ時代のデータセンター内光配線の実践知]]) - **原論文(arXiv:2605.04333)で MRC の実装詳細が確定した**: MRC は RoCEv2 の RC(Reliable Connection)トランスポートへの「最小拡張」であり、独自ネットワーク層ではなく通常の Verbs API・QP 抽象を保持したまま write/write-with-immediate のみサポートする。パケット粒度スプレーは QP 起動時に生成する 32-bit EV(entropy value、典型 128〜256 エントリ、CX8 では通常 100 超)を UDP 送信元ポート + IPv6 flow label に埋め込んで実現し、順序保証は各パケットに RDMA 仮想アドレスを含めることで受信側が到着順序に関係なく即座にメモリへ書き込む(out-of-order placement)ことで解決している。PFC(Priority Flow Control)は完全に無効化し best-effort(lossy)Ethernet で動作する——[[RDMA]] ページが指摘する PFC pause 問題は「MRC と共存させる」のではなく「PFC 自体を切る」という設計判断で解消されている。これにより従来の「未解決の問い」(MRC が RoCEv2 上で動くか独自層か、PFC との相互作用)は解決した。(Source: [[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]]) - **NIC 側光モジュールが、MRC の冗長化でも救えない最後の単一障害点として残る**: [[RDMAネットワーク監視]] が整理する計装点 4 層(スイッチ ASIC / NIC・DPU / 集団通信ライブラリ / 物理部品)の観点で見ると、MRC は T0 スイッチ側の光トランシーバ故障(Figure 6 の事例: T0 スイッチのトランシーバがグリッチし 4 リンクが連続フラップ、3 ノードが訓練中でもジョブはクラッシュせずスループット約 25% 低下で 1 分後に全速回復)は自動的に ride out できる。ところが 800Gb/s の NIC 光学を 4x200Gb/s に分割する構成では、**NIC トランシーバ自体がフラップすると NIC の全ポートを同時に失い QP が失敗するため ride out できない**、と原論文は明記する。同じ「光モジュールの物理層故障」でも、故障箇所が T0 スイッチ側か NIC 側かで MRC の耐性が非対称になる——マルチプレーンによる経路冗長化は「複数リンクのうち一部を失う」障害には効くが、「単一 NIC が全プレーンを同時に失う」障害には原理的に効かない。(Source: [[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]]) - **冗長化はリンク障害を「クラッシュ」から「性能劣化」へ転化させるという構図が、MRC とは独立に Aegis(Alibaba Cloud)でも観察されている**: [[@2025__NSDI__Evolution of Aegis - Fault Diagnosis for AI Model Training Service in Production]] の付録 B は、dual-ToR 設計がリンク障害でのタスククラッシュを防ぐ一方、帯域が半減するため障害ケースを性能劣化ケースへ移すと報告する(O(10K) 件超のリンクホットフィックスをホスト隔離なしで実施)。MRC の Figure 6 の事例(光トランシーバのグリッチが 4 リンクをフラップさせジョブはクラッシュしないがスループットが 1 分間 25% 低下)はこれと同型の現象で、アーキテクチャは異なる(dual-ToR の物理冗長 vs MRC のマルチプレーン+マルチパストランスポート)が、「冗長化が進むほど光障害は可用性問題からスループット・尾部レイテンシ問題へ転化する」という帰結は独立ソース間で一致する。(Source: [[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]], [[@2025__NSDI__Evolution of Aegis - Fault Diagnosis for AI Model Training Service in Production]]) - **「リンクフラップは無視してよい」という運用判断は、フラップの絶対数が既に高頻度であるという前提の上に成り立つ**: [[@2024__SIGCOMM__Alibaba HPN - A Data Center Network for Large Language Model Training]] は 1 日あたり 5K〜60K 件のリンクフラップが発生し一時的な性能劣化を持ち込むと報告する。MRC 論文の Figure 5(Cluster A、T0-T1 間リンクフラップが概ね 2〜10 件/分・ピーク約 13 件/分で 250 分間推移)はこれと桁のオーダーが整合し(1 日あたりに換算すると数千件規模)、「フラップの修理は低優先度でよい」という MRC の運用判断は、フラップが稀な例外ではなく定常的に高頻度で発生することを前提にした上で、トランスポート層(MRC のパケットスプレー・選択的再送信)がそれを吸収しきるという設計に支えられている。Alibaba HPN 側はこの高頻度フラップを「問題提起」として記述するのに対し、MRC はマルチパストランスポートによって同じ現象を「無視してよい」水準まで無害化した、という進展として読める。(Source: [[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]], [[@2024__SIGCOMM__Alibaba HPN - A Data Center Network for Large Language Model Training]]) - **「MRC = SRv6」は誤解であり、SRv6は3転送モードの1つに過ぎないという整理が、原論文の記述と整合しつつ明確化された**: 既存の [[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]] は OpenAI/Microsoft の実デプロイ(SRv6 uSID採用)を中心に記述するため、SRv6 が MRC の必須要素であるかのように読める。本スライドは OCP 仕様書レベルで「必須なのはEVによるパケットスプレーそのものであり、ECMPモードだけでMRCは完結する」ことを明示し、SRv6 uSID はあくまで「決定論的パス指定・可観測性・gray failure耐性」を得るための追加投資であって、Structured EVでも原理的に同種の決定論が得られると整理する。著名デプロイ(OpenAI/Microsoft)の事例だけを見るとSRv6が必須に見えるという読み違いのリスクを、仕様書ソースが訂正する構図になっている。(Source: [[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]], [[@2026__SpeakerDeck__Multipath Reliable Connection (MRC) 大規模AI学習ファブリックのためのマルチパスRoCEv2拡張トランスポート]]) - **CNPの廃止先がSACKへの統合であることが、原論文の「PFC無効化」の記述をより具体化する**: 原論文は PFC を完全に無効化し best-effort Ethernet で動作させるという設計判断を報告するが、DCQCN が担っていた輻輳通知(CNP)がMRCでどう代替されるかまでは踏み込まない。本スライドはCNPというパケット自体がMRCに存在せず、その役割がSACKのMフィールド(ECNマーク付きパケット到着でSACK即時生成、当該パスをSKIPとエコー)に統合されていること、かつCNPが伝えていた「QP粒度の輻輳通知」が「パス粒度の通知」へ細分化されていることを明らかにする。(Source: [[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]], [[@2026__SpeakerDeck__Multipath Reliable Connection (MRC) 大規模AI学習ファブリックのためのマルチパスRoCEv2拡張トランスポート]]) - **NICトランシーバの単一障害点(原論文 Figure 6 由来の未解決の問い)に対し、本スライドのベンダー対応状況一覧が間接的な手がかりを与える**: Broadcom Thor Ultraが2/4/8プレーン(接続あたり128パス)の複数分割粒度に対応することが公開されており、原論文が示唆する「ポート分割粒度の変更(4x200Gb/sでなく8x100Gb/s)による被害縮小」が少なくとも一部のNIC/スイッチ実装では選択可能であることが確認できる。ただしCX8(NVIDIA)側の分割粒度変更可否や、分割粒度とトランシーバ単一障害点の関係を直接検証したデータは両ソースとも持たない。(Source: [[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]], [[@2026__SpeakerDeck__Multipath Reliable Connection (MRC) 大規模AI学習ファブリックのためのマルチパスRoCEv2拡張トランスポート]]) - **UEC/UETとの関係が「取り込み」から「共有プリミティブ+スコープの違い」へと精緻化された**: JANOG58の発表はMRCを「UETの仕様の一部を取り込んでいる」と紹介するにとどまるが、本スライドはpacket spraying・out-of-order placement・SACK retransmission・packet trimming・sender-based CC・path-aware load balancing・best-effort Ethernetという共有プリミティブを列挙した上で、MRCとUETを別トランスポートとして分ける理由を「スコープ(AI学習限定 vs AI+HPC汎用)」と「導入時期(既存RoCE資産の早期投入 vs クリーンスレート)」の2軸に整理し、UETのNSCCをそのまま流用している事実を明示する。「取り込み」という一方向の関係ではなく、MRCがUETのサブセット的な実装選択であるという位置づけがより明確になった。(Source: [[@2026__JANOG58__AIインフラ時代のデータセンター内光配線の実践知]], [[@2026__SpeakerDeck__Multipath Reliable Connection (MRC) 大規模AI学習ファブリックのためのマルチパスRoCEv2拡張トランスポート]]) ## 未解決の問い - **NIC 側光モジュールのフラップ(単一障害点)は、AEC(Active Electrical Cable)/DAC への置き換えやポート分割粒度の変更(例: 4x200Gb/s でなく 8x100Gb/s によるプレーン当たり被害の縮小)でどこまで緩和できるか。** 原論文は「異なる光学設計であればこの問題を完全に避けられるかもしれない」と述べるにとどまり具体策は示していない。[[@2026__JANOG58__Rack-Scale GPUサーバーのNW設計と運用までの苦悩]](GPUクラスタ運用ページ参照)は短距離区間で AEC を採用し光 Optics の劣化モードを一部回避する設計判断を示しており、この知見を NIC 側トランシーバの単一障害点にも適用できるか検証が要る。Broadcom Thor Ultraが2/4/8プレーン分割に対応することは確認できたが、分割粒度と単一障害点被害の定量的関係は未検証。 - ~~MRC が取り込んだとされる UET の packet spraying・congestion notification・packet trimming は、UET 仕様全体のうちどの範囲か。~~ → 本スライドにより、共有プリミティブ(packet spraying・OOO placement・SACK retransmission・packet trimming・sender-based CC・path-aware load balancing・best-effort Ethernet)とMRC固有の限定(Write/WriteIMMのみ、AI学習特化)が明確化された。ただしUEC(Ultra Ethernet Consortium)への正式な仕様提出・標準化状況(MRCがOCPの外でUECにどう位置づけられるか)は依然未確認。 - MRC のプレーン内 EV セットは「1% ロス下で意図した帯域の約 1/3」にとどまる(原論文 §5.2.7、本スライドp.54でも同数値を引用)。この劣化は EV セットサイズ・ECN 閾値・SACK 再送速度のどのパラメータに最も敏感か。継続訓練に耐えるロス率の上限はどこにあるか。 - NIC-T0 リンクが完全故障ではなく許容できない高パケットロス率を示す「グレー故障」の場合、MRC 自身は自端末側か相手端末側かを区別できず Clustermapper のポリシー判断(denylist)に委ねる、と原論文は述べる。この切り分けを自動化する余地はあるか([[RDMAネットワーク監視]] の「反応型診断と予防型予測の接続」という未解決の問いと同型)。 - MRC の公式GitHubリポジトリ(opencomputeproject/OCP-Multipath-Reliable-Connection)は libmrc の API ヘッダ・サンプルを BSD-2-Clause で公開する一方、本スライドは「現時点でフル実装は未公開」「NDA is required」と記す。フル実装がNDA下にある理由(特許・ベンダー間の商業的配慮等)は未確認。 ## 関連 - 概念: [[RDMA]] / [[SRv6]] / [[マルチプレーンClosトポロジ]] / [[LLM分散学習]] / [[集合通信]] / [[RDMAネットワーク監視]] / [[データセンターネットワーク信頼性]] / [[Ultra Ethernet]] / [[RoCE設計課題]] - ソース: [[@2026__LinkedIn__Resilient AI Supercomputer Networking - How MRC and SRv6 Keep 100,000+ GPUs Training]] / [[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]] / [[@2026__SpeakerDeck__Multipath Reliable Connection (MRC) 大規模AI学習ファブリックのためのマルチパスRoCEv2拡張トランスポート]] / [[@2025__NSDI__Evolution of Aegis - Fault Diagnosis for AI Model Training Service in Production]] / [[@2024__SIGCOMM__Alibaba HPN - A Data Center Network for Large Language Model Training]] ## 出典 - [[@2026__LinkedIn__Resilient AI Supercomputer Networking - How MRC and SRv6 Keep 100,000+ GPUs Training]] - [[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]](§2.1 MRC プロトコル詳細、§5.1 本番結果 Figure 6・NIC 光学の単一障害点、§5.2.7 RoCE 比較) - [[@2026__SpeakerDeck__Multipath Reliable Connection (MRC) 大規模AI学習ファブリックのためのマルチパスRoCEv2拡張トランスポート]](OCP MRC Specification 1.0 準拠のパケットフォーマット・EVステートマシン・SRv6統合詳細)