# データセンター輻輳制御 ## 定義 データセンター輻輳制御は、データセンター内のネットワーク(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) SIGCOMM 2010 で発表された TCP ベースの輻輳制御。ECN マーキング割合に基づき輻輳ウィンドウを削減する。OS スタックで実装されるため CPU オーバーヘッドが高い。スロースタートを持つためバースト型ストレージワークロードでの性能が劣る。 ### QCN (Quantized Congestion Notification) IEEE 802.11Qau で標準化された L2 ドメイン向け輻輳制御。フロー識別が L2 アドレスに依存するため、IP ルーティングされたネットワークでは使用不可。 ### TIMELY Google が SIGCOMM 2015(DCQCN と同時期)で発表した RTT 微細変化による輻輳制御。ECN マーキングを使わず遅延信号を使う。CPU 削減は設計目標外。 ## 横断的知見 - **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 には「常に最良な値」が存在せず、経験的チューニングに頼っている。 ## 未解決の問い - 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 の自動最適化は実現可能か? スイッチベンダーの将来機能に依存せずユーザー側で解く手法はあるか? - 機械学習によるパラメータ適応(§8 で示唆)は実用化されたか。 ## 関連 - 概念: [[RDMA]] / [[RDMAネットワーク監視]] / [[オープンネットワーキング]] - ソース: [[@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]] - エンティティ: [[Microsoft]] / [[Mellanox]] / [[Yibo Zhu]] / [[Chuanxiong Guo]] / [[Jitendra Padhye]] - 関連 MOC: [[分散深層学習 - MOC]] ## 出典 - [[@2015__SIGCOMM__Congestion Control for Large-Scale RDMA Deployments]] - [[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]]