# RDMA over Commodity Ethernet at Scale Chuanxiong Guo・Haitao Wu・Zhong Deng・Gaurav Soni・Jianxi Ye・Jitendra Padhye・Marina Lipshteyn（すべて [[Microsoft]]）による SIGCOMM 2016 論文。Microsoft のデータセンター全体への RoCEv2 大規模展開の実体験をまとめた、業界での RoCEv2 本番化の先駆的報告である。 ## 概要 TCP/IP は 40 Gb/s 送信で 6%・受信で 12% という高い CPU 使用率を要求し、バースト性に起因するパケットロスがカーネルスタックのオーバーヘッドと重なり高パーセンタイルレイテンシを悪化させる。RoCEv2 は CPU を介さずリモートメモリへ直接アクセスする RDMA を Ethernet 上で実現し、零パケットロス・低レイテンシ・低 CPU 使用率を提供する。本論文はそれを数万台規模の本番環境に安全に展開するための設計・問題発見・解決を報告する。 ## DSCP-based PFC VLAN-based PFC はパケット優先度と VLAN ID を結合しており、2 つの深刻な問題を生じた。 1. **PXE ブート不能**: VLAN タグを持たない PXE ブート中のサーバが、トランクモードのスイッチポートと通信できない。 2. **Layer-3 越境でのプライオリティ消失**: Layer-2 VLAN 境界を越えると VLAN PCP 値が保持されない。 解決策として **DSCP-based PFC** を設計した。データパケットの優先度情報を VLAN タグから IP ヘッダの DSCP フィールドに移した。PFC ポーズフレーム自体はレイヤ 2 フレームであり変更不要。スイッチと NIC の両方で DSCP 値に基づいたパケット分類・キューイングを行う設計で、主要ベンダー（Arista Networks・Broadcom・Cisco・Dell・Intel・Juniper・Mellanox 等）すべてに対応した。 ## 4 つの安全課題 ### RDMA トランスポートライブロック RoCEv2 は損失なしネットワークを前提とするため、NIC の RDMA トランスポートはシンプルな **go-back-0** リトランスミッションを採用していた。わずか 0.4% のパケットロス率でも 4 MB メッセージが永遠に再送を繰り返し、アプリレベルの goodput がゼロになるライブロックを再現した。 **解決策**: go-back-0 を **go-back-N** に変更。最初のドロップパケットから再送を開始し、それ以前に受信済みのパケットは再送しない。NIC ベンダーと協力して実装した。以来ライブロックを一件も観測していない。 ### PFC デッドロック Clos ネットワークの up-down ルーティングはデッドロックを起こさないと信じていたが、**Ethernet パケットフラッディングとの予期しない相互作用**でデッドロックが実際に発生した。 メカニズム: ARP テーブルのタイムアウト（4 時間）と MAC アドレステーブルのタイムアウト（5 分）の不一致から、ARP エントリは存在するが MAC アドレステーブルにエントリがない「不完全 ARP 状態」が生じる。この状態でパケットが届くとスイッチは全ポートにフラッディングし、損失なしクラスのパケットがロックから脱出できず循環バッファ依存が形成される。 **解決策**: 不完全 ARP エントリに対応する損失なしパケットをドロップする（オプション 3）。ブロードキャストとマルチキャストを損失なしクラスに入れてはならないという教訓を得た。 ### NIC PFC ポーズフレームストーム NIC の受信パイプラインにバグがあり、パイプラインが停止して受信バッファが満杯になると、NIC が常時ポーズフレームを送出し続ける現象（**NIC PFC ストーム**）が生じた。単一の NIC 障害が ToR→Leaf→Spine→全 ToR の連鎖でネットワーク全体を麻痺させる。 **解決策**: 2 つのウォッチドッグ。 - **NIC 側ウォッチドッグ**: NIC のマイクロコントローラが 100ms 以上受信パイプラインの停止を検出すると、ポーズフレームの生成を無効化する。 - **ToR スイッチ側ウォッチドッグ**: サーバ向きポートからのポーズフレームが継続する場合、スイッチは該当ポートの損失なしモードを無効化する（200ms 後に自動再有効化）。 本番で単桁件数の NIC PFC ストームを経験。双方のウォッチドッグ導入後は再発なし。 ### スローレシーバー症状 NIC はキュー・ペアコンテキスト（QPC）・作業キュー要素（WQE）などのデータ構造をサーバのメインメモリに置き、NIC 内の **MTT（Memory Translation Table）** をキャッシュとして使用する（エントリ数 2K、4KB ページで 8MB しかカバーできない）。MTT キャッシュミスが頻発すると受信パイプラインが遅延し、NIC が不必要なポーズフレームを生成してネットワークに波及する。 **緩和策**: (1) ページサイズを 4KB から 2MB に変更し MTT ミス頻度を減少。(2) スイッチ側で動的バッファ共有（dynamic buffer sharing）を有効化。パラメータ α を適切に設定し、輻輳時のバッファ確保を統計的に増大させる。 ## 管理・監視システム ### 設定監視 スイッチとサーバが期待どおりの設定で動作しているかを確認する設定監視サービスを構築。複数のスイッチ種類・ファームウェアバージョン・顧客ごとの異なる設定要件の複雑さを吸収する。 ### PFC ポーズフレームとトラフィック監視 - スイッチとサーバが送受信したポーズフレーム数を監視。 - RDMA トラフィックの各ポートのパケット・バイト数、イングレスポートのドロップ数を収集。 - ポーズ間隔（severity をより正確に反映）はスイッチ側では現時点で非対応のため、ASIC ベンダーに将来実装を要求。 ### RDMA Pingmesh TCP Pingmesh を RDMA 版として実装。512 バイトのペイロードで各サーバに RDMA プローブを送り、ToR・Podset・データセンターの各粒度で RTT（または失敗コード）を記録する能動レイテンシ計測システム。 ## 性能評価 ### レイテンシ 20K サーバが稼働する本番データセンターで、トラフィックの半分を RDMA・半分を TCP で同時計測した結果： - 99 パーセンタイルレイテンシ: RDMA **90µs** 対 TCP **700µs** - TCP はスパイク時に数ミリ秒に達した - RDMA の 99.9 パーセンタイルも約 200µs にとどまり、TCP の 99 パーセンタイル未満 カーネルスタックオーバーヘッドの除去と零パケットロスによる達成。 ### スループット 3 層 Clos ネットワーク（2 ポッドセット、576 + 576 台）での全サーバ同時通信実験： - 集計スループット **3.0 Tb/s**（ネットワーク容量の 60% 利用率） - CPU 使用率は 0% 近傍 - パケットドロップ ゼロ 60% 上限は ECMP ハッシュ衝突に起因し、PFC や HOL ブロッキングは要因ではない。 ## 展開プロセス 5 段階の漸進的展開： 1. 数十台の小規模ラボネットワークで初期バグ排除 2. テストクラスタで成熟度向上 3. ToR レベルのみで本番投入 4. ToR + Leaf（Podset レベル）の PFC 有効化 5. Spine スイッチまで拡張 テストクラスタと本番で同一の管理・監視システムを使用したことが有効に機能した。 ## 教訓 - **理論上正しい設計も本番では予期しない問題が起きる**: PFC デッドロック・ライブロック・スローレシーバーはいずれも事前に想定していなかった。 - **NIC がボトルネック**: RDMA/RoCEv2 のバグの大部分は NIC 由来。スイッチ側より NIC 側の複雑性が高い。 - **管理・監視は最初から必須**: RDMA Pingmesh による能動監視なしでは障害の検知・箇所特定・根本原因分析が困難。 - **損失なしネットワークは低レイテンシを保証しない**: 輻輳時のキュービルドアップと PFC ポーズフレームがレイテンシを増加させる。 ## 関連 - 概念: [[RDMA]] / [[RDMAネットワーク監視]] / [[VPCネットワーク可用性]] - 組織: [[Microsoft]] - 人物: [[Chuanxiong Guo]] / [[Haitao Wu]] / [[Jitendra Padhye]] - 後継研究: [[@2023__NSDI__Empowering Azure Storage with RDMA]] / [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]] ## 出典 - PDF: `.raw/papers/rdma_sigcomm2016.pdf` - DOI: 10.1145/2934872.2934908 - 会議: ACM SIGCOMM 2016, Florianópolis, Brazil, August 22-26, 2016