@2010__SIGCOMM__Data Center TCP (DCTCP)

# Data Center TCP (DCTCP) Navigation: [[データセンター輻輳制御]] | [[Incast]] | [[Mohammad Alizadeh]] > [!abstract] > クラウドデータセンターは、小さな予測可能なレイテンシを要求するワークロードと、大きな持続スループットを要求するワークロードを混在させて運用する。この環境では、現在最善とされる TCP プロトコルは不十分である。本論文は 6000 台サーバーの本番クラスタの計測結果を示し、データセンタースイッチの限られたバッファ空間に対する TCP の需要が根本原因となってアプリケーションのレイテンシが高くなる障害を明らかにする。例えば、帯域幅を大量消費するバックグラウンドフローがスイッチにキューを積み上げ、レイテンシ敏感なフォアグラウンドトラフィックに影響を与える。これらの問題に対処するため、データセンターネットワーク向けの TCP 類似プロトコル DCTCP を提案する。DCTCP はネットワーク中の ECN(Explicit Congestion Notification)を活用してエンドホストへマルチビットフィードバックを提供する。DCTCP を 1 Gbps および 10 Gbps 速度でコモディティの浅バッファスイッチを用いて評価した。DCTCP は TCP と同等以上のスループットを達成しながら、90% 少ないバッファ空間を使用することがわかった。TCP と異なり DCTCP は短フローに対して高いバースト耐性と低レイテンシも提供する。本番計測から導出したワークロードの処理において、DCTCP によりアプリケーションは現在のバックグラウンドトラフィックの 10 倍を、フォアグラウンドトラフィックへの影響なしに処理できることがわかった。さらに、フォアグラウンドトラフィックの 10 倍増加でもタイムアウトは一切発生せず、Incast 問題をほぼ解消できる。 ## 論文情報 | 項目 | 内容 | |---|---| | 著者 | [[Mohammad Alizadeh]](Stanford), [[Albert Greenberg]](Microsoft Research), [[David Maltz]](Microsoft Research), [[Jitendra Padhye]](Microsoft Research), Parveen Patel, [[Balaji Prabhakar]](Stanford), Sudipta Sengupta, Murari Sridharan | | 発表 | SIGCOMM 2010, New Delhi, India | | 発表日 | 2010-08-30 | | 分野 | ネットワーキング / データセンター / 輻輳制御 | | 実装規模 | TCP コード変更 30 行、スイッチパラメータ 1 個 | ## 概要データセンターの TCP 通信には、コモディティスイッチの浅いバッファに起因する 3 つの性能障害が存在する。DCTCP はこれを ECN のマーキング割合をマルチビット輻輳情報として活用することで解決する。スイッチ側は CE マーキング閾値 K を設定するだけでよく、既存ハードウェアで実現可能である。 ## 問題設定 ### データセンターのトラフィック構造 Partition/Aggregate パターンが多くの大規模ウェブアプリケーションの基盤となっている。クエリは上位レイヤから多数のワーカーへ分散され、レスポンスが集約されて結果となる。各ワーカーに 10〜100 ms のタイトな締め切りが設定され、ミスするとその応答は最終結果から除外される。本番計測(6000 台超のサーバー、150 TB 超の圧縮データ、1 ヶ月間)では以下の 3 種類のトラフィックが混在していた: - **クエリトラフィック**: 2 KB〜20 KB の短フロー、レイテンシ重視 - **短メッセージトラフィック**: 100 KB〜1 MB、遅延敏感 - **バックグラウンドトラフィック**: 1 MB〜100 MB の長フロー、スループット重視 ### 3 つの性能障害図2: Partition/Aggregate パターン(レイヤ間のデッドライン連鎖を示す) **障害 1 — Incast(多対一輻輳)**: Partition/Aggregate によりワーカーの応答が同期してアグリゲータ向けポートに殺到する。1 パケットの損失で TCP タイムアウト(RTO_min = 300 ms)が発生し、締め切りをほぼ確実に超過する。 **障害 2 — キュー蓄積(Queue Buildup)**: 長フローが共有キューでパケットを滞留させ、同一キューを通る短フローのレイテンシを増大させる。図9の CDF では、アグリゲータへの RTT の 10% が 1〜14 ms のキュー遅延を受けている。パケット損失がなくてもレイテンシが増大するため、RTO_min の削減では解決しない。 ![[wiki/sources/_attachments/dctcp-sigcomm10/fig09-cdf-rtt-aggregator.png]] *図9: アグリゲータへの RTT の CDF。10% の応答が 1〜14 ms のキュー遅延を受ける(長フローによる障害 2)* **障害 3 — バッファ圧迫(Buffer Pressure)**: 共有メモリスイッチでは、あるポートの長フローがバッファを食い潰すと、他ポートの短フローのバーストを吸収するヘッドルームが失われる。Incast と異なり同期フローを必要としない。図8: 本番アプリケーションのレイテンシ百分位点のスクリーンショット(ジッタリングの on/off 前後) ![[wiki/sources/_attachments/dctcp-sigcomm10/fig08-response-time-percentiles-jitter.png]] *図8: ジッタリングを 8:30 にオフにした際の応答時間百分位点の推移。50 パーセンタイルは 10 倍改善するが、99.9 パーセンタイルは悪化する* ## 提案手法 ### DCTCP アルゴリズムの 3 要素 **要素 1 — スイッチでの単純なマーキング**: 閾値 K を設定するだけ。パケット到着時にキュー占有数が K を超えていれば CE コードポイントをマークし、超えていなければマークしない。既存スイッチの RED 機能を `min_th = max_th = K`、瞬間キュー長に基づくマーキングで流用できる。 **要素 2 — 受信者での ECN-Echo**: RFC 3168 の標準 ECN は確認応答まで ECN-Echo フラグを連続送出するが、DCTCP 受信者は CE マーキングの正確なシーケンスを送信者に伝える。図10の 2 状態 ACK 生成ステートマシンで実現し、遅延 ACK(m パケットごとに 1 ACK)との組み合わせも可能。 **要素 3 — 送信者でのコントローラ**: 送信者はマーク割合の推定値 α を保持し、データウィンドウ 1 枚ごと(約 1 RTT)に EWMA(指数移動平均)で更新する: ``` α ← (1 − g) × α + g × F ``` ここで F は直前ウィンドウでマークされたパケットの割合、g は新サンプルへの重み(推奨: 1/16)。α ≈ 0 は輻輳低、α ≈ 1 は輻輳高を示す。 TCP との唯一の違いは、マーク付き ACK 受信時のウィンドウ調整則: ``` cwnd ← cwnd × (1 − α/2) ``` TCP が常に半減(`α = 1` 相当)するのに対し、DCTCP は輻輳度に比例して段階的に削減する。α が小さければウィンドウ削減も小さく、キュー長を低く保ちながら高スループットを維持できる。 ![[wiki/sources/_attachments/dctcp-sigcomm10/fig01-queue-length-tcp-vs-dctcp.png]] *図1: TCP vs DCTCP のキュー長時系列。TCP は 300〜600 KB で大きく振動するのに対し、DCTCP は 20〜30 KB 付近に安定して収束する* ### パラメータ設計指針 **マーキング閾値 K**: キューがアンダーフローしないための下限は `K > (C × RTT) / 7`。ただし実装の突発性(LSO・割り込み軽減による 30〜40 パケットバースト)を考慮し、1 Gbps では K = 20 パケット、10 Gbps では K = 65 パケットを採用。 **推定ゲイン g**: 輻輳イベントを少なくとも 1 回以上スパンするよう `(1 − g)^TC > 1/2` から決定。推奨値 g = 1/16。 ### 解析 N フロー同期の定常解析により、DCTCP のキュー振動幅は `O(√(C × RTT))` であり、TCP の `O(C × RTT)` と比較して大幅に小さい。これにより非常に小さい K(帯域遅延積の 1/7 以下)でもスループット損失なくマーキングできる。 ## 新規性 DCTCP の核心的貢献は ECN の 1 ビット系列からマルチビット輻輳情報を抽出することにある。個々の制御則自体ではなく、この情報抽出の考え方が新しい: | 比較項目 | 標準 TCP(ECN あり) | DCTCP | |---|---|---| | 輻輳検知 | 存在のバイナリ情報のみ | マーク割合 α によるマルチビット情報 | | ウィンドウ削減 | 常に半減 | α/2 に比例した段階的削減 | | キュー長目標 | 制御なし(ドロップまで増加) | 閾値 K 付近に安定化 | | スイッチ要件 | 既存 ECN | 既存 ECN のみ(RED 流用可) | | NIC 要件 | なし | なし(QCN と異なりハードウェアレートリミッタ不要) | RED/PI などの AQM スキームは TCP の 2 分の 1 削減という保守的な反応を変えないため、統計的多重化が少ないデータセンター環境ではスループット対遅延のトレードオフから抜け出せない。DCTCP はこのトレードオフを根本的に解消する。 ## 実験設定 - テストベッド: 94 台(80 台が 1 Gbps NIC、14 台が 10 Gbps NIC) - スイッチ: Broadcom Triumph(48× 1 Gbps + 4× 10 Gbps、4 MB バッファ、ECN 対応)、Broadcom Scorpion(24× 10 Gbps、ECN 対応)、Cisco CAT4948(16 MB 深バッファ、ECN 非対応) - 比較対象: TCP New Reno(w/ SACK)、TCP-RED - 計測: キュー長の瞬間値サンプリング(125 ms 間隔) ## 実験結果 ### 基本性能 1 Gbps では DCTCP と TCP の両方が 0.95 Gbps の最大スループットを達成。キュー長は DCTCP が K+N パケット(約 20〜30 パケット)付近に安定するのに対し、TCP は 10 倍大きく大きく変動する。 10 Gbps での公平性テスト(最大 90 フロー): DCTCP は Jain 公平性指数 0.99 を達成。フロー収束時間は 1 Gbps で 20〜30 ms、10 Gbps で 80〜150 ms(TCP 比 2〜3 倍)。 ### Incast マイクロベンチマーク静的バッファ(100 パケット/ポート)で 41 台の同時 1 MB 要求を実験。DCTCP は 35 台以下でタイムアウトゼロ。TCP は 10 台超でタイムアウトが発生し始め、35 台超では壊滅的な性能低下。動的バッファを有効にすると DCTCP は 40 台でもタイムアウトゼロを維持。全対全 Incast(40 台が同時に他の 40 台各々に 25 KB を要求): DCTCP はタイムアウトゼロ。TCP は 55% 超のクエリが少なくとも 1 回のタイムアウトを経験。 ### キュー蓄積マイクロベンチマーク 2 本の大フローが共存する中での 20 KB 短フロー 1000 回転送: DCTCP の中央値遅延 < 1 ms に対し TCP の中央値遅延 19 ms。 ### バッファ圧迫マイクロベンチマーク 10 対 1 Incast + 66 本のバックグラウンド長フローの組み合わせ: TCP のクエリ完了時間 95 パーセンタイルがバックグラウンド有りで 9.87 ms → 46.94 ms に悪化。DCTCP は 9.17 ms → 9.09 ms とほぼ不変。 ### 本番ベンチマーク Partition/Aggregate 構造で 45 台・1 Gbps・3 種混在トラフィック(10 分間、200,000 超のバックグラウンドフロー・188,000 超のクエリ)の計測: - クエリ完了時間: DCTCP が TCP より低く、特に裾が改善。TCP は 1.15% がタイムアウトを経験、DCTCP はゼロ - 短メッセージ: 平均 3 ms・95 パーセンタイル 9 ms の短縮 **スケールトラフィック**(バックグラウンド・クエリともに 10 倍増): DCTCP の短メッセージ 95 パーセンタイルは 29 ms、クエリは 24 ms。TCP はそれぞれ 86 ms・145 ms。TCP はクエリの 92% 超がタイムアウトを経験。DCTCP は 0.3%。 ![[wiki/sources/_attachments/dctcp-sigcomm10/fig15-queue-length-dctcp-vs-red-10gbps.png]] *図15: 10 Gbps での DCTCP vs TCP-RED のキュー長時系列。TCP-RED は広い振動(最大 250 KB)を示し、DCTCP は 50〜100 KB の範囲で安定している* 深バッファスイッチ(CAT4948)との比較: Incast は改善するが短メッセージ完了時間が 80 ms 超に悪化。TCP-RED との比較: 短フローは改善するが、クエリの 95% がタイムアウトを経験(キュー長変動が大きいため)。 ## 考察 ### 長所と適用範囲 - TCP コード変更 30 行、スイッチパラメータ 1 個のみ。既存ハードウェアで実現可能 - データセンター内の均質なネットワーク・単一管理ドメインの前提が成立する場合に有効 - スロースタートや additive increase、パケット損失からの回復は TCP と同一。DCTCP は ECN 反応のみを変える ### 限界と課題 - **広域ネットワークへの適用不可**: RTT が 250 µs 程度のデータセンター向けに設計。WAN への適用は想定外 - **TCP との公平性の未保証**: DCTCP フローと TCP フローを同一ネットワークに混在させる場合は、Ethernet プライオリティ(CoS)による分離が必要 - **大規模 Incast の限界**: ワーカー数が非常に多く、初回 RTT の 1 パケットだけで静的バッファを超過する場合はタイムアウトを回避できない - **収束時間**: TCP より 2〜3 倍遅い。ただしデータセンターの RTT は数百 µs であり絶対時間は小さい - **10 Gbps での実装課題**: LSO 等によるバースト(30〜40 パケット)への対応が必要 ## 強み / 弱点・課題 **強み**: - 既存の ECN 対応ハードウェアだけで実現可能な最小限の変更で大幅な性能改善 - 3 つの障害(Incast・キュー蓄積・バッファ圧迫)を単一のメカニズムで同時解決 - 定常解析により設計パラメータの理論的根拠を提示 **弱点・課題**: - RDMA / RoCEv2 には直接対応しない(後続の DCQCN が対応) - スロースタートを持つため突発型ストレージワークロードでの性能は制限される - TCP との共存には CoS によるトラフィック分離が前提 ## 関連概念 - [[データセンター輻輳制御]] — DCQCN・QCN との横断比較 - [[Incast]] — 多対一通信パターンの輻輳問題 - [[Microsoft Research]] — 著者の主要所属 - [[Albert Greenberg]] — 共著者、VL2 等でも活躍 ## 出典 - [[@2010__SIGCOMM__Data Center TCP (DCTCP)]]