データセンター輻輳制御 - yuuk1's Digital Garden

# データセンター輻輳制御 ## 定義データセンター輻輳制御は、データセンター内のネットワーク(Ethernet/IP ルーティング)において、高帯域・超低レイテンシ・公平性を同時に達成するための輻輳制御プロトコルおよびメカニズム群である。主な課題は、TCP の高 CPU オーバーヘッドを避けながら損失ゼロのファブリックを維持し、かつ PFC(Priority-based Flow Control)の副作用——head-of-line blocking・不公平性・被害者フロー問題——を解消することにある。 RDMA を IP ルーティングされたデータセンターネットワークで用いる場合の標準プロトコル **RoCEv2** は、損失ゼロのレイヤ 2 を前提とするため PFC に依存する。しかし PFC はフロー単位でなくポート単位で動作するため、スイッチ内外でのインキャスト(多対一通信)時に問題を引き起こす。フロー単位の輻輳制御がこの根本解決策となる。([[@2015__SIGCOMM__Congestion Control for Large-Scale RDMA Deployments]]) ## 主要プロトコル ### DCQCN (Datacenter QCN) Microsoft と Mellanox が SIGCOMM 2015 で発表したレート制御型エンドツーエンド輻輳制御プロトコル([[@2015__SIGCOMM__Congestion Control for Large-Scale RDMA Deployments]])。QCN(IEEE 802.11Qau)と DCTCP を融合し、RoCEv2 上で動作する。NIC ハードウェア(Mellanox ConnectX-3 Pro/ConnectX-4)に実装される。 - 送信者(RP)・スイッチ(CP)・受信者(NP)の三者構造 - スイッチは ECN マーキング(RED 機能)のみ実施し、独自機能は不要 - 受信者 NP が CNP(Congestion Notification Packet)を 50 µs 間隔で生成 - 送信者 RP が収束係数 α を用いてレートを削減・回復 - スロースタートなし——フローは輻輳がなければライン速度で開始 ### DCTCP (Data Center TCP) [[Mohammad Alizadeh]]、[[Albert Greenberg]] らが SIGCOMM 2010 で発表した TCP ベースの輻輳制御([[@2010__SIGCOMM__Data Center TCP (DCTCP)]])。ECN マーキング割合 α を EWMA で推定し、`cwnd ← cwnd × (1 − α/2)` で段階的にウィンドウを削減する。標準 TCP が常に半減するのとは異なり、輻輳度に比例した緩やかな反応により、スイッチのキュー占有率を閾値 K 付近に安定させながら高スループットを維持できる。TCP コード変更は 30 行、スイッチへの要求は単一の CE マーキング閾値 K のみ(既存 ECN ハードウェアを流用可能)。Incast・キュー蓄積・バッファ圧迫の 3 障害を同時に解消することを 6000 台サーバーの本番測定と実機実験で検証した。OS スタックで実装されるため CPU オーバーヘッドが高く、スロースタートを持つためバースト型ストレージワークロードでの性能は制限される。RDMA / RoCEv2 への適用は後継の DCQCN が担う。 **設計の核心**: ECN の 1 ビット系列からマルチビット輻輳情報を抽出することにある。これにより `O(√(C × RTT))` の振動幅(TCP の `O(C × RTT)` に対して大幅に小さい)を実現し、帯域遅延積の 1/7 以下という小さい閾値 K でもスループット損失なく動作する。 ### QCN (Quantized Congestion Notification) IEEE 802.11Qau で標準化された L2 ドメイン向け輻輳制御。フロー識別が L2 アドレスに依存するため、IP ルーティングされたネットワークでは使用不可。 ### TIMELY Google が SIGCOMM 2015(DCQCN と同時期)で発表した RTT 微細変化による輻輳制御。ECN マーキングを使わず遅延信号を使う。CPU 削減は設計目標外。 ## 横断的知見 - **VL2(2009)は TCP + VLB でアドミッション制御なしに輻輳を分散させる先行アプローチを示した**: [[VL2]]([[@2009__SIGCOMM__VL2 - A Scalable and Flexible Data Center Network]])は専用の輻輳制御プロトコルを使わず、(1) TCP のエンドツーエンド輻輳制御でホースモデル適合を強制し、(2) [[Valiant Load Balancing]] でトラフィックをランダム分散して特定リンクの集中を防ぐ二層設計を採用した。この「ネットワークを均一にして TCP に任せる」方針は、その後の RDMA 普及によって「TCP の CPU オーバーヘッドをなくしつつ輻輳を制御する」DCQCN(2015)への設計の進化を際立たせる。VL2 は RDMA を対象外とし、TCP フロー限定でのトラフィック分散を前提とした時代の設計である。(Source: [[@2009__SIGCOMM__VL2 - A Scalable and Flexible Data Center Network]], [[@2015__SIGCOMM__Congestion Control for Large-Scale RDMA Deployments]]) - **DCTCP と DCQCN は同じ ECN 信号を用いながら全く異なる輻輳反応機構を持つ**: DCTCP はウィンドウベースの段階的削減(`cwnd ← cwnd × (1 − α/2)`)を OS スタックで実装し、Incast・キュー蓄積・バッファ圧迫を TCP 30 行変更で解決する。DCQCN はスロースタートなしのレートベース制御を NIC ハードウェアで実装し、RDMA の高スループット・低レイテンシ要件に対応する。同じ ECN メカニズムを共有しながら、前者は汎用 TCP フロー向け、後者は RDMA/RoCEv2 向けという役割分担が成立している。(Source: [[@2010__SIGCOMM__Data Center TCP (DCTCP)]], [[@2015__SIGCOMM__Congestion Control for Large-Scale RDMA Deployments]]) - **AQM(RED/PI)はデータセンター環境では統計的多重化の少なさゆえに機能しない**: DCTCP の検証によれば、RED は TCP の保守的な 2 の 1 削減という反応機構を変えないため、スループット対遅延のトレードオフから抜け出せない。また RED パラメータの設定が難しく(10 Gbps で正しい設定を見つけるのは困難)、設定ミスでスループットが急落する。DCTCP は輻輳度に比例した反応でこのトレードオフを根本的に解消する。(Source: [[@2010__SIGCOMM__Data Center TCP (DCTCP)]]) - **深バッファスイッチは Incast への部分解に過ぎず、短フローのキュー蓄積を悪化させる**: 深バッファ(CAT4948、16 MB)では Incast によるクエリタイムアウトは減少するが、長フローによるキュー蓄積が増大し短メッセージ完了時間が 80 ms 超に悪化する。DCTCP は浅バッファスイッチ(4 MB)で 3 障害を同時に解決する。(Source: [[@2010__SIGCOMM__Data Center TCP (DCTCP)]]) - **単一パス RoCEv2 は LLM 訓練の P2P 通信で理論最適の 9 倍の FCT を示す**: HotNets 2024 のシミュレーション(8,192 ホスト・完全プロビジョニング 2段 Fat Tree・800 Gbps リンク)では、RoCEv2 シングルパスの FCT が理論最適 1 ms に対して 9 ms となった。ECMP コリジョンと PFC の head-of-line blocking が原因。SOTA 輻輳制御(ベストエフォート・シングルパス)で 7 ms、NDP/Homa のようなマルチパストランスポートで 5% 以内に収束する。(Source: [[@2024__HotNets__I've Got 99 Problems But FLOPS Ain't One]]) - **業界はロッシー動作とマルチパスへシフトしている**: PFC の運用複雑性(lossless ネットワーク管理・バッファ縮小による PFC トリガー増加)を嫌い、Ultra Ethernet Consortium を中心に Ethernet ベースのベストエフォート・マルチパス動作が次世代 AI/ML ネットワークの標準として推進されている。ただし既存 RoCE ハードウェアは go-back-N を実装し PFC 依存のため、大規模なハードウェア変更が必要。(Source: [[@2024__HotNets__I've Got 99 Problems But FLOPS Ain't One]]) - **PFC と ECN の協調がデータセンター RDMA 輻輳制御の根本的構造**: DCQCN はスロースタートなしでライン速度から送信を開始するため、PFC を完全に無効化するとパケット損失が頻発し RDMA 性能が壊滅的に低下する。一方、PFC 単体では head-of-line blocking と不公平が避けられない。「PFC を防衛の盾、ECN/DCQCN を攻めの調整機構」として組み合わせる二層構造が必須であり、バッファ閾値($t_{PFC}$・$t_{ECN}$)の適切な設定が正常動作の前提条件となる。(Source: [[@2015__SIGCOMM__Congestion Control for Large-Scale RDMA Deployments]]) - **DCQCN のパラメータは QCN/DCTCP の推奨値をそのまま使えない**: DCQCN は QCN の量子化フィードバックと DCTCP の per-ack フィードバックをいずれも持たない。流体モデル(数値解析)により最適値を導出する必要があり、QCN 推奨(B=150 KB・T=1.5 ms・g=1/16)では 2 フロー系ですら収束しないことが実証されている。正しい設定はタイマー 55 µs・バイトカウンタ 10 MB・$K_{\max}$ 200 KB・$P_{\max}$ 1%・g=1/256。(Source: [[@2015__SIGCOMM__Congestion Control for Large-Scale RDMA Deployments]]) - **マルチベンダー混在環境では AR/DLB の単純 on/off では輻輳が解消しない(ソース: [[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]])**: NVIDIA SN4700(Mellanox ASIC)と Juniper QFX5240(Broadcom ASIC)の混在構成では、Mellanox の Adaptive Routing(AR)と Broadcom の Dynamic Load Balancing(DLB)を組み合わせると CNP(Congestion Notification Packet)・Reorder が多発した。Spine の Ingress interface hashing(受信インターフェースに基づく ECMP ハッシュ)と Leaf の DLB を組み合わせることでリオーダーと CNP が大幅に減少し、デフォルト比でスループットがほぼ 2 倍に改善した。DLB の inactivity-interval には「常に最良な値」が存在せず、経験的チューニングに頼っている。 ## 未解決の問い - DCTCP のウィンドウベース段階的制御と DCQCN のレートベース制御を、同一ネットワーク内で TCP フローと RDMA フローが共存するシナリオで比較した場合、CoS(クラス・オブ・サービス)分離以外の共存手法はあるか。 - DCTCP でも解消できない「ワーカー数が非常に多く初回 RTT の 1 パケットだけでバッファを超過する」Incast に対する根本解はトラフィックスケジューリング以外にあるか。 - DCQCN の流体モデルによる安定性の形式解析は完成しているか。マルチボトルネック(parking lot)シナリオでの最適設定はどう導出するか。 - 100 Gbps・400 Gbps への移行時、PFC headroom や ECN 閾値の計算はどう変わるか。 - TIMELY(RTT 信号)と DCQCN(ECN 信号)を混在ワークロードで比較した場合、どのシナリオでどちらが優位か。 - AI クラスタ(GPU トポロジ・集団通信)特有のトラフィックパターンに対して DCQCN のパラメータは再チューニングが必要か。Azure Storage の実績([[@2023__NSDI__Empowering Azure Storage with RDMA]])での異世代 NIC 間の DCQCN 実装差はどの程度影響するか。 - マルチベンダー Lossless 構成で DLB inactivity-interval の自動最適化は実現可能か? スイッチベンダーの将来機能に依存せずユーザー側で解く手法はあるか? - INTFusion([[@2026__IFIP Networking__INTFusion - Unifying Network and Host Telemetry in Data Center Networks]])は INT によるキュー占有率のリアルタイム検知を TCP インキャスト検知に利用するが、実際の輻輳制御プロトコル(DCQCN/DCTCP)へのフィードバックループは未実装。「テレメトリ = 観測」から「テレメトリ → 制御アクション」への閉ループはどう設計されるか。 - 機械学習によるパラメータ適応(§8 で示唆)は実用化されたか。 - マルチパストランスポート(NDP/Homa/UEC)が LLM 訓練の P2P・all-reduce パターンに対してどの程度の実負荷で有効か。シミュレーション(8K ホスト)から百万 GPU 規模への外挿は成立するか。(Source: [[@2024__HotNets__I've Got 99 Problems But FLOPS Ain't One]]) ## 関連 - 概念: [[RDMA]] / [[RDMAネットワーク監視]] / [[オープンネットワーキング]] / [[AIデータセンタートポロジ]] / [[Incast]] / [[Valiant Load Balancing]] / [[インバンドネットワークテレメトリ]] - ソース: [[@2009__SIGCOMM__VL2 - A Scalable and Flexible Data Center Network]] / [[@2010__SIGCOMM__Data Center TCP (DCTCP)]] / [[@2015__SIGCOMM__Congestion Control for Large-Scale RDMA Deployments]] / [[@2023__NSDI__Empowering Azure Storage with RDMA]] / [[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]] / [[@2024__HotNets__I've Got 99 Problems But FLOPS Ain't One]] / [[@2026__IFIP Networking__INTFusion - Unifying Network and Host Telemetry in Data Center Networks]] - エンティティ: [[Mohammad Alizadeh]] / [[Albert Greenberg]] / [[Microsoft]] / [[Mellanox]] / [[Yibo Zhu]] / [[Chuanxiong Guo]] / [[Jitendra Padhye]] / [[Costin Raiciu]] - 関連 MOC: [[分散深層学習 - MOC]] ## 出典 - [[@2010__SIGCOMM__Data Center TCP (DCTCP)]] - [[@2015__SIGCOMM__Congestion Control for Large-Scale RDMA Deployments]] - [[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]] - [[@2024__HotNets__I've Got 99 Problems But FLOPS Ain't One]]