TCP と輻輳制御輻輳制御の重要性

輻輳制御の困難さ

TCP による輻輳制御

輻輳制御の重要性 (1/2)

輻輳は悪化していく傾向がある

輻輳発生二次災害三次災害玉突き事故

輻輳制御の重要性 (2/2)ネットワークに自律的な輻輳回復機能がない

ネットワークはできるだけ仕事をしない

エンドノードが輻輳を回避する必要がある

エンドノードは故意に輻輳を起こせる DoS アタック

輻輳制御技術の大まかな歴史初期のインターネット : 輻輳制御技術なし

1980 年初輻輳崩壊の発生が指摘される

1980 年後半エンドノード主体による輻輳制御技術の出現

1990 年後半中継ノード主体による輻輳制御技術の出現

現在広帯域・低遅延要求アプリケーションの台頭インターネット速度記録（ TCP 高速化技術）

輻輳制御の困難さ (1/2)エンドノードはネットワークの状態が分からない

自分で推測してネットワークに送出するだけ

IPネットワーク

パケットを多く出すのか？パケットを少なく出すのか？ネットワークは教えてくれない

輻輳制御の困難さ (2/2)なぜインターネットの状態は分かりにくい？

IP の特徴 様々な通信媒体の性質を抽象化

上位プロトコルから通信媒体の性質が見えにくい 中継システムの簡素化

ネットワークの許容量が不明

ネットワークの混雑度が不明

アプリケーションとトラフィックパターン

TCP インタラクティブデータフロー

パケットを直ちに送出 アプリケーション例： SSH, Telnet などコンソールアプリケー

ション バルクデータフロー

フロー制御によってパケットを送出 アプリケーション例： http, ftp, メール など

UDP フロー制御・輻輳制御を行わない

アプリケーション例：ストリーミング , VoIP など

それぞれが異なるトラフィックパターンを有する

アプリケーショントレンドの推移トラフィックの推移

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005年

(%)

デー

タ量

OthersNapsterSMTPHTTP/HTTPSFTP

P2P 登場

ポート番号からサービス特定がしにくい時代

出典 : WIDE 報告書 (1994-1999)2000-2005 は daily sampling

WWW 全盛

15 年前のアプリケーションモデル

サーバ・クライアントモデル サービスを提供する側と受ける側に役割を分担 情報 ( データ ) は「提供する側」に存在

情報 ( データ ) のありか 情報 ( データ ) が格納されているサーバは「何らかの方法」で探し出す

archie プログラム サーバ数が多くない上、有名なサーバには様々な種類の情報 ( データ ) が大

量に存在

情報 ( データ ) の集まり方 情報 ( データ ) が一箇所に集まるので、利用者も一箇所に集中してアクセス

する

利用者

巨大なサーバ：　 A

インターネットインターネット

クライアント クライアント 利用者

ドキュメントファイルサーバ Aから

ソフトウェアをダウンロードしよ

う

サーバ Aからドキュメントを

ダウンロードしよう

ソフトウェアファイル

10 年～ 5 年前のアプリケーションモデル

サーバ・クライアントモデル 「置き場所」としてのサーバは変化せず 能動的なクライアントも変化せず

情報の分散化 情報 ( データ ) は、「リンク」が含むようになり、分散したサーバ間で情報が有機的に結びつけられるようになった 情報提供者はリンクを意識して情報 ( データ ) を作成 情報利用者はリンクを辿り新たな情報 ( データ ) を取得

情報 ( データ ) のありか： 情報 ( データ ) が格納されているサーバは「何らかの方法」で探す

cf. 検索エンジン、ディレクトリサービス サーバの数が多く、大量の情報 ( データ ) が分散して存在

情報 ( データ ) の集まり方 インターネット中に分散して存在するが、利用者の増加に伴い人気のある情報 ( デー

タ ) を持つサーバにアクセスは集中インターネットインターネット

Webサーバ

Webサーバ

Webサーバ

Webサーバ

リンクリンク

アドレスを指定

アドレスを指定 アドレスを指定

アドレスを指定

最近のアプリケーションモデル P2P モデル

あらかじめ役割を決めない ( サーバ・クライアントの両方の役割を担う ) 対等な関係

情報 ( データ ) 単位の分散化から、分割した情報 ( データ ) の分散化 ファイル単位のやり取りから、ファイルの分割を前提とした断片単位のやり取りへ

情報 ( データ ) のありか 断片化した情報 ( データ ) はネットワーク上の任意のホストに存在 情報理論を応用した検索手法 ( 分散ハッシュ etc…) P2P のピアになるホストの数だけ分散する可能性がある

情報 ( データ ) の集まり方 完全な情報 ( データ ) は、それをリクエストした人のところに存在 ネットワーク上には、断片化されたもの、完全なもの様々な形で存在

ファイル A

ファイルの断片化 (6分割の例 )

ファイル A

メディア通信と遅延デッドライン

再生を行うために間に合わせなければならないタイミング

これに遅れると映像や音声が乱れる

バッファ パケットロスや遅延な

どでデッドラインオーバーが頻繁に起こらないようにデータを一時的に蓄積

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)

フローコントロールもちょっとゆっくり

送って。

キュー ( バッファ )もちょっとゆっくり

送るか。

早すぎてバッファがあふれる

①

②

③

送信者 受信者

フローコントロールもっとはやく

送って。

キュー ( バッファ )じゃはやくおくるか

①

②

③

送信者 受信者

遅いから余裕があるな

ウィンドウ制御ウィンドウ広告　＝　受信バッファ残量

ウィンドウ更新 ACK セグメントによる

ACK を待たずに、複数セグメントを転送転送効率の向上

スライディングウィンドウ

1

2

3

45

6

7

8

広告ウィンドウ

直ちに転送可能

スライディングウィンドウ

1

2

3

45

6

7

8

広告ウィンドウ

転送されたが確認応答されていない

直ちに転送可能

スライディングウィンドウ

1

2

3

45

6

7

8

転送されたが確認応答されていない

転送されて確認応答済み

直ちに転送可能

スライディングウィンドウ

1

2

3

45

6

7

8

転送されたが確認応答されていない

転送されて確認応答済み

直ちに転送可能

新たに広告されたウィンドウ

TCP の輻輳制御機能

輻輳

もちょっとゆっくり送ろう。

受信者からしばらく応答がない輻輳が発生してパケットが届い

てなさそうだ

①

②

送信者 受信者

輻輳制御の重要性輻輳は悪化していく傾向がある

輻輳発生

二次災害

玉突き事故なんらかの対処をしなければ悪化する一方　（輻輳崩壊）

TCP の輻輳制御アルゴリズム

非常に多くのアルゴリズムが存在

代表的な例 TCP Tahoe

スロースタートアルゴリズム，輻輳回避アルゴリズム，高速再転送アルゴリズム

TCP Reno (TCP NewReno) 高速再転送アルゴリズム

TCP Vegas RTT をベースとしたウィンドウサイズの調整

OS によって実装されているアルゴリズムがことなることも

TCP の輻輳制御アルゴリズム（時代別）

1988 年頃 Tahoe

スロースタート、輻輳回避アルゴリズムの採用高速再転送アルゴリズムの採用

1990 年頃 Reno

高速リカバリ・アルゴリズムの採用

1996 年頃 NewReno

高速リカバリ・アルゴリズムの修正

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.

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.

TCP の輻輳制御アルゴリズム (1/2)

ネットワークの状態推測機構 ネットワークの情報は直接手に入らない エンド間の通信から得られる情報で推察

単純なアルゴリズム パケットが落ちない

転送量を上げる パケットが落ちた

転送量を落とす

TCP の輻輳制御アルゴリズム (2/2)

ウィンドウサイズを増減させ転送制御 送信者の輻輳ウィンドウ 受信者のウィンドウサイズ広告

2 段階の通信状態 スロースタート 輻輳回避

スロー・スタートスロー・スタート

エンドノード間の回線状態はわからない 回線の許容量以下に送信量を制御する必要がある ネットワークへの突発的なトラフィック流入を防止可

能

輻輳ウインドウ（ cwnd ） 送信者が送信可能なセグメント数を決定 送信者が管理するウィンドウ （注）受信者の管理するウィンドウとは別

スロー・スタートの仕組みスロー・スタートのアルゴリズム

通信開始時輻輳ウィンドウサイズを 1で初期化

Ack 受信時輻輳ウィンドウを Ack 受信毎に増加輻輳ウィンドウは幾何級数的に増加

スロー・スタートの概要

送信者 受信者

初期 windowサイズは 1で送信

１に対して Ackを返す

windowサイズを 2で送信

2に対して Ackを 2つ返す

windowサイズを 4で送信

1,2,4,8,,,, と幾何級数的にウィンドウサイズを大きくする

輻輳回避状態1. スロースタートを開始し、輻輳ウィンドウが増加2. 送信者は、パケットロスを検知しスロースタートを停止

輻輳が発生したときの輻輳ウィンドウを記憶 輻輳ウィンドウを１に戻しスロースタートを再初期化

輻輳回避状態へ移行 記憶した輻輳ウィンドウまでは通常のスロースタート 記憶した輻輳ウィンドウに達すると

Ack受信ごとに輻輳ウィンドウを上げていかない 輻輳ウィンドウ分のAckを受信して輻輳ウィンドウを開く

TCP Tahoe におけるウィンドウサイズの変化

t

ネットワークの限界

最適なウィンドウサイズ

スロースタート閾値

スロースタート 輻輳回避

TCP Reno におけるウィンドウサイズの変化

t

スロースタート閾値

スロースタート 輻輳回避

ネットワークの限界

最適なウィンドウサイズ

往復時間の測定RTT から分かること

輻輳の度合い パケットロスの指標

RTT は非線形に変化外れ値の可能性

平滑化することで RTT を評価（ RTT評価値）

R は RTT評価値Mは新しい測定値 αは平滑化係数（推奨値は 0.9 ）

R = αR+(1-α)M

再転送タイムアウト値の算出

再転送タイムアウト値（ RTT ）

βは遅延分散係数（推奨値は 2）

再転送タイムアウトするごとに増加 指数バックオフ最大値 64秒

RTO = Rβ (RFC793 推奨式 )

高速再転送アルゴリズム 受信者の TCP が順番の違うセグメントを受信

確認応答（重複 ACK ）を生成する必要

単に順番が入れ替わった … (a) 受信者はセグメントを並び替えて上位層に渡す

パケットロスが発生した … (b) 送信者は該当するセグメントを再送する必要

高速再転送アルゴリズム (a) 、 (b) をいち早く調べる方法

以下の場合、パケット損失の可能性高と判断 重複 ACK を３つ受信した場合

再送タイマを待たずに直ちに再送する

高速再転送アルゴリズム再送タイムアウトを待たずに再送

迅速な再送による転送効率の向上

123４５

発信元 宛て先

インターネット13４５

2 番パケットを転送 Packet loss

3 が届いた時点で 1 番への ACK

1 番への ACK が3 が届いた時、 4 が届いた時、 5 が通ったときの合計 3 回届く

　　 2 番のパケットが届いていない！

セルフクロッキング (1/3)経路の一番細い部分がボトルネックとなり、パケッ

トギャップが発生する

送信者 受信者

帯域が広い 帯域が広い帯域が狭い

ルータ ルータ

ボトルネックボトルネック

パケッ

トギャッ

プ

セルフクロッキング (2/3)受信者はパケットギャップの間隔で Ack を返してく

る

送信者 受信者

帯域が広い 帯域が広い帯域が狭い

ルータ ルータ

セルフクロッキング (3/3)Ack の受信間隔に合わせてパケットを送出する

通信のバースト性が抑えられる

送信者 受信者

帯域が広い 帯域が広い帯域が狭い

ルータ ルータ

まとめ： TCP における輻輳制御

ネットワークの状態を動的に推測

輻輳が発生すれば転送速度を落とす

輻輳が起きないギリギリまで転送速度を上げる

できるだけ早く最適なウィンドウサイズに到達する

ウィンドウサイズが安定すると通信も安定する

エンドノードによる輻輳制御の限界

エンドノードだけでは、ネットワークの状態を完全に把握することは不可能

ネットワーク全体の安定が各エンドノードの自律的な動作に掛かっている 悪意のあるユーザの攻撃や、無知なユーザの無秩序な

利用に対して脆弱

中間ノードでも制御を行う必要性 QoS 技術

QoS とは？Quality of Service

利用するサービスに対して品質を考慮

特にインターネットでは、通信品質 スループット レスポンスタイム到着揺らぎ幅（ジッタ）

自律分散協調型のインターネットでは困難

エンドノードとネットワーク

エンドノードでの制御

ネットワークの状態は分からない

重い処理もできる

ネットワーク全体に影響を及ぼせない

ネットワークでの制御

ネットワークの状態を把握できる

処理が集中しやすい 重い処理は避けたい

ネットワーク全体へ設定が反映される

QoS の必要性全ての通信をスムーズには行えない

サービスの平滑化・差別化料金格差

リアルタイムアプリケーションの優先放送（音楽・動画）対戦型ゲーム IP電話

緊急の電話・緊急でない電話

QoS の実現例専用の回線を用意する

中間ノードでの優先制御 IP アドレス・ポート番号などヘッダの情報で区別ヘッダに特別な情報を負荷

既存のインターネットの概念と反するスケーラビリティとの兼ね合い

問題点

輻輳が発生したらルータはキューを備えている

輻輳が発生　＝　キューが溢れる

キューから溢れたパケットは破棄される

入りきらず , 破棄される

ルータ

キュー

パケットの優先制御優先したいパケットは優先 QUEUE に入れる

ここでは、青いパケットを優先したいとする水色の QUEUE が優先 QUEUE とする

QoS の実現に必要な構成要素サービスの記述

多種多様な要求がある

中間ノードでの優先制御機構

制御情報の伝播 シグナリング技術

管理者による手動設定では対処できない

QoS 機構（１）： Intserv + RSVP

サービスの記述

フローごとの帯域予約 Intserv

予約メッセージフォーマット FF （ Fixed Filter ）方式 SE （ Shared Explicit ）方式 WF （ Wildcard Filter ）方式

QoS 機構（１）： Intserv + RSVP

優先制御機構

RSVP対応ルータ フローの状態を常に監視 フローごとに予約帯域を確保 フローに適合するパケットを優先転送

QoS 機構（１）： Intserv + RSVP

制御情報の伝播

RSVP メッセージ エンド間のルータ全てに伝播させる 送信者→受信者：パスメッセージ 受信者→送信者：予約メッセージ

Intserv + RSVP の問題点エンド間に RSVP対応ルータが不可欠

各ルータがフローの状態を保持マッチングするヘッダフィールドが様々管理する情報が膨大

トラフィックが急増すると破綻

ルータの負荷を軽減する必要性

QoS 機構（２）： Diffserv + BB

サービスの記述

PHB （ Per-HOP Behavior ） EF （ Expedited Forwarding ） AF （ Assured Forwarding ）

DSCP （ Diffserv Code Point ） IPヘッダの TOS フィールド（→ DS フィールド）中に

記述 DS対応ノードは DSCP と PHB のテーブルを保持 DS エッジが記述

DS ドメインに入る際

QoS 機構（２）： Diffserv + BB

Diffserv とスケーラビリティ

Intserv ではルータの負荷が問題

DSCP はヘッダ中のビット列固定長

処理が軽い

QoS 機構（２）： Diffserv + BB

優先制御機構

DS対応ルータ（ DS コア）

トラフィック分類機能 BA （ Behavior Aggregate ） Classifier MF （ Multi Field ） Classifier

TCA （ Traffic Conditioning Agreement ）

QoS 機構（２）： Diffserv + BB

制御情報の伝播

BB （ Bandwidth Broker ） DS ドメイン内のリソース割り当て DS エッジを設定詳細な挙動までは決まっていない 主流となるソフトウェアは未だ無い

研究ベース

MPLS によるトラフィック制御

MPLS （ Multi Protocol Label Switching ） パケット転送技術のひとつ パケットにラベルヘッダを付加

ラベルスイッチング

MPLS を応用したトラフィック制御 ラベルに通信品質制御情報を付加

RSVP-extension Diffserv に類似したモデル

ラベルIPヘッダ

MPLS ネットワーク

MPLSエッジ

MPLSエッジ

外部ネットワーク

外部ネットワーク

LSR

LSR

LSR

通常の IP ネットワークから MPLSネットワークへパ

ケットが転送

ラベルが付加され

る

ラベルが変更され

る

ラベルが変更され

る

ラベルが削除される

パスが張られる

まとめ： QoS と輻輳制御管理ドメイン内での制御

ユーザのニーズを適切に記述

記述された要求に従い制御情報を伝播

中間ノードが優先制御 特定の通信が輻輳を回避