自律分散協調システム論 第 13 回「 TCP と輻輳制御 /QoS 制御」

1. 自律分散協調システム論第13回「TCPと輻輳制御/QoS制御」自律分散協調システム論第13回「TCPと輻輳制御/QoS制御」 中村　修 osamu@sfc.wide.ad.jp

2. TCPと輻輳制御 • 輻輳制御の重要性 • 輻輳制御の困難さ • TCPによる輻輳制御

3. 玉突き事故 三次災害 二次災害 輻輳発生 輻輳制御の重要性 (1/2) • 輻輳は悪化していく傾向がある

4. 輻輳制御の重要性 (2/2) • ネットワークに自律的な輻輳回復機能がない • ネットワークはできるだけ仕事をしない • エンドノードが輻輳を回避する必要がある • エンドノードは故意に輻輳を起こせる • DoSアタック

5. 輻輳制御技術の大まかな歴史 • 初期のインターネット:輻輳制御技術なし • 1980年初輻輳崩壊の発生が指摘される • 1980年後半エンドノード主体による輻輳制御技術の出現 • 1990年後半中継ノード主体による輻輳制御技術の出現 • 現在広帯域・低遅延要求アプリケーションの台頭インターネット速度記録（TCP高速化技術）

6. パケットを少なく出すのか？ パケットを多く出すのか？ IPネットワーク 輻輳制御の困難さ (1/2) • エンドノードはネットワークの状態が分からない • 自分で推測してネットワークに送出するだけ ネットワークは教えてくれない

7. 輻輳制御の困難さ (2/2) なぜインターネットの状態は分かりにくい？ • IPの特徴 • 様々な通信媒体の性質を抽象化 • 上位プロトコルから通信媒体の性質が見えにくい • 中継システムの簡素化 • ネットワークの許容量が不明 • ネットワークの混雑度が不明

8. アプリケーションとトラフィックパターン • TCP • インタラクティブデータフロー • パケットを直ちに送出 • アプリケーション例：SSH, Telnet などコンソールアプリケーション • バルクデータフロー • フロー制御によってパケットを送出 • アプリケーション例：http, ftp, メールなど • UDP • フロー制御・輻輳制御を行わない • アプリケーション例：ストリーミング, VoIP など それぞれが異なるトラフィックパターンを有する

9. アプリケーショントレンドの推移 ポート番号からサービス特定がしにくい時代 P2P登場 WWW全盛 出典: WIDE報告書(1994-1999) 2000-2005はdaily sampling

10. ソフトウェアファイル ドキュメントファイル 巨大なサーバ：　A サーバAからソフトウェアをダウンロードしよう サーバAからドキュメントをダウンロードしよう インターネット 利用者 クライアント 利用者 クライアント 15年前のアプリケーションモデル • サーバ・クライアントモデル • サービスを提供する側と受ける側に役割を分担 • 情報(データ)は「提供する側」に存在 • 情報(データ)のありか • 情報(データ)が格納されているサーバは「何らかの方法」で探し出す • archie プログラム • サーバ数が多くない上、有名なサーバには様々な種類の情報(データ)が大量に存在 • 情報(データ)の集まり方 • 情報(データ)が一箇所に集まるので、利用者も一箇所に集中してアクセスする

11. アドレスを指定 アドレスを指定 リンク リンク Webサーバ インターネット Webサーバ Webサーバ アドレスを指定 アドレスを指定 Webサーバ 10年～5年前のアプリケーションモデル • サーバ・クライアントモデル • 「置き場所」としてのサーバは変化せず • 能動的なクライアントも変化せず • 情報の分散化 • 情報(データ)は、「リンク」が含むようになり、分散したサーバ間で情報が有機的に結びつけられるようになった • 情報提供者はリンクを意識して情報(データ)を作成 • 情報利用者はリンクを辿り新たな情報(データ)を取得 • 情報(データ)のありか： • 情報(データ)が格納されているサーバは「何らかの方法」で探す • cf. 検索エンジン、ディレクトリサービス • サーバの数が多く、大量の情報(データ)が分散して存在 • 情報(データ)の集まり方 • インターネット中に分散して存在するが、利用者の増加に伴い人気のある情報(データ)を持つサーバにアクセスは集中

12. ファイルA ファイルの断片化(6分割の例) ファイルA 最近のアプリケーションモデル • P2Pモデル • あらかじめ役割を決めない • (サーバ・クライアントの両方の役割を担う) • 対等な関係 • 情報(データ)単位の分散化から、分割した情報(データ)の分散化 • ファイル単位のやり取りから、ファイルの分割を前提とした断片単位のやり取りへ • 情報(データ)のありか • 断片化した情報(データ)はネットワーク上の任意のホストに存在 • 情報理論を応用した検索手法(分散ハッシュ etc…) • P2Pのピアになるホストの数だけ分散する可能性がある • 情報(データ)の集まり方 • 完全な情報(データ)は、それをリクエストした人のところに存在 • ネットワーク上には、断片化されたもの、完全なもの様々な形で存在

13. メディア通信と遅延 • デッドライン • 再生を行うために間に合わせなければならないタイミング • これに遅れると映像や音声が乱れる • バッファ • パケットロスや遅延などでデッドラインオーバーが頻繁に起こらないようにデータを一時的に蓄積

14. TCPによるインターネット最高速度 • Interne2 Land Speed Record • 東京大学、WIDEプロジェクト、JGN2(NICT)、NTTコミュニケーションズなどによる • 2006年12月30日 • 30000km(実際には32372km)のネットワーク • 7.67Gbpsのデータ転送速度 • 230100 terabit-meters per second (Tb-m/s) • 2006年12月31日 • 同一ネットワーク • 9.08Gbpsのデータ転送速度 • 272400 terabit-meters per second (Tb-m/s)

15. TCPにおけるフロー制御

16. もちょっとゆっくり 送って。 キュー(バッファ) フローコントロール ② 送信者 受信者 もちょっとゆっくり 送るか。 ③ ① 早すぎてバッファがあふれる

17. もっとはやく 送って。 キュー(バッファ) フローコントロール ② 送信者 受信者 ③ じゃはやくおくるか ① 遅いから余裕があるな

18. ウィンドウ制御 • ウィンドウ広告　＝　受信バッファ残量 • ウィンドウ更新 • ACKセグメントによる • ACKを待たずに、複数セグメントを転送 • 転送効率の向上

19. 8 1 7 2 6 3 4 5 スライディングウィンドウ 直ちに 転送可能 広告 ウィンドウ

20. 8 1 7 2 6 3 4 5 スライディングウィンドウ 転送されたが 確認応答されていない 広告 ウィンドウ 直ちに 転送可能

21. 転送されて 確認応答済み 8 1 7 2 6 3 4 5 スライディングウィンドウ 転送されたが 確認応答されていない 直ちに 転送可能

22. 8 1 7 2 6 3 4 5 スライディングウィンドウ 転送されて 確認応答済み 転送されたが 確認応答されていない 新たに広告された ウィンドウ 直ちに 転送可能

23. TCPにおける輻輳制御

24. もちょっとゆっくり 送ろう。 輻輳 TCPの輻輳制御機能 ② 送信者 受信者 ① 受信者からしばらく応答がない 輻輳が発生してパケットが届いて なさそうだ

25. なんらかの対処をしなければ 悪化する一方　（輻輳崩壊） 玉突き事故 二次災害 輻輳発生 輻輳制御の重要性 • 輻輳は悪化していく傾向がある

26. TCPの輻輳制御アルゴリズム • 非常に多くのアルゴリズムが存在 • 代表的な例 • TCP Tahoe • スロースタートアルゴリズム，輻輳回避アルゴリズム，高速再転送アルゴリズム • TCP Reno (TCP NewReno) • 高速再転送アルゴリズム • TCP Vegas • RTTをベースとしたウィンドウサイズの調整 • OSによって実装されているアルゴリズムがことなることも

27. TCPの輻輳制御アルゴリズム（時代別） • 1988年頃 • Tahoe • スロースタート、輻輳回避アルゴリズムの採用 • 高速再転送アルゴリズムの採用 • 1990年頃 • Reno • 高速リカバリ・アルゴリズムの採用 • 1996年頃 • NewReno • 高速リカバリ・アルゴリズムの修正

28. Linux Kernel の持つアルゴリズム(Kernel 2.6.18の例, /usr/src/linux/net/ipv4/tcp_*.c) • Binary Increase Congestion control for TCP (BICTCP) • Lison-Xu, Kahaled Harfoush, and Injong Rhee. • TCP Reno / TCP NewReno • BSD系OSのデフォルト • Binary Increase Congestion control for TCP v2.0 (TCP CUBIC) • Injong Rhee, Lisong Xu. • High Speed TCP • Sally Floyd. • H-TCP • R.N.Shorten, D.J.Leith.

29. TCPの続き • TCP HYBLA • C.Caini, R.Firrincieli. • TCP Low Priority (TCP-LP) • Scalable TCP • Tom Kelly • TCP Vegas • Lawrence S. Brakmo and Larry L. Peterson. • TCP Veno • C. P. Fu, S. C. Liew. • TCP Westwood+: end-to-end bandwidth estimation for TCP • Angelo Dell'Aera.

30. TCPの輻輳制御アルゴリズム (1/2) • ネットワークの状態推測機構 • ネットワークの情報は直接手に入らない • エンド間の通信から得られる情報で推察 • 単純なアルゴリズム • パケットが落ちない • 転送量を上げる • パケットが落ちた • 転送量を落とす

31. TCPの輻輳制御アルゴリズム (2/2) • ウィンドウサイズを増減させ転送制御 • 送信者の輻輳ウィンドウ • 受信者のウィンドウサイズ広告 • 2段階の通信状態 • スロースタート • 輻輳回避

32. スロー・スタート • スロー・スタート • エンドノード間の回線状態はわからない • 回線の許容量以下に送信量を制御する必要がある • ネットワークへの突発的なトラフィック流入を防止可能 • 輻輳ウインドウ（cwnd） • 送信者が送信可能なセグメント数を決定 • 送信者が管理するウィンドウ • （注）受信者の管理するウィンドウとは別

33. スロー・スタートの仕組み • スロー・スタートのアルゴリズム • 通信開始時 • 輻輳ウィンドウサイズを1で初期化 • Ack受信時 • 輻輳ウィンドウをAck受信毎に増加 • 輻輳ウィンドウは幾何級数的に増加

34. スロー・スタートの概要 初期windowサイズは1で送信 １に対してAckを返す 送信者 受信者 windowサイズを2で送信 2に対してAckを2つ返す windowサイズを4で送信 1,2,4,8,,,,と幾何級数的にウィンドウサイズを大きくする

35. 輻輳回避状態 • スロースタートを開始し、輻輳ウィンドウが増加 • 送信者は、パケットロスを検知しスロースタートを停止 • 輻輳が発生したときの輻輳ウィンドウを記憶 • 輻輳ウィンドウを１に戻しスロースタートを再初期化 • 輻輳回避状態へ移行 • 記憶した輻輳ウィンドウまでは通常のスロースタート • 記憶した輻輳ウィンドウに達すると • Ack受信ごとに輻輳ウィンドウを上げていかない • 輻輳ウィンドウ分のAckを受信して輻輳ウィンドウを開く

36. TCP Tahoe におけるウィンドウサイズの変化 スロースタート 輻輳回避 ネットワーク の限界 最適な ウィンドウサイズ スロースタート 閾値 t

37. TCP Reno におけるウィンドウサイズの変化 スロースタート 輻輳回避 ネットワーク の限界 最適な ウィンドウサイズ スロースタート 閾値 t

38. 往復時間の測定 • RTTから分かること • 輻輳の度合い • パケットロスの指標 • RTTは非線形に変化 • 外れ値の可能性 • 平滑化することでRTTを評価（RTT評価値） • RはRTT評価値 • Mは新しい測定値 • αは平滑化係数（推奨値は0.9） R = αR+(1-α)M

39. 再転送タイムアウト値の算出 • 再転送タイムアウト値（RTT） • βは遅延分散係数（推奨値は2） • 再転送タイムアウトするごとに増加 • 指数バックオフ • 最大値64秒 RTO = Rβ (RFC793推奨式)

40. 高速再転送アルゴリズム • 受信者のTCPが順番の違うセグメントを受信 • 確認応答（重複ACK）を生成する必要 • 単に順番が入れ替わった … (a) • 受信者はセグメントを並び替えて上位層に渡す • パケットロスが発生した … (b) • 送信者は該当するセグメントを再送する必要 • 高速再転送アルゴリズム • (a)、(b)をいち早く調べる方法 • 以下の場合、パケット損失の可能性高と判断 • 重複ACKを３つ受信した場合 • 再送タイマを待たずに直ちに再送する

41. インターネット 発信元 宛て先 高速再転送アルゴリズム • 再送タイムアウトを待たずに再送 • 迅速な再送による転送効率の向上 2番のパケットが 届いていない！ ５ Packet loss ５ ４ 2番パケットを転送 3 ４ 2 3 1 1 3が届いた時点で1番へのACK 1番へのACKが 3が届いた時、4が届いた時、5が通ったとき の合計3回届く

42. ボトルネック ボトルネック パケットギャップ セルフクロッキング (1/3) • 経路の一番細い部分がボトルネックとなり、パケットギャップが発生する 送信者 受信者 ルータ ルータ 帯域が広い 帯域が狭い 帯域が広い

43. セルフクロッキング (2/3) • 受信者はパケットギャップの間隔でAckを返してくる 送信者 受信者 ルータ ルータ 帯域が広い 帯域が狭い 帯域が広い

44. セルフクロッキング (3/3) • Ackの受信間隔に合わせてパケットを送出する • 通信のバースト性が抑えられる 送信者 受信者 ルータ ルータ 帯域が広い 帯域が狭い 帯域が広い

45. まとめ：TCPにおける輻輳制御 • ネットワークの状態を動的に推測 • 輻輳が発生すれば転送速度を落とす • 輻輳が起きないギリギリまで転送速度を上げる • できるだけ早く最適なウィンドウサイズに到達する • ウィンドウサイズが安定すると通信も安定する

46. エンドノードによる輻輳制御の限界 • エンドノードだけでは、ネットワークの状態を完全に把握することは不可能 • ネットワーク全体の安定が各エンドノードの自律的な動作に掛かっている • 悪意のあるユーザの攻撃や、無知なユーザの無秩序な利用に対して脆弱 • 中間ノードでも制御を行う必要性 • QoS技術

47. ネットワークによる輻輳制御- QoS機構 -

48. QoSとは？ • Quality of Service • 利用するサービスに対して品質を考慮 • 特にインターネットでは、通信品質 • スループット • レスポンスタイム • 到着揺らぎ幅（ジッタ） • 自律分散協調型のインターネットでは困難

49. エンドノードとネットワーク エンドノードでの制御 • ネットワークの状態は分からない • 重い処理もできる • ネットワーク全体に影響を及ぼせない ネットワークでの制御 • ネットワークの状態を把握できる • 処理が集中しやすい • 重い処理は避けたい • ネットワーク全体へ設定が反映される

50. QoSの必要性 • 全ての通信をスムーズには行えない • サービスの平滑化・差別化 • 料金格差 • リアルタイムアプリケーションの優先 • 放送（音楽・動画） • 対戦型ゲーム • IP電話 • 緊急の電話・緊急でない電話