# Multipath Reliable Connection (MRC) 大規模AI学習ファブリックのためのマルチパスRoCEv2拡張トランスポート Navigation: [[../index|index]] | [[../overview|overview]] > [!note] 検証済み情報の性質 > 本資料は OCP MRC Specification 1.0([S1]、2026-03-21)・MRC Transport 論文([S2]、arXiv:2606.18170)・OpenAI/Microsoft運用論文([S3]、既存 wiki の [[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]] と同一)を一次ソースとし、ベンダー文書・第三者分析を出典区分した66ページの技術解説スライドである。全ページを画像で確認した。p.58 は登壇者により内容が「以降、非公開」とされ、Google Falcon 等の学術系先行技術(IRN/MPRDMA/NDP/REPS/Hermes/Strack/CONGA)との比較の詳細は含まれない。 ## 概要 RoCEv2 RC トランスポートに対する MRC(Multipath Reliable Connection)の拡張内容を、OCP 仕様書・MRC Transport 論文を一次ソースとして技術的に深掘りする解説資料。既存 wiki の [[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]] が主に OpenAI/Microsoft の運用実績を扱うのに対し、本資料は **OCP 仕様書レベルのパケットフォーマット・オペコード空間・EV ステートマシン・NACK 理由コード・SRv6 uSID のデータプレーン詳細**まで踏み込む点が特徴である。 ## 主要メッセージ - MRC は「RoCEv2 を全面的に置き換える汎用トランスポート」ではなく、既存の RoCE RC・QP・RDMA Write・Verbs 資産を流用しながら大規模 AI 学習に必要な部分だけを作り替える production-oriented な限定実装である(p.9-10)。 - MRC の本質は Entropy Value(EV)による「1 QP をパケット単位で数百経路へ spray する」ことにあり、SACK/NACK/トリミング/NSCC/EV ステートマシンはこれを支える基本機構(primitive)の組み合わせである(p.13, 21)。 - SRv6 は MRC の必須構成要素ではなく、OCP 仕様が定義する 3 つの転送モード(ECMP ハッシュ・Structured EV・SRv6 uSID)の 1 つに過ぎない。「MRC = SRv6」は OpenAI 等の著名デプロイに引きずられた誤解であると明言する(p.45)。 - RoCEv2 RC の ACK が「パケット到達」と「RDMA 操作の意味的成功」を一つの信号で兼ねていたのに対し、MRC はこれを配送層(SACK/NACK)とセマンティック層(RDMA ACK/NAK)に分離する。この分離が全パケット自己記述(RETH 毎パケット搬送)による順不同メモリ直接配置を可能にしている(p.29, 36)。 ## 視覚的に重要な図表 **p.1 タイトルスライド** ![[_attachments/MRC_technical_deep_dive/page-001.png]] 発表日 2026/06/30、登壇者 Masayuki Kobayashi(markunet)。 **p.20 MRCの基本動作フロー** ![[_attachments/MRC_technical_deep_dive/page-020.png]] 1 QP のパケットが EV 切り替えで数百パス×複数プレーンへ spray され、到達成功/ECN マーキング/NACK 受信/サイレントドロップの 4 分岐で受信側・送信側それぞれの挙動(SACK 生成、EV の SKIP/ASSUMED_BAD 遷移、選択再送、probe による復帰)を整理する。 **p.23 EV state machine** ![[_attachments/MRC_technical_deep_dive/page-023.png]] GOOD(送信可能)/SKIP(一時除外)/ASSUMED_BAD(到達不能疑い)/DENIED(管理者無効化)の4状態と遷移条件(Bad Path Detected、SACK m=bad、Probe Response、NACK ILH 等)を示す Figure 5(EV State Diagram、原典 OCP 仕様書からの引用図)。 **p.36 MRCのパケットフォーマット** ![[_attachments/MRC_technical_deep_dive/page-036.png]] Ethernet/IP/UDP(dport=4791, sport=EV)/BTH の下に Reliability Header(SETH/NETH/PETH)を追加した全体スタックと、OCP 仕様書 Figure 3(Reliability Packet Stack)を並置する。変更が入る既存ヘッダは BTH と RETH の 2 つのみと明示。 **p.59 NIC対応状況** ![[_attachments/MRC_technical_deep_dive/page-059.png]] NVIDIA ConnectX-8(OpenAI/MicrosoftのGB200世代本番クラスタで運用中)、AMD Pensando Pollara 400/Vulcano 800(pre-standard実装、MI350/MI355・MI400世代向け認定中)、Broadcom Thor Ultra(SRv6/ECMP両モード対応、S3クラスタDで運用実証)、Intelは仕様共同作成者だが対応製品の公表なし、という2026年6月19日時点のベンダー対応状況一覧。 **p.61 実運用実績** ![[_attachments/MRC_technical_deep_dive/page-061.png]] OpenAI Stargate(OCI Abilene, Texas)の航空写真とともに、Microsoft Fairwaterの42,020 GPUでNCCL send-recv理論ピーク最大92%自己申告等、当事者公表ベースの本番デプロイ実績を列挙する。 ## 経路利用・信頼性・輻輳制御の詳細(RoCEv2 RCとの差分) 既存 concept [[MRC]] は arXiv:2605.04333(運用論文)ベースで EV・out-of-order placement・PFC 無効化までを押さえていたが、本資料は OCP 仕様書ベースでさらに以下を明確化する。 - **経路利用**: 標準 RoCEv2 RC は 1 QP が 5-tuple で 1 経路へ ECMP 固定される。NCCL 等の QP scaling は UDP source port を変えて ECMP 経路への分散を狙う確率的回避策に過ぎない。MRC は QP を増やす代わりに 1 QP の各パケットへ異なる EV を付与しパケット単位で spray する(p.13)。 - **信頼性**: go-back-N/in-order 前提から、自己記述パケット(全リクエストパケットに RETH を搬送、VA をパケット毎に更新)+ SACK bitmap による選択再送へ変更。SACK は cack_psn(累積 ACK 最大 PSN)・sack_offset・64bit ビットマップの 3 要素で、損失とリオーダリングを観測で区別できる(p.14, 30)。 - **輻輳制御**: MRC に CNP(Congestion Notification Packet)は存在せず、その役割は SACK に統合される。ECN マーク付きパケットの到着が SACK 即時生成トリガの1つであり、SACK は当該パケットの EV を entropy フィールドにエコーし M フィールド(SKIP)を立てて返す。CNP が伝えていた QP 粒度の輻輳通知は、MRC ではパス粒度の通知に置き換えられている(p.34)。輻輳制御アルゴリズム自体は UET の NSCC(Network Signal Congestion Control、ウィンドウベース)をそのまま採用し、MRC の貢献は「アルゴリズムの発明」ではなく「必要なシグナルの標準化」と位置づける(p.33)。 - **パケットロスの意味の区別**: UET 由来の packet trimming により、輻輳した switch はパケット全体を drop する代わりに payload を切り落とし header を優先的に届ける。receiver は TRIM NACK を返し、sender は「TRIM された→輻輳の可能性」「何も届かず timeout→経路障害の可能性」を区別できる。EV は単なる hash seed ではなく小さな状態を持つ仮想経路識別子として扱われる(p.16)。 ## MPR とオペコード空間 - 受信側主導のインフライト制御として、Maximum PSN Range(MPR、パケット数単位のスライディング受信ウィンドウ)と max_wimm_inflight(WriteIMM のインフライト上限、セマンティック操作粒度の別軸)の2つが新設された。パケットは順不同で届くが WriteIMM の完了通知(ImmDt)はリクエスタ発行順で配送されなければならず、レスポンダは先行リクエストが揃うまで完了情報を退避(stash)する(p.26-27)。 - MRC オペコードは上位 3bit=`0b110` の専用空間を使い RC とは意図的に非互換(p.38)。対応操作は RDMA WRITE First/Middle/Last/Only(Immediate 有無含む)・Acknowledge・Endpoint Request/Response・Reliability SACK/NACK/PROBE の11種類のみで、Read/Send/Atomic は非対応(p.53 参照)。 ## SRv6 統合の位置づけ - OCP 仕様は ECMP ハッシュ・Structured EV・SRv6 uSID の3転送モードを**等格**に定義しており、必須なのは EV によるパケットスプレーそのものである。MRC Transport 論文でもソースルーティングは Optional に分類される(p.45)。 - SRv6 uSID モードでは、宛先 IPv6 アドレス(32bit ロケータ+16bit uSID 列、最大6個)による IPv6-in-IPv6 カプセル化を NIC が encap/decap し、スイッチは pop & left-shift のみを行う純粋な SRv6 トランジットノードとして動作する。OpenAI の実装では EV(32bit)を SRv6 アドレスへアルゴリズム的にマッピングすることで、パス毎に「SRv6アドレス+EV」の二重状態を持つ無駄を回避している(p.47-48)。 - この構成では BGP 等の動的ルーティングプロトコルを無効化し静的ルートをプリプロビジョニングする。OpenAI は全ノードに Clustermapper エージェントを置き SRv6 セルフループプローブで毎ミリ秒全リンクをプローブして障害リンクマップを作成する(p.49)。 ## 適用領域とトレードオフ - 適する用途: 大規模同期 AI 事前学習(42K GPU スケールの NCCL send/recv で大メッセージ 92GB/s/NIC 実証済み)、マルチプレーン Clos のスケールアウト網、単一プレーン既存 RoCE ファブリックの改善(ECMP モードならスイッチ変更なしで導入可)、PFC を撤廃したい lossy Ethernet 運用(p.52)。 - 適さない用途: RDMA Read/Send/Atomic を必要とする汎用 RDMA アプリケーション、受信側 RQ フロー制御(RNR-NAK)前提のアプリ、in-order 配送に依存する設計、汎用マルチテナント DC/フロントエンド網、数十〜数百 GPU の小規模クラスタでの新規導入(p.53)。 - プロトコル設計上の対価として、恒常的なリオーダリングによる MPR/OOO 配置資源の必須化、全パケット自己記述によるヘッダオーバーヘッド増(RC では First/Only のみが運んだ RETH を全パケットが運ぶ)、lossy 動作による回復機構群の実装複雑性増(1%級の持続損失で性能が約1/3まで低下、0.1%ならほぼ無影響)、機能削減による RC との相互運用性放棄、エンドポイント主導の障害処理による NIC 側状態集中(CX8 実装ではリンク断時の全 QP EV 再マッピングが非瞬時でスループットグリッチの原因になると報告)を挙げる(p.54)。 ## 口頭説明・補足 transcript なし(音声・動画は提供されていない)。 ## 概念・実体への接続 - [[MRC]] — 本資料の中核テーマ。パケットフォーマット・EVステートマシン・SRv6統合の仕様レベル詳細を追加する。 - [[SRv6]] — MRC における3転送モードの1つとしての位置づけ、EV↔SRv6アドレスのアルゴリズム的対応を追加する。 - [[Ultra Ethernet]] — MRC が NSCC・packet trimming・SACK/NACK を UET から採用している関係を扱う。 - [[RoCE設計課題]] — RoCEv2 RC の PFC/DCQCN 依存・go-back-N・単一パス制約という課題に対する MRC の解決アプローチ。 - [[マルチプレーンClosトポロジ]] — MRC とマルチプレーントポロジの co-design、EV空間のplane分割。 - [[Masayuki Kobayashi]] — 登壇者。 - [[OCP Foundation]] — MRC仕様の標準化主体。 - [[OpenAI]] / [[NVIDIA]] / [[AMD]] / [[Broadcom]] / [[Microsoft Fairwater]] / [[Oracle]] — NIC/スイッチ対応・本番運用の当事者。 ## 限界・不確実点 - 発表イベント・想定聴衆は本資料単体では確認できない。WebFetch による SpeakerDeck ページのメタデータ取得では「顧客向け技術説明会」との情報が得られたが、スライド本文中に主催イベント名の明記はなく confidence は medium とする。 - p.58「Google Falconなど学術系・先行技術との比較」は登壇者により「以降、非公開」とされており、IRN/MPRDMA/NDP/REPS/Hermes/Strack/CONGA との比較内容自体は本資料に含まれない。 - p.62 で MRC の公式 GitHub リポジトリ(opencomputeproject/OCP-Multipath-Reliable-Connection)への言及があるが、「現時点でフル実装は未公開」「NDA is required」と記載されており、コード自体の検証はできていない。 - ベンダー対応状況(p.59-60)は「2026年6月19日時点」の情報とスライド内に明記されており、時間経過により陳腐化する可能性がある。