自律分散協調システム論 第 13 回「 TCP と輻輳制御 /QoS 制御」
-
Upload
ramona-golden -
Category
Documents
-
view
53 -
download
4
description
Transcript of 自律分散協調システム論 第 13 回「 TCP と輻輳制御 /QoS 制御」
輻輳制御の重要性 (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)
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)
ネットワークの状態推測機構 ネットワークの情報は直接手に入らない エンド間の通信から得られる情報で推察
単純なアルゴリズム パケットが落ちない
転送量を上げる パケットが落ちた
転送量を落とす
スロー・スタートスロー・スタート
エンドノード間の回線状態はわからない 回線の許容量以下に送信量を制御する必要がある ネットワークへの突発的なトラフィック流入を防止可
能
輻輳ウインドウ( cwnd ) 送信者が送信可能なセグメント数を決定 送信者が管理するウィンドウ (注)受信者の管理するウィンドウとは別
スロー・スタートの概要
送信者 受信者
初期 windowサイズは 1で送信
1に対して Ackを返す
windowサイズを 2で送信
2に対して Ackを 2つ返す
windowサイズを 4で送信
1,2,4,8,,,, と幾何級数的にウィンドウサイズを大きくする
輻輳回避状態1. スロースタートを開始し、輻輳ウィンドウが増加2. 送信者は、パケットロスを検知しスロースタートを停止
輻輳が発生したときの輻輳ウィンドウを記憶 輻輳ウィンドウを1に戻しスロースタートを再初期化
輻輳回避状態へ移行 記憶した輻輳ウィンドウまでは通常のスロースタート 記憶した輻輳ウィンドウに達すると
Ack受信ごとに輻輳ウィンドウを上げていかない 輻輳ウィンドウ分のAckを受信して輻輳ウィンドウを開く
往復時間の測定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 を3つ受信した場合
再送タイマを待たずに直ちに再送する
高速再転送アルゴリズム再送タイムアウトを待たずに再送
迅速な再送による転送効率の向上
12345
発信元 宛て先
インターネット1345
2 番パケットを転送 Packet loss
3 が届いた時点で 1 番への ACK
1 番への ACK が3 が届いた時、 4 が届いた時、 5 が通ったときの合計 3 回届く
2 番のパケットが届いていない!
セルフクロッキング (1/3)経路の一番細い部分がボトルネックとなり、パケッ
トギャップが発生する
送信者 受信者
帯域が広い 帯域が広い帯域が狭い
ルータ ルータ
ボトルネックボトルネック
パケッ
トギャッ
プ
まとめ: TCP における輻輳制御
ネットワークの状態を動的に推測
輻輳が発生すれば転送速度を落とす
輻輳が起きないギリギリまで転送速度を上げる
できるだけ早く最適なウィンドウサイズに到達する
ウィンドウサイズが安定すると通信も安定する
エンドノードによる輻輳制御の限界
エンドノードだけでは、ネットワークの状態を完全に把握することは不可能
ネットワーク全体の安定が各エンドノードの自律的な動作に掛かっている 悪意のあるユーザの攻撃や、無知なユーザの無秩序な
利用に対して脆弱
中間ノードでも制御を行う必要性 QoS 技術
QoS とは?Quality of Service
利用するサービスに対して品質を考慮
特にインターネットでは、通信品質 スループット レスポンスタイム到着揺らぎ幅(ジッタ)
自律分散協調型のインターネットでは困難
エンドノードとネットワーク
エンドノードでの制御
ネットワークの状態は分からない
重い処理もできる
ネットワーク全体に影響を及ぼせない
ネットワークでの制御
ネットワークの状態を把握できる
処理が集中しやすい 重い処理は避けたい
ネットワーク全体へ設定が反映される
QoS の実現例専用の回線を用意する
中間ノードでの優先制御 IP アドレス・ポート番号などヘッダの情報で区別ヘッダに特別な情報を負荷
既存のインターネットの概念と反するスケーラビリティとの兼ね合い
問題点
QoS 機構(1): Intserv + RSVP
サービスの記述
フローごとの帯域予約 Intserv
予約メッセージフォーマット FF ( Fixed Filter )方式 SE ( Shared Explicit )方式 WF ( Wildcard Filter )方式
Intserv + RSVP の問題点エンド間に RSVP対応ルータが不可欠
各ルータがフローの状態を保持マッチングするヘッダフィールドが様々管理する情報が膨大
トラフィックが急増すると破綻
ルータの負荷を軽減する必要性
QoS 機構(2): 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 機構(2): Diffserv + BB
優先制御機構
DS対応ルータ( DS コア)
トラフィック分類機能 BA ( Behavior Aggregate ) Classifier MF ( Multi Field ) Classifier
TCA ( Traffic Conditioning Agreement )
QoS 機構(2): 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ネットワークへパ
ケットが転送
ラベルが付加され
る
ラベルが変更され
る
ラベルが変更され
る
ラベルが削除される
パスが張られる