# Congestion Control for Large-Scale RDMA Deployments Source: [[@2015__SIGCOMM__Congestion Control for Large-Scale RDMA Deployments]] | 原本: `.raw/papers/p523.pdf` > ACM SIGCOMM 2015, August 17–21, London, United Kingdom. DOI: 10.1145/2785956.2787484 著者: Yibo Zhu(Microsoft・UC Santa Barbara), Haggai Eran(Mellanox), Daniel Firestone(Microsoft), Chuanxiong Guo(Microsoft), Marina Lipshteyn(Microsoft), Yehonatan Liron(Mellanox), Jitendra Padhye(Microsoft), Shachar Raindel(Mellanox), Mohamad Haj Yahia(Mellanox), Ming Zhang(Microsoft) 所属: [[Microsoft]] / [[Mellanox]] / UC Santa Barbara --- ## 要旨 現代のデータセンターアプリケーションは 40 Gbps の高帯域と 10 µs 未満/ホップという超低レイテンシを要求するが、従来の TCP/IP スタックは CPU オーバーヘッドが高すぎてこの要件を満たせない。RDMA はその解答だが、IP ルーティングされたデータセンターネットワーク上では RoCEv2 として展開され、損失ゼロのファブリックを保つために PFC(Priority-based Flow Control)に依存する。しかし PFC は head-of-line blocking と不公平を引き起こす。本論文はこれらの問題を解消するエンドツーエンド輻輳制御方式 **DCQCN**(Datacenter QCN)を提案し、Mellanox NIC に実装した。 --- ## 背景と動機 ### なぜ RDMA か TCP は 40 Gbps スループットを達成しようとすると全コアで 20% 以上の CPU 使用率を要し、小サイズメッセージでは CPU がボトルネックになりリンクを飽和できない。RDMA では NIC がホストの CPU を迂回してメモリバッファ間でデータを転送し、クライアント CPU 使用率を 3% 未満に抑えながらリンクを飽和させる。レイテンシも TCP(25.4 µs)に対して RDMA Read/Write で 1.7 µs と 1 桁以上低い(測定: 2 KB メッセージ、40 Gbps スイッチ経由)。 ### PFC の問題 RoCEv2 は無損失 L2 を実現するために PFC を使う。PFC はスイッチが上流エンティティへ PAUSE フレームを送り送信を停止させる機構だが、フロー単位でなくポート(+優先度)単位で動作するため以下の問題が生じる。 - **不公平(parking lot 問題)**: 4 つの送信者(H1–H4)が単一受信者へ送る実験で、H4 が最大 20 Gbps を独占する一方 H1–H3 の最大スループットが H4 の最小を下回る。 - **被害者フロー(victim flow)問題**: 輻輳パスを共有しないフロー VS→VR が、H11–H14 の輻輳によるカスケード PAUSE の影響で 10 Gbps→4.5 Gbps に低下する。経路を共有しないスパインスイッチで 6 百万件超の PAUSE メッセージが発生する。 既存案(QCN・DCTCP・TCP-Bolt・iWarp)はいずれか一つ以上の要件——L3 ルーティング対応・低 CPU オーバーヘッド・超高速スタート——を満たせない。 --- ## DCQCN アルゴリズム DCQCN はレート制御型のエンドツーエンド輻輳制御プロトコルで、QCN と DCTCP を融合し NIC ハードウェアに実装する。スロースタートを持たず、フローは輻輳がなければ送信開始時にライン速度で送り始める。 ### 三者モデル | 役割 | 略称 | 担当 | |---|---|---| | 送信者 | RP(Reaction Point) | レート削減・回復 | | スイッチ | CP(Congestion Point) | ECN マーキング | | 受信者 | NP(Notification Point) | CNP 生成 | ### CP アルゴリズム 出力キューに到着したパケットが閾値 K を超えた場合 ECN マーキングを施す。DCTCP と同様に RED 機能を使い、$K_{\min} = K_{\max} = K$・$P_{\max} = 1$ とするとカットオフ型になるが、後述のパラメータ設定では確率的マーキング(RED ライク)を採用する。 ### NP アルゴリズム ECN マーキングされたパケットが到着したフローに対して、最後の CNP(Congestion Notification Packet)送信から N µs 以内であれば追加 CNP を抑制し、N µs ごとに最大 1 CNP を送信する(N = 50 µs)。ConnectX-3 Pro は 1〜5 µs に 1 CNP を生成でき、40 Gbps で 10〜20 輻輳フローを処理可能。ConnectX-4 では 200 フロー超に対応。 ### RP アルゴリズム CNP を受信すると現レート $R_C$ を削減し、収束係数 α を更新する。 $R_T = R_C, \quad R_C = R_C(1-\alpha/2), \quad \alpha = (1-g)\alpha + g$ CNP を受信しなければ α を減衰させ($\alpha = (1-g)\alpha$)、レートは以下の 3 フェーズで回復する。 1. **高速回復(Fast Recovery)**: $R_C = (R_T + R_C)/2$ を F=5 回繰り返す 2. **加算増加(Additive Increase)**: $R_T = R_T + R_{AI}$(40 Mbps ステップ)、$R_C = (R_T + R_C)/2$ 3. **超高速増加(Hyper Increase)**: バイトカウンタ・タイマーによる高速ランプアップ --- ## バッファ設定 DCQCN が正常に動作するには PFC と ECN の閾値が協調している必要がある。 - **ヘッドルームバッファ $t_{flight}$**: PAUSE メッセージがインフライト中のパケットを吸収できるよう確保。1500 バイト MTU で 22.4 KB/ポート/優先度。 - **PFC 閾値 $t_{PFC}$**: 共有バッファ B とポート数 n から $t_{PFC} \leq (B - 8n \cdot t_{flight})/(8n)$。Arista 7050QX32(12 MB・32 ポート)では 24.47 KB。動的閾値 β を使えば $t_{PFC} = \beta(B - 8n t_{flight} - s)/8$ と現在の占有量 s に応じて調整できる。 - **ECN 閾値 $t_{ECN}$**: ECN が PFC より先に発火するよう $t_{ECN} < \beta(B - 8n t_{flight})/(8n(\beta+1))$。β=8 ではテストベッドで $t_{ECN} < 21.75$ KB。 --- ## 流体モデルとパラメータ最適化 流体モデルは単一ボトルネック(帯域 C)に N 個の貪欲なフローを置き、微分方程式(式 5〜9)で $R_C$・$R_T$・α・キュー長 q・マーキング確率 p の時間発展を記述する。数値解析で以下の最適設定値を導出した。 | パラメータ | 設定値 | |---|---| | タイマー | 55 µs | | バイトカウンタ | 10 MB | | $K_{\max}$ | 200 KB | | $K_{\min}$ | 5 KB | | $P_{\max}$ | 1% | | g | 1/256 | - g=1/16(DCTCP 推奨)ではキュー長振動が大きく、g=1/256 が安定。 - 初期パラメータ(QCN/DCTCP 推奨 B=150 KB・T=1.5 ms)では 2 フロー系で収束不可。タイマーを 55 µs に短縮し、バイトカウンタを 10 MB に拡大することで解決。 --- ## 評価 テストベッド: Arista 7050QX32 × 3 階層 Clos トポロジ(ToR×4・リーフ×4・スパイン×2、全リンク 40 Gbps)、Mellanox ConnectX-3 Pro NIC。 ### ベンチマークトラフィック(クラウドストレージ模擬) 480 機クラスタ 1 日分のトレース(1000 万フロー超)から流量特性を抽出。ユーザートラフィック(ランダム対話)と暴走ディスク再構築(インキャスト)を混在させてシミュレーション。 - **DCQCN なし**: インキャスト次数が増えるとスパインスイッチに 6 百万件超の PAUSE メッセージが発生し、ユーザーフローのスループットが急落。 - **DCQCN あり**: スパインの PAUSE は約 3000 件。ユーザートラフィック 5 対ペアの性能を 80 対ペアで維持——**16 倍のユーザートラフィック**を性能劣化なしに処理。 - インキャスト次数 10 の場合、10 パーセンタイルスループット: DCQCN なし 1.12 Gbps → **DCQCN あり 3.43 Gbps**。 ### レイテンシ 20:1 インキャスト時の出力キュー長の 95 パーセンタイル: DCTCP 162.9 KB → DCQCN 76.6 KB。DCQCN はハードウェアレートリミッタを使うため浅い $K_{\min}$ が使え、キューが短い。 ### PFC と ECN バッファ閾値の重要性 - PFC を無効化した DCQCN: パケット損失が頻発し 10 パーセンタイルスループットがゼロ(RDMA は損失に弱い)。 - PFC 有効・閾値誤設定: 改善するが完全な性能を発揮できない。正確なバッファ設定が必須。 ### マルチボトルネック 複数ボトルネックを持つフロー(parking lot シナリオ)では DCTCP 型カットオフ ECN で不公平が生じるが、確率的 RED マーキングと高速タイマーの組み合わせで緩和できる。 --- ## 実装 DCQCN の NP・RP 状態機械は Mellanox ConnectX-3 Pro/ConnectX-4 NIC のハードウェアに実装されており、レートリミットはパケット単位で行われる。Microsoft のデータセンターで本番展開中(2015 年時点)。スイッチへの独自機能追加は不要で、標準の RED/ECN サポートのみを必要とする。 --- ## 関連研究との対比 | 手法 | L3 対応 | 低 CPU | 超高速スタート | 実装層 | |---|---|---|---|---| | QCN | 否(L2 のみ) | 是 | 是 | NIC | | DCTCP | 是 | 否 | 否(スロースタート) | OS スタック | | iWarp | 是 | 否 | 否 | NIC | | TCP-Bolt | 是 | 否 | 是 | OS スタック | | TIMELY | 是 | 否(目標外) | 是 | NIC | RTT 信号 | | **DCQCN** | **是** | **是** | **是** | **NIC** | TIMELY(Google、同時期 SIGCOMM 2015)は RTT の細粒度変化を輻輳信号にするが、CPU 削減は設計目標でない。両者の比較は将来課題とされた。 --- ## 将来課題 - 100 Gbps・400 Gbps ネットワーク向けの DCQCN/PFC チューニング。 - 流体モデルを用いた安定性の形式解析。 - 機械学習による DCQCN パラメータ適応(§8 で示唆)。 ## 関連 - 概念: [[RDMA]] / [[データセンター輻輳制御]] / [[RDMAネットワーク監視]] - エンティティ: [[Microsoft]] / [[Mellanox]] / [[Yibo Zhu]] / [[Chuanxiong Guo]] / [[Jitendra Padhye]] / [[Ming Zhang (Microsoft Research)]] - 関連 MOC: [[分散深層学習 - MOC]] ## 出典 - 原本: `.raw/papers/p523.pdf` - DOI: 10.1145/2785956.2787484