# データセンター輻輳制御 ## 定義 データセンター輻輳制御は、データセンター内のネットワーク(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]]) ## 子概念 - [[TCP輻輳制御アルゴリズム]] - [[インバンドネットワークテレメトリ]] - [[トランスポートプロトコル設計]] - [[バッファブロートとキュー管理]] - [[ホスト輻輳制御]] - [[マイクロバースト]] ## 主要プロトコル ### 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 ベースの輻輳制御([[@2015__SIGCOMM__TIMELY - RTT-based Congestion Control for the Datacenter]])。ECN マーキングを一切使わず、NIC ハードウェアタイムスタンプによる精密な RTT 計測のみを輻輳シグナルとする点が DCQCN/DCTCP と根本的に異なる。RTT の絶対値でなく**勾配(gradient)**——時間に対する遅延の微分——を用いて輻輳の立ち上がり・立ち下がりを予測することで、標準的な「目標キュー長維持」方式の理論的限界(Kelly ら[33]が指摘する「制御ループより短い時間スケールのキューは制御できない」問題)を回避しながら低レイテンシと高スループットを両立する。低閾値 T_low(バーストによる一時的 RTT スパイクのフィルタ)・高閾値 T_high(尾部レイテンシの上限保証)・HAI(Hyperactive Increase、急激な帯域余剰への高速収束)という 3 つの補助機構を持つ。RDMA(OS-bypass メッセージング)実装の評価で、PFC のみのファブリック比で 99 パーセンタイル尾部レイテンシを 9 倍、最適化済みカーネル DCTCP 比で 13 倍改善する。スイッチ側の変更を一切要求しない点は DCQCN(NIC + スイッチ ECN)・DCTCP(スイッチ ECN)と対照的だが、CPU オーバーヘッド削減は設計目標に含まれない(DCTCP と同様にホストソフトウェアで動作)。 ### HPCC (High Precision Congestion Control) [[Alibaba Group]] が [[Harvard University]]・[[University of Cambridge]]・[[MIT]] と共同で SIGCOMM 2019 に発表した INT(in-network telemetry)ベースの輻輳制御([[@2019__SIGCOMM__HPCC - High Precision Congestion Control]])。ECN の1ビットや RTT という粗粒度シグナルではなく、経路上の各スイッチが ACK にキュー長(qLen)・送信バイトレート(txRate)・リンク帯域容量(B)を直接埋め込み、送信者がリンクごとの inflight bytes を精密に計算・制御する。ほとんどの場合1回のレート更新で適正な送信レートに収束できる点が DCQCN・TIMELY と根本的に異なる。 - 送信者は inflight bytes(未確認応答データ量)をウィンドウで直接制御し、フィードバックが遅延しても過剰送信しない(TCP のウィンドウ機構をデータセンター輻輳制御に応用) - per-RTT で更新される参照ウィンドウ $W_i^c$ により、ACK ごとに反応しつつ同一キュー状態への多重反応(過剰反応)を防ぐ - チューニングパラメータは $\eta$(効率とキュー長のトレードオフ、既定95%)・$maxStage$(定常安定性と帯域回収速度のトレードオフ、既定5)・$W_{AI}$(公平性収束速度のトレードオフ)の3個のみで、いずれも信頼性非依存 - 32台テストベッドで DCQCN 比 99パーセンタイル FCT スローダウンを最大95%削減、320台シミュレーションの incast で DCQCN・TIMELY が発生させる PFC ポーズをゼロに抑制 ## 横断的知見 - **HPCC は INT を「輻輳制御」に使う最初期の応用例であり、後年の INT 活用は「監視・診断」へ主軸を移した**: [[インバンドネットワークテレメトリ]] の横断的知見が集約する INTFusion(2026年、IFIP Networking)は INT をホスト/アプリコンテキストと融合させた**診断**目的の技術として位置づけるが、その原型である INT 自体は HPCC(2019年、SIGCOMM)によって「輻輳制御ループに直接組み込む」形で実用化された。HPCC は ACK に埋め込まれた qLen・txRate・B をそのまま送信レート計算に使い、INTFusion は同じ情報をスイッチ内部の異常検知・トラブルシューティングに使う。同一の技術基盤(INT)が「制御(closed-loop)」と「観測(open-loop diagnostics)」という異なる用途へ7年の間隔を空けて展開されたことは、[[データセンター輻輳制御]] の未解決の問い(INTFusion の項)にある「テレメトリ→制御アクションへの閉ループ」がそもそも HPCC で先行して実現されていたことを示す——ただし HPCC は「輻輳制御に特化した閉ループ」であり、INTFusion が目指す「汎用的な異常検知への応用」とはスコープが異なる。(Source: [[@2019__SIGCOMM__HPCC - High Precision Congestion Control]], [[@2026__IFIP Networking__INTFusion - Unifying Network and Host Telemetry in Data Center Networks]]) - **DCQCN・TIMELY・HPCC は同一の根本課題(粗粒度フィードバック)に3つの異なる軸で挑んだ**: DCQCN は ECN の1ビットマーキング、TIMELY は RTT の時間微分(勾配)という、いずれも間接的・低情報量のシグナルから輻輳の程度を推測するヒューリスティックである。HPCC はこれらとは異なり、INT によってキュー長・送信バイトレート・帯域容量という直接測定値を得ることで、「推測」から「計算」へと輻輳制御の性質そのものを変えた。3方式はいずれも SIGCOMM(2015年×2件、2019年)に発表されており、ECN(2015)→RTT勾配(2015、同時期)→INT直接測定(2019、4年後)という順で、輻輳シグナルの情報量を段階的に増やす方向にデータセンター輻輳制御研究が進化してきたことが分かる。(Source: [[@2015__SIGCOMM__Congestion Control for Large-Scale RDMA Deployments]], [[@2015__SIGCOMM__TIMELY - RTT-based Congestion Control for the Datacenter]], [[@2019__SIGCOMM__HPCC - High Precision Congestion Control]]) - **HPCC は「フローの inflight bytes を直接制御する」ことで、DCQCN・TIMELY が抱えるレート制御という間接性の問題そのものを解消した**: DCQCN・TIMELY はいずれもレート(bps)を輻輳シグナルに基づいて調整するが、輻輳時にはフィードバックの遅延によって実際の inflight データ量がレート制御の意図から乖離しうる(HPCC 論文の実測では、PFC が3ホップ伝播するケースで送信者あたりの inflight bytes が BDP の11倍に達する)。HPCC はレートではなくウィンドウ(inflight bytes の上限)を直接制御することで、フィードバック遅延下でも送信者が限度を超えて送信し続けない構造的保証を持つ。これは、[[データセンター輻輳制御]] の既存知見「PFC を防衛の盾、ECN/DCQCN を攻めの調整機構」とする二層構造とは別軸の解決策——ウィンドウ制御そのものによって PFC への依存度を下げるアプローチである。(Source: [[@2019__SIGCOMM__HPCC - High Precision Congestion Control]]) - **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 には「常に最良な値」が存在せず、経験的チューニングに頼っている。 - **RoCEv2 の PCP/DSCP → TC マッピングにはベンダー横断のデファクト値が存在する(ソース: [[@2024__SpeakerDeck__GPUネットワーク設計・運用 基礎勉強会 Lossless Ethernet - PFC-ECN編]])**: RoCEv2 通信 = DSCP 26 = TC 3、CNP = DSCP 48 = TC 6 という組み合わせが、NVIDIA(Mellanox)の公式推奨値であると同時に Broadcom NIC のデフォルト PCP/DSCP 値とも一致する。DCQCN論文([[@2015__SIGCOMM__Congestion Control for Large-Scale RDMA Deployments]])が示す理論的な RP/CP/NP 三者構造の実装が、実運用では「エンドツーエンドで DSCP 値を揃える」という単純な設定規律に還元されることを示す一次資料。マッピング自体はローカル動作にのみ影響するが、運用上はクラスタ内の全機器で値を統一することが強調されている。 - **PFC は「最終手段」、ECN/CNP による事前抑制が主防御という運用上の位置づけ(ソース: [[@2024__SpeakerDeck__GPUネットワーク設計・運用 基礎勉強会 Lossless Ethernet - PFC-ECN編]])**: PFC の PAUSE フレームがキュー単位で送信を完全停止させる one-shot に近い制御であるのに対し、ECN マーキング→CNP 通知→DCQCN によるレート調整は輻輳が解消するまで継続的に動作する。PFC の継続発動は head-of-line blocking による性能低下に直結するため、「バッファが埋まる前に ECN/CNP で輻輳を通知し、PFC は瞬間的な最終防波堤として使う」という運用規律が、[[データセンター輻輳制御]] の理論(PFC の副作用としての head-of-line blocking)を裏付ける実務知見として確認できる。 - **Headroom バッファはケーブル長と MTU から計算する必要があり、閾値の過大・過小が非対称なコストを生む(ソース: [[@2024__SpeakerDeck__GPUネットワーク設計・運用 基礎勉強会 Lossless Ethernet - PFC-ECN編]])**: XOFF 閾値の設定が高すぎる(Headroom 不足)場合は PAUSE 送信後も届き続ける in-flight パケットを吸収しきれずパケットロスが発生し「lossless でなくなる」。逆に低すぎる(Headroom 過剰)場合は不要な送信停止と帯域幅利用率低下、バッファ資源の浪費を招く。IEEE 802.1Q-2012 が定義する計算式に基づき、ケーブル長が異なる設計ではラック内の左右対称性を保つなど、物理設計とバッファパラメータ設計が密結合していることを示す。 - **ECN は輻輳点自身が送信元 QP 情報を読めないため、3 ホップの通知経路(Reaction Point/Congestion Point/Notification Point)を経由せざるを得ない**: [[@2025__SpeakerDeck__AIインフラを考える]] は、スイッチ(Congestion Point)が ECN マーキングした後、宛先ノード(Notification Point)が CNP を生成して送信元(Reaction Point)へ送り返すという 3 ホップ構造の根本原因が、送信元 QP 情報が BTH(Base Transport Header)に含まれずスイッチから読めない点にあることを示した。IETF Internet-Draft「Fast CNP」(draft-xiao-rtgwg-rocev2-fast-cnp-03、ZTE Corp、2025-06-09)は、この制約を回避してスイッチが直接高速 CNP を送信側へ送る仕組みを提案しており、DCQCN 提案から 10 年を経て輻輳検知の反応速度そのものを短縮する標準化の動きが進んでいることを示す。(Source: [[@2025__SpeakerDeck__AIインフラを考える]]) - **サイレントドロップの通知(Drop Notification)は、輻輳制御とは別に「破棄がどこで起きたか」を高速に伝える仕組みとして提案段階にある**: 同資料は、輻輳・破棄されたパケットのヘッダ部分をトリミングし DSCP 値を輻輳発生場所に応じて書き換えて別優先キューから転送する Trimmed Packet の仕組みを紹介し、受信側 NIC が「Trimmed Packet」として認識し再送制御を起動する新ロジックが必要になるため、従来の Ethernet 受信処理実装だけでは対応できないと指摘する。ECN の CNP が「輻輳が起きたことの予兆」を伝えるのに対し、Drop Notification は「実際にパケットが破棄されたこと」を伝えるという役割分担があり、再送要求のトリガーを高速化する補完的な機構として位置づけられる。(Source: [[@2025__SpeakerDeck__AIインフラを考える]]) - **一般的なLinux TCPスタックの視点では、DCTCPはCUBIC/BBRと並ぶ「プラガブルな輻輳制御アルゴリズムの1つ」として抽象化され、RDMA固有の3ホップ通知経路(RP/CP/NP)やPFCとの協調構造には触れられない**: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 10 ネットワーク]]([[TCP輻輳制御アルゴリズム]])はDCTCPを「キューが非常に浅い段階でECNを生成するように設定されたスイッチを前提とする」とだけ説明し、`cwnd ← cwnd × (1 − α/2)` という反応式やPFCとの二層防御構造には言及しない。同じDCTCPという技術が、汎用OS教科書では「選べる輻輳制御アルゴリズムの1つ」、RDMA専門文献では「PFCの副作用を緩和する必須機構」として全く異なる重みづけで扱われており、読者が参照する文献のレイヤによってDCTCPの理解の深さが大きく変わることを示す。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 10 ネットワーク]] §10.4.1.2.5、[[@2015__SIGCOMM__Congestion Control for Large-Scale RDMA Deployments]]) - **PFCの導入は輻輳の「発生を防ぐ」だけでなく「発生場所を一段上へ動かす」効果を持つ**: [[@2025__IMC__Congestion Patterns in a Large-scale RDMA Datacenter]] は、Meta の本番RDMA AIデータセンターで PFC 一時停止フレームを層別に測定し、ToR→spine 層が他の全層を合計したよりも多くの pause frame を送信する(2桁の差)ことを示した。これは Google[43]・Facebook[50] が報告する TCP/IP データセンターの「最終ホップ(宛先ToR→宛先host)が最も輻輳する」という定説と逆で、PFC が宛先ToRでのバッファ蓄積・パケットロスを防ぐ代わりに、pause frame という形で輻輳シグナルを一段上流(spine層)へ押し上げていることを実測で裏付けた。[[@2015__SIGCOMM__Congestion Control for Large-Scale RDMA Deployments]] が示す「PFC を防衛の盾、ECN/DCQCN を攻めの調整機構」とする二層構造の知見に、「盾として機能した結果、輻輳箇所そのものが移動する」という空間的な帰結が加わる。(Source: [[@2025__IMC__Congestion Patterns in a Large-scale RDMA Datacenter]], [[@2015__SIGCOMM__Congestion Control for Large-Scale RDMA Deployments]]) - **粗粒度カウンタでもバースト性を捉えられるかは「指標の種類」に依存し、時間粒度だけの問題ではない**: 同論文は、PFC一時停止カウント(閾値ベース)とトラフィックレートカウンタ(平均ベース)という2種類の分単位指標を同一リンクで比較し、前者はスパイン間で2桁の不均衡を示す一方、後者は12%差とほぼ均衡して見えることを発見した。原因は短いバーストが並列パスに不均等に分散するとPFC閾値を超える頻度に差が出るが、分単位平均はその変動を均してしまうためである。TCP/IPデータセンター測定([10][11][31][41][50])が一貫して「高分解能テレメトリでなければ短いバーストを捉えられない」と結論づけてきたのに対し、本論文は「指標の種類(閾値ベース vs 平均ベース)」という時間粒度とは独立した設計軸を追加し、既存の粗粒度PFCカウンタ(ほぼ全RDMAネットワークに既に展開済み)がバースト検知に転用できる可能性を示した。(Source: [[@2025__IMC__Congestion Patterns in a Large-scale RDMA Datacenter]]) - **RDMAファブリックはラックローカリティを前提にできない**: 同論文は、host-ToR間とspine-ToR間の平均トラフィックレート差が約16%に留まることを示し、TCP/IPデータセンターで報告される強いラックローカリティ([41])が、AI訓練ワークロード主体のRDMAデータセンターでは成立しないことを実測で確認した。AllReduce(ring/tree構造)やAllToAll(v)(直接点対点交換)といった集合通信パターンがジョブを複数ラックにまたがらせるためである。この「トラフィックの空間的な非局所性」は、上記のPFC輻輳箇所シフトと合わせて、RDMAデータセンターのネットワークコアが構造的にボトルネックになりやすいことの裏付けとなる。(Source: [[@2025__IMC__Congestion Patterns in a Large-scale RDMA Datacenter]]) - **輻輳シグナルの選択(遅延 vs ECN)は「通説」を覆す形で TIMELY によって再検証された**: DCTCP の著者は「データセンターの微小なキューイング遅延の正確な測定は困難な課題」と述べ([[@2010__SIGCOMM__Data Center TCP (DCTCP)]])、遅延ベース輻輳制御を採用しない理由としていた。TIMELY はこれに対し、NIC ハードウェアタイムスタンプとハードウェア ACK 生成という近年の NIC 進化により、データセンターでもマイクロ秒精度の RTT 計測が可能になったことを実験的に示し、ECN マーク割合と RTT の相関は弱い(散布図で相関係数が低い)一方、RTT はスイッチの実キュー占有量とほぼ完全に一致することを実証した。これは「ECN か RTT か」という輻輳シグナルの選択が、単なる実装上の好みではなく計測技術の進歩に左右される設計判断であることを示す。(Source: [[@2015__SIGCOMM__TIMELY - RTT-based Congestion Control for the Datacenter]]) - **TIMELY と DCQCN は同じ SIGCOMM 2015 で独立に発表されたが、シグナル・実装層・展開要件が対照的**: DCQCN は NIC + スイッチ ECN マーキングに依存し RP/CP/NP の 3 ホップ通知経路を要求するのに対し、TIMELY はホスト-ホスト間の RTT のみで完結し、スイッチの変更を一切要求しない。両者とも RDMA/OS-bypass 環境での実装だが、DCQCN はスロースタートなしのレートベース制御を NIC ハードウェアで実装し、TIMELY はホストソフトウェア(NIC タイムスタンプ活用)でレート制御する。「スイッチサポート不要」という展開容易性の代償として、TIMELY は NIC のハードウェアタイムスタンプ精度に強く依存する(RTT ノイズが平均 50 µs を超えると性能劣化)。(Source: [[@2015__SIGCOMM__TIMELY - RTT-based Congestion Control for the Datacenter]], [[@2015__SIGCOMM__Congestion Control for Large-Scale RDMA Deployments]]) - **勾配ベース制御とターゲットキュー長ベース制御は、同じ RTT シグナルからでも全く異なる挙動を生む**: TIMELY の実験(T_low=T_high とした場合、TCP FAST 相当のターゲットキュー長方式に帰着)は、ターゲット方式が低レイテンシ(低い T_target)か高スループット(高い T_target)のどちらかしか達成できないのに対し、勾配方式はキューの立ち上がり・立ち下がりを予測することで両立できることを示した。DCTCP のマルチビット ECN マーク割合による段階的反応(`cwnd ← cwnd × (1 − α/2)`)も一種の「勾配的」設計と言えるが、TIMELY は明示的に時間微分を計算する点でより直接的である。(Source: [[@2015__SIGCOMM__TIMELY - RTT-based Congestion Control for the Datacenter]]) - **「PFC 無効化がパケット損失を招き性能が壊滅する」のは現行 RoCE NIC の go-back-N 設計に起因するのであって、輻輳制御全体の宿命ではない**: 上記の知見(DCQCN の PFC 依存)は現行 RoCE NIC を前提とするが、[[@2018__SIGCOMM__Revisiting Network Support for RDMA]](IRN、SIGCOMM '18)は NIC 側にロス回復(SACK ベース選択的再送)と BDP-FC(帯域幅遅延積フロー制御)を実装するだけで、PFC を無効化してもむしろ性能が向上する(RoCE+PFC比で 6〜83% 改善)ことを示した。DCQCN・Timely のような明示的輻輳制御を併用してもこの傾向は変わらず、IRN への PFC 追加はほとんどの場合性能を悪化させる(最大 39% 悪化)。これは「PFC を防衛の盾とする二層構造が必須」という理解を、「現行 RoCE NIC の go-back-N ロス回復という実装上の弱点があるがゆえに PFC が必須になっている」という、より precise な因果関係へ精緻化する。(Source: [[@2018__SIGCOMM__Revisiting Network Support for RDMA]], [[@2015__SIGCOMM__Congestion Control for Large-Scale RDMA Deployments]]) - **ホストスタック上の CCA をカーネル改変なしに反復できると、DCTCP 系の本番チューニングが月単位から週単位へ落ちる**: [[@2024__SIGCOMM__NetEdit - An Orchestration Platform for eBPF Network Functions at Scale]] は Meta 本番で BPF DCTCP / D2TCP / BET を Struct_ops の eBPF CCA として載せ、開発期間が DCTCP 11か月→RWND 6か月→iCWND 1か月と短縮したと報告する。無効化実験では再送 4.5 倍・タイムアウト再送 29 倍・ToR ダウンリンク輻輳破棄 363.7% 増となり、ホスト側ウィンドウ/CCA 調整が ToR インキャスト緩和に効いていることを示す。本 concept が扱うスイッチ/NIC 中心の DCQCN・HPCC・TIMELY に対し、**ホスト eBPF で既存カーネル CCA を差し替える第三の配備経路**を追加する。ポリシーは測定レイテンシに反応せず階層アドレスから局所性を静的推論する点で、HPCC の INT 閉ループとは対照的である。(Source: [[@2024__SIGCOMM__NetEdit - An Orchestration Platform for eBPF Network Functions at Scale]]) - **PFC 無効化時の性能低下幅は、ロス回復方式(go-back-N vs SACK)によって 1.5〜3倍から「改善」まで反転する**: 現行 RoCE(go-back-N)は PFC 無効化で 1.5〜3 倍性能が悪化するのに対し、IRN(SACK ベース)は PFC 無効化でむしろ性能が向上する。同じ「PFC を切る」という操作が正反対の結果を生む要因は、輻輳制御アルゴリズム(DCQCN/Timely)ではなく NIC のロス回復方式にある。これは、本 concept が扱う輻輳制御プロトコル(DCQCN・DCTCP・TIMELY)の議論に対して、「輻輳が発生した後にどう回復するか」という直交する設計軸(NIC のロス回復機構)が PFC 依存度を左右する主要因であることを加える。(Source: [[@2018__SIGCOMM__Revisiting Network Support for RDMA]]) - **「公平性」の放棄は、専用データセンター輻輳制御アルゴリズムを正当化する明示的な設計判断として書籍レベルでも論じられている**: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 7 TCPの考古学]] は、GoogleがBBRを自社バックボーン内で用いる際「他のBBRフローに対してのみ公平であればよい」と割り切っていることを、輻輳制御研究における「公平性から有害性(harm)ベースの評価への転換」という潮流の具体例として紹介する。本concept が実測データから積み上げてきたDCQCN・DCTCP・HPCCのような単一管理ドメイン向け専用アルゴリズムの正当化根拠(RoCEv2は損失ゼロのL2を前提にできる、データセンターは単一管理ドメインでECNを全スイッチで有効化できる等)は、この「公平性を放棄してよい領域を切り出す」という設計思想の技術的な実装例として位置づけ直せる。すなわち本concept は「どう実装するか」を、[[トランスポートプロトコル設計]] と [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 7 TCPの考古学]] は「なぜ公平性を放棄してよいのか」を補完的に説明している。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 7 TCPの考古学]] §7.2, [[@2015__SIGCOMM__Congestion Control for Large-Scale RDMA Deployments]]) - **エッジツークラウド・クラウドツークラウド・イントラクラウドという3分類は、本concept が扱う各アルゴリズムのデプロイ範囲を整理する枠組みを提供する**: 同章は今日のTCP接続の大半を「エッジツークラウド」「クラウドツークラウド(通常はプロバイダーのバックボーン経由)」「イントラクラウド(データセンター内のサーバ間)」の3つに分類し、後2者では特定用途に特化した輻輳制御アルゴリズムがすでに稼働していると述べる。本concept が集約するDCQCN・DCTCP・TIMELY・HPCCはいずれも「イントラクラウド」区分に、GoogleのバックボーンBBRは「クラウドツークラウド」区分にそれぞれ対応づけられる。この3分類のもとでは、単一の普遍的な輻輳制御アルゴリズムに合意する必要は薄れ、「真のピアツーピア転送が必要になる稀な状況でのフォールバック機構」だけが汎用アルゴリズムに残された役割になるとされる。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 7 TCPの考古学]] §7.2) - **広域インターネット向けの前提(long-fat pipe、多様な既存TCPフローとの共存)とデータセンター内の前提(単一管理ドメイン、浅いバッファのコモディティスイッチ)は、同じ教科書の同一節に並べて初めて対比が際立つ**: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 6 Congestion Control]] §6.4.2は、CUBIC(大きな帯域遅延積を持つ long-fat networks 向けに素早く容量を埋めることを目指す)・BBR(広域インターネットでの公平性が未解決の開発中課題)・DCTCP(データセンターは単一管理ドメインのため他の TCP フローとの公平性を気にせず専用チューニングができ、long-fat pipe を想定しないため浅いバッファのコモディティスイッチで運用される)を同一の「ソースベースのアプローチ」節に並べて説明する。[[@2010__SIGCOMM__Data Center TCP (DCTCP)]] 自身も「データセンター内の均質なネットワーク・単一管理ドメインの前提が成立する場合に有効」と限界として明記しており(§9)、広域インターネット向け設計(CUBIC/BBR)とデータセンター向け設計(DCTCP)の分岐点は、アルゴリズムの巧拙ではなく「管理ドメインが単一かどうか」「バッファ深度をどう仮定するか」という環境側の前提にあることが、汎用教科書とデータセンター論文を重ねることで一段と明確になる。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 6 Congestion Control]] §6.4.2, [[@2010__SIGCOMM__Data Center TCP (DCTCP)]] §9) - **Jainの公平性指標という同一の物差しが、単一管理ドメイン内では理想値に近い結果を、広域インターネットでの異種アルゴリズム混在では壊滅的な値を示す**: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 6 Congestion Control]] §6.1.3が定式化するJainの公平性指標そのものは「良い/悪い」の絶対基準を持たない相対的な尺度だが、[[@2010__SIGCOMM__Data Center TCP (DCTCP)]]は10 Gbpsで最大90フローを競合させた公平性テストでJain公平性指数0.99を報告する(単一管理ドメイン内のDCTCPフロー同士)。一方、ch.6 §6.4.2が報告するBBR対CUBICの広域インターネット実験では、CUBICフローが帯域を100分の1しか得られない事例がある。同じ指標を異なる展開範囲(単一管理ドメイン内 対 広域インターネットでの異種アルゴリズム混在)に適用すると正反対の結果になることは、[[データセンター輻輳制御]] が既存知見で述べる「専用アルゴリズムが公平性を放棄できるのは管理ドメインが閉じているから」という設計判断を、Jain指標という共通の物差しの上で定量的に裏付ける。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 6 Congestion Control]] §6.1.3, §6.4.2, [[@2010__SIGCOMM__Data Center TCP (DCTCP)]] §7) - **輻輳制御の反応速度に対する要求は、µburstの実測により「1 RTT未満」まで切り詰められる**: [[@2017__IMC__High-Resolution Measurement of Data Center Microbursts]] は、Facebook本番データセンターの25µs粒度計測により、輻輳イベントの90パーセンタイルが200µs以下で終息する[[マイクロバースト]](µburst)であることを示した。TIMELY・DCQCNのようなパケットドロップ/RTT変動/ECNを信号とする輻輳制御は、いずれも信号がsenderに到達するまで最低RTT/2を要し、収束に複数RTTを要しうる。多くのµburstが単一RTTより短命であるという実測は、これらの信号がそもそも間に合わない輻輳イベントが相当数存在することを意味し、より低遅延な輻輳シグナル(バッファ側での即時対応や、TCPペーシングのハードウェア実装強化)の必要性を実測データで裏付ける。本concept が集約するDCQCN(2015)・TIMELY(2015)・HPCC(2019)はいずれもこの2017年の実測に先行または近接して提案されており、µburstスケールでの検証は本wiki内でまだ行われていない。(Source: [[@2017__IMC__High-Resolution Measurement of Data Center Microbursts]]) - **µburst実測は「バーストは同期的挙動」という[[@2025__IMC__Congestion Patterns in a Large-scale RDMA Datacenter]]の観測に、独立した1次データで先行する**: 同じIMCという場で8年隔てて発表された両論文は、共に「マイクロ秒〜ミリ秒スケールでの同期的バースト」を扱うが、認識論的に異なる。[[@2017__IMC__High-Resolution Measurement of Data Center Microbursts]] はマルコフ連鎖の尤度比検定でバースト到着の自己相関を統計的に証明し(r_web=119.7等)、[[@2025__IMC__Congestion Patterns in a Large-scale RDMA Datacenter]] はPFC一時停止カウンタとポート間の負荷不均衡を関連づける。両者とも「輻輳は独立事象の集積ではなく相関を持つ」という同一の経験則に、異なる年代・異なるネットワーク種別(前者はEthernet ToR、後者はRDMA)で独立到達している。 - **単一ポート計測の限界(2017年)は、ホスト側同期計測(2022年)によって初めて克服された**: [[@2017__IMC__High-Resolution Measurement of Data Center Microbursts]] はスイッチ側で一度に1ポートしかサンプリングできず、複数バーストが共有バッファを同時に奪い合う「輻輳(contention)」を分析できないという制約を自ら認めていた。[[@2022__IMC__A Microscopic View of Bursts, Buffer Contention, and Loss in Data Centers]] は計測点をスイッチからホストへ転換し(eBPFベースのMillisampler)、ラック内の全ホストを時刻同期させるSyncMillisamplerによってこの制約を解消した。その結果、「輻輳が高いほど損失が多いとは限らない」(RegA-Typicalの損失率がRegA-Highの2.9倍)という、単一ポート計測では原理的に発見不可能だった非自明な関係を実証した。これは、輻輳制御研究において「反応速度」(2017年の知見: µburstは1 RTT未満で終息する)と「輻輳とバッファ資源競合の相互作用」(2022年の知見)が、計測手法の進化(スイッチ単一ポート→ホスト分散同期)によって段階的に明らかになってきたことを示す。(Source: [[@2017__IMC__High-Resolution Measurement of Data Center Microbursts]], [[@2022__IMC__A Microscopic View of Bursts, Buffer Contention, and Loss in Data Centers]]) - **DT(dynamic threshold)バッファ共有アルゴリズムのパラメータαは、輻輳が低いほど結果への影響が大きい——本concept の「PFC/ECN二層構造」の議論に「バッファ割り当ての公式」という定量的な基盤を追加する**: [[@2022__IMC__A Microscopic View of Bursts, Buffer Contention, and Loss in Data Centers]] は、Choudhury-Hahneの動的しきい値公式 `T = α×B / (1+α×S)`(Sはアクティブキュー数)から、αが大きいほど同じSに対する割り当ては大きくなるが、Sの変化に対する変動幅(傾き)も低輻輳領域で急峻になることを示した。Meta本番フリートの既定値はα=1で、単独アクティブキューはバッファの50%、輻輳が全く生じない場合でも実際のToRでは約1.8MBが上限となる。本concept が集約するDCQCN・DCTCPはこの共有バッファの「内側」で動作するエンドツーエンド輻輳制御だが、[[@2022__IMC__A Microscopic View of Bursts, Buffer Contention, and Loss in Data Centers]] はその「外側」にあるバッファ割り当てそのものの変動(中央値33.3%減、15%のrunで70%超減)が、輻輳制御アルゴリズムが対処しなければならない環境条件を大きく左右することを定量的に示した。(Source: [[@2022__IMC__A Microscopic View of Bursts, Buffer Contention, and Loss in Data Centers]]) - **輻輳制御研究の「end-to-end」の終端がNICだったという暗黙の前提は、ホスト輻輳の発見によって覆される**: 本concept が集約するDCQCN・DCTCP・TIMELY・HPCCはいずれもNICを輻輳制御の終端とみなし、NIC-CPU/メモリ間のホストネットワークを不可視の領域として扱う。[[ホスト輻輳制御]]([[@2023__SIGCOMM__Host Congestion Control]])は、高帯域アクセスリンクの普及とホスト内資源(CPU・キャッシュ・メモリ帯域)の技術トレンド停滞のギャップから、ネットワークファブリックとは別にホストネットワーク内でも輻輳(ホスト輻輳)が生じることを実測で示した。ホストネットワークはロスレスなクレジットベースフロー制御を用いるため、輻輳点(メモリコントローラ)ではなく輻輳点から離れたNICバッファでキューイングとドロップが生じ、「パケットドロップは輻輳点で発生する」という本concept の全プロトコルが暗黙に置く前提が破られる。(Source: [[@2023__SIGCOMM__Host Congestion Control]]) - **hostCCはDCTCPを置き換えずホスト輻輳シグナルをエコーする形で統合する、既存プロトコルへの非侵襲的拡張の実例**: DCQCN・TIMELY・HPCCがいずれもゼロから設計された専用プロトコルであるのに対し、hostCCは既存のDCTCP実装を変更せず、ホスト輻輳シグナル(IIOバッファ占有量)をECNマーキング経由でDCTCPへエコーするだけで統合する。ネットワーク輻輳制御プロトコル自体の設計を変えずに新しい輻輳源(ホスト)へ対応範囲を拡張できることを示しており、本concept が集約するプロトコル間の「シグナルの情報量を段階的に増やす」進化(ECN→RTT勾配→INT直接測定)とは別の軸——「輻輳が発生する場所を拡張する」という軸——を追加する。(Source: [[@2023__SIGCOMM__Host Congestion Control]]) - **RHCCはDCQCNと"min(受信側レート, 送信側レート)"で統合する新しい合成パターンを示した**: [[@2024__APNet__Rethinking Intra-host Congestion Control in RDMA Networks]](RHCC)は、hostCCのECNエコー方式とは異なる統合方式を採る。RDMA受信側カーネルモジュールがデータパケットを直接改変できないためECNマーキングが使えず、代わりにMellanoxのProgrammable Congestion Control(PCC)によるプローブ機構で受信処理遅延を測定し、ホスト内資源から求めた許容レート$R_{rev}$を計算する。最終送信レートは$R_{trans} = \min(R_{rev}, R_{cc})$として、$R_{cc}$(DCQCNが計算するホスト間輻輳制御レート)と単純な最小値合成で統合する。これは、hostCC(ECNシグナルをネットワーク輻輳制御プロトコルの入力に混ぜ込む)とは異なる「2つの独立したレート計算を後段で min 合成する」という設計であり、DCQCN側のアルゴリズムを一切変更しない点は共通しつつ、統合のメカニズムが異なる2つの実例が本concept に揃ったことになる。(Source: [[@2023__SIGCOMM__Host Congestion Control]], [[@2024__APNet__Rethinking Intra-host Congestion Control in RDMA Networks]]) - **RHCCとDCQCNの併存下でのPFC削減効果は、ホスト内輻輳応答の速さがホスト間輻輳制御の発火頻度を左右することを定量的に示す**: 拡張ジャーナル版 [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]] は、Incastによるホスト間輻輳とMLCによるホスト内輻輳(3倍)を同時発生させた実験で、素のDCQCNが大きなPFC一時停止と深刻な性能劣化を示す一方、RHCCを組み合わせるとPFC一時停止が最大2.9倍削減されネットワークスループットが最大1.85倍改善することを示した。これは、本concept が集約するDCQCN・PFCの相互作用(PFCがヘッドオブラインブロッキング・PFCストームを招く副作用として知られる)が、NIC-スイッチ間だけでなくホスト内輻輳の有無によっても左右されることを、ホスト輻輳制御とデータセンター輻輳制御の統合実験で初めて定量化した例である。(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]]) - **HotNets 2024 のシミュレーションが予測した「マルチパストランスポートが単一パス RoCEv2 の 9 倍の FCT を理論最適の 5%以内へ縮める」という結果を、UCCL-Tran は実機テストベッドで裏づける**: 本 concept の既存知見(§横断的知見)は 8,192 ホストのシミュレーション環境で NDP/Homa のようなマルチパストランスポートが単一パス RoCEv2 の性能劣化を大幅に改善しうると予測してきたが、[[@2026__OSDI__UCCL-Tran - An Extensible Software Transport Layer for GPU Networking]] は実機の NVIDIA ConnectX-7・Broadcom Thor-2・AWS EFA テストベッド上でパケットスプレー型マルチパス(256 QP、power-of-two サンプリング)と受信側主導 CC(EQDS)を実装し、フロー衝突が起きる fat-tree トポロジで既存 RDMA ハードウェアトランスポート比 all-to-all 最大 4.54 倍、incast/permutation トラフィックで P99.9 レイテンシ最大 4.88 倍の改善を測定した。シミュレーションが示した「マルチパス化の理論的な有効性」を、ソフトウェアトランスポート層という具体的な実装経路によって本番規模に近いテストベッドで実証した点で、両者は予測と検証の関係にある。(Source: [[@2024__HotNets__I've Got 99 Problems But FLOPS Ain't One]], [[@2026__OSDI__UCCL-Tran - An Extensible Software Transport Layer for GPU Networking]]) - **業界が指摘してきた「ロッシー動作・マルチパストランスポートへのシフト」は、大規模ハードウェア変更を待たずソフトウェアだけで先行実装できる**: 本 concept の既存知見は、Ultra Ethernet Consortium 中心のマルチパス標準化が「既存 RoCE ハードウェアが go-back-N を実装し PFC 依存のため大規模なハードウェア変更が必要」という前提に立つと述べてきたが、UCCL-Tran は既存 RDMA NIC(NVIDIA・Broadcom・AWS)を一切改造せず、RDMA UC の `write_with_immediate` でコントロールパスをホスト CPU へ切り離すことで同じ目標(パケットスプレー・受信側主導 CC・選択的再送)をソフトウェアのみで達成する。UEC のようなハードウェア標準化を待つアプローチと、UCCL-Tran のような既存ハードウェア上のソフトウェア先行実装というアプローチが並行して進んでいることを示す。(Source: [[@2024__HotNets__I've Got 99 Problems But FLOPS Ain't One]], [[@2026__OSDI__UCCL-Tran - An Extensible Software Transport Layer for GPU Networking]]) - **本conceptが集約する「PFCを防衛の盾、ECN/DCQCNを攻めの調整機構」とする二層構造は、H&P Appendix Fが2019年時点で提示した輻輳管理の3分類(パケット破棄・フロー制御・チョークパケット)のうち後2者の組み合わせに正確に対応する**: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Appendix F Interconnection Networks]] §F.7は、輻輳制御機構を(1)パケット破棄(ロッシー網、Internet的)、(2)リンクレベルのフロー制御によるバックプレッシャ(ロスレス網、SAN的)、(3)チョークパケット(スイッチが閾値超過を検知し送信元へ通知して注入レートを下げさせる)の3方式に分類し、(2)は「輻輳源への通知が遅すぎ、輻輳を未然に防げない」、(3)は「通知遅延が長いと不安定化し振動または帯域利用率低下を招く」という異なる弱点を持つと述べる。本conceptが集約するRoCEv2の設計([[@2015__SIGCOMM__Congestion Control for Large-Scale RDMA Deployments]])は、まさにPFC(クレジットではなくPAUSEフレームによるリンクレベルバックプレッシャ、Appendix Fの分類(2))を「最終防波堤」、ECNマーキング+CNP+DCQCNのレート調整(スイッチが閾値超過を検知し送信元通知する点でAppendix Fのチョークパケット(3)に相当)を「事前抑制」として組み合わせる構造そのものである。Appendix Fが一般論として指摘する各方式固有の弱点(バックプレッシャの通知遅延・チョークパケットの不安定化リスク)は、本conceptが集約するPFCのhead-of-line blocking問題やDCQCNのパラメータチューニングの困難さ(QCN推奨値では2フロー系すら収束しない)と符合し、RoCEv2の輻輳制御アーキテクチャは1980〜2000年代の相互結合網研究が既に整理していた古典的な3分類のうち2つを、データセンター規模で組み合わせ直したものだと分かる。(Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Appendix F Interconnection Networks]] §F.7, [[@2015__SIGCOMM__Congestion Control for Large-Scale RDMA Deployments]]) - **400GbE の Lossless 構成では、PFC・ECN/CNP・ETS を個別機能でなく一つの運用検証単位として扱う必要がある**: [[@2023__JANOG52__AI ML基盤の400G DCネットワークを構築した話]] は、200GbE の Congestion Point を作って ECN/CNP を検証し、キュー優先度を ETS で確認するとともに、L3 ルーティング、BGP 迂回、400Gbps の E2E 帯域も確認した。PFC/ECN の閾値調整だけでなく、経路制御・優先度・実効帯域を含む検証が必要であることを示す。(Source: [[@2023__JANOG52__AI ML基盤の400G DCネットワークを構築した話]]) - [パケット粒度ソフトウェア制御による輻輳制御の拡張基盤] SCR([[@2025__NSDI__White-Boxing RDMA with Packet-Granular Software Control]])は、DCQCNのようにASICへ焼き付けられた輻輳制御に代わり、BlueField-3 DPA上のイベント駆動フレームワークでSwift(delay-based CC)のRTT測定・ターゲット遅延計算を再現し、原設計と一致する収束挙動を確認した。DCQCNがスイッチのECNマーキングのみに依存するのに対し、SCRはFabric/Host/Peerドメインの信号を統合し、輻輳制御アルゴリズム自体をソフトウェアへ持ち出す点で異なる。(Source: [[@2025__NSDI__White-Boxing RDMA with Packet-Granular Software Control]]) - [クレジットベースCCの実装課題] Pegasusは16KBバッチ単位のクレジットベース輻輳制御をFPGA版RNICにオフロードした際、QP数が4〜8と少ない場面でハードウェア送信スレッドの状態遷移遅延に起因する「クレジットジッタ」でスループットが理想値より8%以上低下する問題を発見した。対策として、十分なクレジットが無くても一定バッチサイズまで送信を許可し(クレジット値が一時的に負になることを許容)、この低下を解消した(Source: [[@2026__SIGCOMM__Pegasus - A Data Center Network for Bare-Metal AI Cloud]])。 ## 未解決の問い - ホスト輻輳が存在する環境で、TIMELY・HPCCのような他のRDMA/RoCEv2向け輻輳制御プロトコルはhostCC/RHCCと同様のホスト輻輳シグナル統合で拡張可能か。[[@2024__APNet__Rethinking Intra-host Congestion Control in RDMA Networks]](RHCC)およびその拡張ジャーナル版 [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]] はいずれもDCQCNとの統合(min合成)のみを実測で示しており、TIMELYのRTT勾配・HPCCのINT直接測定という別の輻輳シグナル体系との統合は未検証のまま残る。PFCとホストローカル輻輳応答の相互作用も、RHCCはPFC一時停止時間の削減(基本シナリオで最大64%、cross-NUMAシナリオで最大92%、ホスト間・ホスト内輻輳併存シナリオで最大2.9倍)を実測で示したが、PFCのheadroom計算やheadroomパラメータとの相互作用の理論的な分析は行われていない。([[ホスト輻輳制御]]、[[@2023__SIGCOMM__Host Congestion Control]]、[[@2024__APNet__Rethinking Intra-host Congestion Control in RDMA Networks]]、[[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]]) - DCTCP のウィンドウベース段階的制御と DCQCN のレートベース制御を、同一ネットワーク内で TCP フローと RDMA フローが共存するシナリオで比較した場合、CoS(クラス・オブ・サービス)分離以外の共存手法はあるか。 - DCTCP でも解消できない「ワーカー数が非常に多く初回 RTT の 1 パケットだけでバッファを超過する」Incast に対する根本解はトラフィックスケジューリング以外にあるか。 - DCQCN の流体モデルによる安定性の形式解析は完成しているか。マルチボトルネック(parking lot)シナリオでの最適設定はどう導出するか。 - IRN(2018)は NIC 側のロス回復方式変更だけで PFC 依存を解消できることを示したが、DCQCN のような輻輳制御アルゴリズム自体の設計(ECN 閾値・レート更新式)は IRN の登場でどう見直されるべきか。IRN は輻輳制御と直交すると主張するが、ロス回復が高速化された環境で ECN ベースの輻輳検知の役割はどう変わるか。([[@2018__SIGCOMM__Revisiting Network Support for RDMA]]) - 100 Gbps・400 Gbps への移行時、PFC headroom や ECN 閾値の計算はどう変わるか。 - TIMELY(RTT 信号)と DCQCN(ECN 信号)を混在ワークロードで比較した場合、どのシナリオでどちらが優位か。TIMELY 論文自身も両者の CPU 使用率を含めた直接比較を将来課題として明記しており([[@2015__SIGCOMM__TIMELY - RTT-based Congestion Control for the Datacenter]])、10 年以上を経た現在もこの比較を行った一次資料は本 wiki 内に未収載。 - TIMELY のようなホスト完結型(スイッチ変更不要)の遅延ベース輻輳制御は、100/400 Gbps 以降のデータセンター速度でも有効であり続けるか。TIMELY 論文はこれを明示的な将来課題として残している。(Source: [[@2015__SIGCOMM__TIMELY - RTT-based Congestion Control for the Datacenter]]) - 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)へのフィードバックループは未実装。HPCC([[@2019__SIGCOMM__HPCC - High Precision Congestion Control]])が輻輳制御に特化した閉ループを既に実現している一方、INTFusion のような汎用診断向け INT 活用へこの閉ループ設計思想を輸入する余地はあるか。 - HPCC は本番評価を32台テストベッド・320台シミュレーションで行っているが、10万+GPU 規模の現代 LLM 訓練データセンター(AllReduce/AllToAll の複数ボトルネックが常態化する環境)で inflight bytes 推定(Eqn 1)の「単一ボトルネック仮定」がどこまで崩れるか、複数ボトルネック時の収束ラウンド数増加は実運用上どの程度深刻か。 - HPCC の INT オーバーヘッド(最大42バイト/パケット、5ホップ)は 100Gbps 世代の実験に基づく。800Gbps・1.6Tbps 世代でパケットサイズ・ホップ数が変化した場合、INT ヘッダオーバーヘッドと長フローのスループット劣化(§5.3 で示された1.24倍のトレードオフ)はどう変化するか。 - 機械学習によるパラメータ適応(§8 で示唆)は実用化されたか。 - マルチパストランスポート(NDP/Homa/UEC)が LLM 訓練の P2P・all-reduce パターンに対してどの程度の実負荷で有効か。シミュレーション(8K ホスト)から百万 GPU 規模への外挿は成立するか。(Source: [[@2024__HotNets__I've Got 99 Problems But FLOPS Ain't One]]) - UCCL-Tran は 6〜16 台規模のテストベッド(Table 1)での実測に留まる。HotNets 2024 が示す 8,192 ホストシミュレーションと同規模、あるいはそれ以上の実機環境でも、UCCL-Tran のソフトウェアマルチパス・EQDS の改善率(FCT P99.9 で最大 4.88×)は維持されるか、それとも QP スワッピング・ホスト CPU 負荷の別のボトルネックが顕在化するか。([[@2026__OSDI__UCCL-Tran - An Extensible Software Transport Layer for GPU Networking]], [[@2024__HotNets__I've Got 99 Problems But FLOPS Ain't One]]) - [[@2025__IMC__Congestion Patterns in a Large-scale RDMA Datacenter]] はPFCの副作用として知られる head-of-line blocking・PFCストームが、スパイン層内の不均一な負荷分散(8リンク中4本が平均1.8Kpause/sec超、別4本が100pause/sec未満)にどこまで寄与しているかを直接検証していない。ECMP/QPスケーリング/フローレットスイッチングを組み合わせた負荷分散の下で、この不均一性はハッシュ衝突由来か、バーストの空間的な集中由来か、どちらが支配的か。 - 同論文はPFC一時停止カウンタとバースト頻度・負荷不均衡の相関を定性的に示すが、ポート単位の分単位カウンタとホスト側4.8msサンプリングを紐付けられないため定量的な因果関係を出せていない(論文自身の限界として明記)。この紐付けができれば、PFC一時停止カウンタから微小バーストの発生源(どのホスト・どの集合通信パターンか)を逆引きできるか。 - NetEdit のホスト側 eBPF CCA(BPF DCTCP 等)は測定レイテンシに反応しない静的ポリシーである。HPCC の INT 閉ループや TIMELY の RTT 勾配と同一ファブリックで共存したとき、ホスト静的設定とスイッチ/RTT 動的制御のどちらが支配的になるか、本 wiki に一次比較は無い。([[@2024__SIGCOMM__NetEdit - An Orchestration Platform for eBPF Network Functions at Scale]]) - Ranyshaの「有害性(harm)」ベースの評価枠組みを、本concept が集約する具体的なアルゴリズム間(例: DCQCNとHPCCの並行デプロイ)に適用した定量評価は本wiki内にまだ無い。「新メカニズムが与える有害性が既存メカニズム同士の有害性の許容範囲内に収まる」という基準を、実際のデータセンター輻輳制御アルゴリズムのどのペアで検証すべきか。 - エッジツークラウド・クラウドツークラウド・イントラクラウドという3分類における「真のピアツーピア転送のフォールバック機構」の具体像は何か。本concept が扱うアルゴリズム群のなかにこの役割を担うものは特定されていない。 - [[@2022__IMC__A Microscopic View of Bursts, Buffer Contention, and Loss in Data Centers]] は「輻輳が高いほど損失が多いとは限らない」理由として、エンドポイント適応・ファブリック輻輳・ASIC多様性・リンク速度という複数の仮説を挙げるが確定的な検証をしていない。本concept が集約するDCTCP/DCQCNのようなエンドツーエンド輻輳制御アルゴリズムの反応特性の違いが、この非自明な関係(RegA-Typical vs RegA-High)にどこまで寄与しているかは、輻輳制御アルゴリズムの内部動作にまで踏み込んだ追試験でなければ切り分けられない。 - 同論文が明らかにした「動的しきい値バッファ共有(DT)のα設定は低輻輳領域ほど結果への影響が大きい」という知見は、DCQCN・DCTCPのようなエンドツーエンド輻輳制御のパラメータチューニング(本concept の未解決の問いにある「AIクラスタ特有のトラフィックパターンに対するDCQCN再チューニング」等)と独立に検討されてきた。バッファ共有アルゴリズムのα調整と輻輳制御アルゴリズムのパラメータ調整を同時最適化した一次研究は本wiki内にまだ無い。 ## 関連 - 概念: [[RDMA]] / [[RDMAネットワーク監視]] / [[オープンネットワーキング]] / [[AIデータセンタートポロジ]] / [[Incast]] / [[Valiant Load Balancing]] / [[インバンドネットワークテレメトリ]] / [[TCP輻輳制御アルゴリズム]] / [[トランスポートプロトコル設計]] / [[マイクロバースト]] / [[バッファブロートとキュー管理]] / [[相互結合網]] - ソース: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Appendix F Interconnection Networks]](§F.7、輻輳管理の古典的3分類) / [[@2026__OSDI__UCCL-Tran - An Extensible Software Transport Layer for GPU Networking]] / [[@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]] / [[@2024__SpeakerDeck__GPUネットワーク設計・運用 基礎勉強会 Lossless Ethernet - PFC-ECN編]] / [[@2025__SpeakerDeck__AIインフラを考える]] / [[@2025__IMC__Congestion Patterns in a Large-scale RDMA Datacenter]] / [[@2018__SIGCOMM__Revisiting Network Support for RDMA]] / [[@2015__SIGCOMM__TIMELY - RTT-based Congestion Control for the Datacenter]] / [[@2019__SIGCOMM__HPCC - High Precision Congestion Control]] / [[@2024__SIGCOMM__NetEdit - An Orchestration Platform for eBPF Network Functions at Scale]] / [[@2017__IMC__High-Resolution Measurement of Data Center Microbursts]] / [[@2022__IMC__A Microscopic View of Bursts, Buffer Contention, and Loss in Data Centers]] / [[@2023__SIGCOMM__Host Congestion Control]] / [[@2024__APNet__Rethinking Intra-host Congestion Control in RDMA Networks]] / [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]] / [[@2025__NSDI__White-Boxing RDMA with Packet-Granular Software Control]] / [[@2026__SIGCOMM__Pegasus - A Data Center Network for Bare-Metal AI Cloud]] - エンティティ: [[Mohammad Alizadeh]] / [[Albert Greenberg]] / [[Microsoft]] / [[Mellanox]] / [[Yibo Zhu]] / [[Chuanxiong Guo]] / [[Jitendra Padhye]] / [[Costin Raiciu]] / [[Soudeh Ghorbani]] / [[Meta]] / [[Google]] / [[Amin Vahdat]] / [[Alibaba Group]] / [[Yuliang Li]] / [[Frank Kelly]] / [[Ehab Ghabashneh]] / [[Sanjay Rao]] / [[Purdue University]] - 関連 MOC: [[分散深層学習 - MOC]] ## 出典 - [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Appendix F Interconnection Networks]] §F.7(輻輳管理の古典的3分類: パケット破棄・リンクレベルフロー制御・チョークパケット) - [[@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]] - [[@2025__SpeakerDeck__AIインフラを考える]]（ECN の3ホップ通知経路とスイッチが直接CNP生成できない制約、IETF Fast CNP draft、Drop Notification によるサイレントドロップ通知） - [[@2025__IMC__Congestion Patterns in a Large-scale RDMA Datacenter]]（Meta本番RDMA AIデータセンターの輻輳測定。PFC導入による輻輳箇所のエッジ→コアシフト、粗粒度PFCカウンタによるバースト検知の知見） - [[@2022__IMC__A Microscopic View of Bursts, Buffer Contention, and Loss in Data Centers]]（Meta+Purdueの共同研究。ホスト計測+ラック内同期(Millisampler/SyncMillisampler)によるバースト・輻輳・損失の統合分析。輻輳が高いほど損失が多いとは限らないという非自明な発見と、動的しきい値バッファ共有アルゴリズムのα公式による定量的裏付け） - [[@2018__SIGCOMM__Revisiting Network Support for RDMA]](IRN。NIC のロス回復方式(SACK vs go-back-N)が PFC 依存度を左右する主要因であることを実証) - [[@2015__SIGCOMM__TIMELY - RTT-based Congestion Control for the Datacenter]]（RTT 勾配のみによる輻輳制御。ECN 不要、DCQCN と同時期発表。99パーセンタイル尾部レイテンシをPFC比9倍・DCTCP比13倍改善） - [[@2019__SIGCOMM__HPCC - High Precision Congestion Control]]（INT による直接測定に基づく高精度輻輳制御。DCQCN比99パーセンタイルFCTスローダウン最大95%削減、incastでPFCポーズをゼロに抑制） - [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 7 TCPの考古学]] §7.2(公平性から有害性への転換、エッジツークラウド/クラウドツークラウド/イントラクラウドの3分類) - [[@2017__IMC__High-Resolution Measurement of Data Center Microbursts]](Facebook本番データセンターの25µs粒度計測。輻輳の90パーセンタイルが200µs以下のµburstであることを実証し、1 RTT未満の低遅延輻輳シグナルの必要性を示唆) - [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]](APNet 2024版の拡張ジャーナル版。DCQCNとの併存下でPFC一時停止最大2.9倍削減・スループット最大1.85倍改善、収束性の理論的解析、hostCCに対する5点の体系的優位性比較を追加)