Download - Data Center TCP (DCTCP)
1
Data Center TCP(DCTCP)
Mohammad Alizadeh, Albert Greenberg, David Maltz, Jitu Padhye, Parveen Patel,
Balaji Prabhakar, Sudipta Sengupta , Murari Sridha
Microsoft Research and Stanford UniversitySIGCOMM 2010
発表者浅見・川原研究室 M1 加藤拓也 twitter ID @kato_t1988
目次
• 背景, 目的• データセンターの通信• 関連研究• DCTCP アルゴリズム• 実験, 評価• まとめ
2
目次
• 背景, 目的• データセンターの通信• 関連研究• DCTCP アルゴリズム• 実験, 評価• まとめ
3
背景
4
・データセンターの計算資源の大規模化・クラウド化の促進
しかし,
- Incast 問題- Queue Buildup- Buffer Pressure
TCP はデータセンター内の通信には不十分
本研究について
5
・データセンタートラヒックの計測・分析 ・データセンター内の通信を改善する Data Center TCP(DCTCP) の提案
目的既存ハードウェアを使用して
データセンターにおけるネットワーク性能を改善する
コントリビューション
目次
• 背景, 目的• データセンターの通信• 関連研究• DCTCP アルゴリズム• 実験, 評価• まとめ
6
・クエリトラヒック・小さいフロー・大きいフロー
( 2KB 〜 20KB )( 100KB 〜1MB )( 1MB 〜100MB )
トラヒック
データセンター
7
ソフトリアルタイム処理 ウェブ検索,商品販売,広告,商品推薦,…… →Partition/Aggregate システム
アプリケーション Aggregator
Worker Worker……
Partition/Aggregate システム
request
Delay SensitiveDelay SensitiveThroughput Sensitive
3 つの性能障害要因
8
switch
Output QueueIncast
Queue Buildup
Buffer Pressure
キュー長を短く,スループットを高く保つことが重要
= large flow = small flow
目次
• 背景, 目的• データセンターの通信• 関連研究• DCTCP アルゴリズム• 実験, 評価• まとめ
9
関連研究
10
・ジッタを加える → 平均して遅延・再送タイムアウト (RTO) を小さくする → Queue Buildup には無効
Incast 対策
Incast ジッタ
関連研究
11
・ RTT からキュー長を推定 → ノイズが大きい・明示的フィードバック → 特別なハードウェアスイッチが必要・ Active Queue Management(AQM) → 後に比較 (RED)
Queue Buildup 対策
Drop or CE mark
Random Early Detection (RED)
Queue
目次
• 背景, 目的• データセンターの通信• 関連研究• DCTCP アルゴリズム• 実験, 評価• まとめ
12
α ← (1 - g) × α + g × F
F: ECE 印付パケット率g: 重み付け係数α: 輻輳推量
DCTCP アルゴリズム
13
Sender Receiver
Switch
閾値 K
パケットCongestion Experienced(CE) bitExplict Congestion Notification
(ECN) Echo
cwnd ← cwnd × (1 – α/2)
cwnd: ウィンドウサイズ
DCTCP の幸せ
14
閾値 K
通常の TCP DCTCP
feedbackfeedback
set not to make queue < 0
目次
• 背景, 目的• データセンターの通信• 関連研究• DCTCP アルゴリズム• 実験, 評価• まとめ
15
実験環境
ポート バッファ ECN
Triumph 48 1Gbps, 4 10Gbps 4MB YScorpion 24 10Gbps 4MB YCAT4948 48 1Gbps, 2 10Gbps 16MB N
16
基本的に動的バッファ割り当てを有効
閾値 K=
重み付け g = 1/16
20 (1Gbps ポート ) 65 (10Gbps ポート )
パラメータ
使用するスイッチ
マシン1Gbps NIC または 10Gbps NIC
TCP
New Reno with SACK
評価 – Queue Buildup-
17転送時間累積分布関数
実験方法 SenderSender Triumph SW ReceiverSender・ 2 つの大きいフロー + 20KB データ送信 *1000 回
1Gbps1Gbps
評価 – Benchmark-
18クエリの完了時間
実験方法 Server Triumph SW ServerServer・ Partition/Aggregate クエリ + BG トラヒック for 10min
10Gbps1Gbps
45台
バックグラウンドトラヒックの完了時間
( 95 パーセンタイル)
評価 – Benchmark 10X scaled-
19
実験方法 Server Triumph SW ServerServer・ Partition/Aggregate クエリ + BG トラヒック *10 for 10min
10Gbps1Gbps
45台
完了時間( 95 パーセンタイル)
目次
• 背景, 目的• データセンターの通信• 関連研究• DCTCP アルゴリズム• 実験, 評価• まとめ
20
・ ECN を僅かに改良しただけで抜群の性能向上
まとめ
21
・データセンタートラヒックの計測・分析・データセンター内の通信を改善する Data Center TCP(DCTCP) の提案
コントリビューション
感想
Appendix
22
評価 –スループットとキュー長 -
23キュー長累積分布関数 K に対するスループット (10Gbps)
実験方法Sender Triumph SW ReceiverSender
1Gbps1Gbps
・できる限り速くデータを送信し続ける・ DCTCP vs. TCP
評価 –スループットとキュー長 -
24キュー長累積分布関数
実験方法Sender Triumph SW ReceiverSender
1Gbps1Gbps
・できる限り速くデータを送信し続ける・ DCTCP vs. TCP with RED→DCTCP はキュー長を小さく保ちつつ最大のスループットを実現
時間に対するキュー長
結論
評価 – Incast 問題 -
25キュー遅延 クエリのタイムアウト率
実験方法 Server Triumph SW ClientServer・クライアントは 1/nMB のデータを要求 *1000 回・ DCTCP vs. TCP→DCTCP は TCP よりも Incast をタイムアウトなしに処理可能
1Gbps1Gbps
n 台
結論
評価 – Queue Buildup-
26転送時間累積分布関数
実験方法 SenderSender Triumph SW ReceiverSender・ Sender2 つは常に大きいフローを流す・残りの Sender は 20KB データ送信 *1000 回・ DCTCP vs. TCP→DCTCP はキュー長を短くしクエリの遅延を小さくする
1Gbps1Gbps
結論
評価 – Buffer Pressure-
27
・ 11 台で 10-1 の Incast ( 100KB*10 のデータ要求)・ 33 台はそれぞれ他の 2 台に常にデータ送信 (合計 66 フロー):バックグラウンドトラヒック
実験方法
Host Triumph SWHost
1Gbps
結果
44台
結論
・クエリのタイムアウト率は TCP で 7%, DCTCP では 0.08%・バックグラウンドトラヒックのスループットは同等
Without background traffic With background traffic
TCP 9.87ms 46.94ms
DCTCP 9.17ms 9.09ms
95 パーセンタイルのクエリ完了時間
DCTCP はフロー間の性能依存を解消する
評価 – Benchmark-
28クエリの完了時間
実験方法 Server Triumph SW ServerServer・ Partition/Aggregate クエリ + BG トラヒック for 10min・ DCTCP vs. TCP→DCTCP は TCP よりも効率よく現実的フローを処理可能
10Gbps1Gbps
45台
結論
バックグラウンドトラヒックの完了時間
( 95 パーセンタイル)
評価 – Benchmark 10X scaled-
29
実験方法 Server Triumph SW ServerServer・ Partition/Aggregate クエリ + BG トラヒック *10 for 10min
→DCTCP は 10 倍の BG トラヒックも処理可能
10Gbps1Gbps
45台
結論
完了時間( 95 パーセンタイル)