Chapter 3 Chapter 3: トランスポート層 Transport Layer

1

Transport Layer 3-1

Chapter 3Transport Layer

Computer Networking: A Top Down Approach Featuring the Internet, 2nd edition. Jim Kurose, Keith RossAddison-Wesley, July 2002.

A note on the use of these ppt slides:We’re making these slides freely available to all (faculty, students, readers). They’re in PowerPoint form so you can add, modify, and delete slides (including this one) and slide content to suit your needs. They obviously represent a lot of work on our part. In return for use, we only ask the following:

If you use these slides (e.g., in a class) in substantially unaltered form, that you mention their source (after all, we’d like people to use our book!)

If you post any slides in substantially unaltered form on a www site, that you note that they are adapted from (or perhaps identical to) our slides, and note our copyright of this material.

Thanks and enjoy! JFK/KWR

All material copyright 1996-2002J.F Kurose and K.W. Ross, All Rights Reserved

Transport Layer 3-2

Chapter 3: トランスポート層目標:トランスポート層サービスの背後にある原理の理解:多重化／逆多重化

高信頼データ転送

フロー制御

輻輳制御

インターネットにおけるトランスポート層について学習:

UDP: コネクションレストランスポート

TCP: コネクション指向トランスポート

TCP 輻輳制御

Transport Layer 3-3

Chapter 3 内容

3.1 トランスポート層サービス

3.2 多重化と逆多重化3.3 コネクションレス型トランスポート: UDP3.4 高信頼データ転送の原理

3.5 コネクション指向型トランスポート: TCPセグメント構造


フロー制御

コネクション管理

3.6 輻輳制御の原理3.7 TCP 輻輳制御

Transport Layer 3-4

トランスポートサービスとプロトコル

異なるホスト間で実行されるアプリ間に論理的通信を提供

トランスポートプロトコルはエンドシステムにおいて実行

送信側：アプリケーションメッセージをセグメントに分割し，ネットワーク層に渡す

受信側：セグメントからメッセージを再構成し，アプリケーション層に渡す

アプリケーションにとってひとつ以上のプロトコルが利用可能

インターネット: TCP と UDP

applicationtransportnetworkdata linkphysical


networkdata linkphysical



networkdata linkphysicalnetwork

data linkphysical

logical end-end transport

Transport Layer 3-5

トランスポート層とネットワーク層

ネットワーク層: ホスト間の論理的通信

トランスポート層: プロセス間の論理的通信ネットワーク層サービスに依存し，その機能を強化する

家庭での類似:12 人の子供が12人の子供に手紙を送る

プロセス = 子供アプリケーションメッセージ = 封筒内の手紙ホスト = 家庭転送プロトコル = アンとビル

ネットワーク層プロトコル= 郵便サービス

Transport Layer 3-6

インターネットトランスポート層プロトコル

高信頼，順序保証配送: TCP輻輳制御

フロー制御

コネクションセットアップ

低信頼，順序非保証配送: UDP

“best-effort” IP に特別な機能を追加しない（プロセス識別のみ）

利用できないサービス: 遅延保証

帯域保証






networkdata linkphysicalnetwork

data linkphysical

logical end-end transport

2

Transport Layer 3-7

Chapter 3 内容





フロー制御



Transport Layer 3-8

多重化／逆多重化

application

transport

network

link

physical

P1 application

transport

network

link

physical

application

transport

network

link

physical

P2P3 P4P1

host 1 host 2 host 3

= process= socket

受信セグメントを適切なソケットに転送

終点ホストにおける逆多重化:複数ソケットからデータを集め，（後に逆多重で用いられる）ヘッダを付加してまとめる

始点ホストにおける多重化:

Transport Layer 3-9

逆多重化はどのように機能するかホストはIPデータグラムを受信各データグラムは，送信IPアドレス，受信IPアドレス各データグラムは，ひとつのトランスポート層セグメントを運ぶ

各セグメントは，送信ポート番号と受信ポート番号をもつ（特定のアプリの有名なポート番号を思い出そう）

ホストは，適切なソケットにセグメントを向けるためにＩＰアドレスとポート番号を使う

始点ポート番号終点ポート番号

32 bits

アプリケーションデータ

（メッセージ）

他のヘッダフィールド

TCP/UDP セグメントフォーマット

Transport Layer 3-10

コネクションレス型の逆多重化

ポート番号を付与してソケットを生成：

DatagramSocket mySocket1 = new DatagramSocket(99111);

DatagramSocket mySocket2 = new DatagramSocket(99222);

UDP ソケットは（終点ＩＰアドレス，終点ポート番号）

で識別される

ホストがUDPセグメントを受信すると：セグメント内の終点ポート番号をチェック

UDPセグメントをそのポート番号をもつソケットに向ける

同一ソケットにむけられた異なる始点ＩＰアドレスあるいはまた異なる始点ポート番号をもつIPデータグラム


コネクションレス型の逆多重化（つづき）

DatagramSocket serverSocket = new DatagramSocket(6428);

ClientIP:B

P3

clientIP: A

P1P1P3

serverIP: C

SP: 6428DP: 9157

SP: 9157DP: 6428

SP: 6428DP: 5775

SP: 5775DP: 6428

始点ポート番号は“返信アドレス”として使用される


コネクション指向型の逆多重化

TCP ソケットは次の４つの値によって識別される: 始点IPアドレス始点ポート番号

終点IPアドレス終点ポート番号

終点ホストは，4つの値を使ってセグメントをアプリケーションソケットに向ける

サーバホストは同時に多数のTCPソケットをサポートするかもしれない：各ソケットは自身の４つの値によって識別される

Ｗｅｂサーバは各クライアントに対して異なるソケットを持つ非継続型 HTTP は各リクエストに対して異なるソケットを持つ

3


コネクション指向型の逆多重（つづき）

ClientIP:B

P3

clientIP: A

P1P1P3

serverIP: C

SP: 80DP: 9157

SP: 9157DP: 80

SP: 80DP: 5775

SP: 5775DP: 80

P4


Chapter 3 内容





フロー制御




UDP: User Datagram Protocol [RFC 768]

“余計な機能のない,” “余計な部分を削った” インターネットトランスポートプロトコル

“ベストエフォート” サービス，UDPセグメントは， may be:失われる

アプリへの非順序保証配信

コネクションレス：

送信，受信間でハンドシェイク不要

各 UDP セグメントは互いに独立に扱われる

なぜ UDP は存在するのか？

（遅延の原因となりうる）コネクション設定不要

単純：送受信側でコネクション状態なし

小さいセグメントヘッダ

輻輳制御なし：UDP は，所望の速度で送信可能


UDP: さらにストリーミングマルチメディアアプリケーションによく利用される

廃棄への耐性

速度に敏感

他の UDP アプリDNSSNMP

アプリ層で追加されたUDPを介した高信頼転送

アプリケーション独自のエラー回復！

始点ポート番号終点ポート番号

32 bits

アプリケーションデータ（メッセージ）

UDP セグメントフォーマット

長さチェックサム

Length, inbytes of UDP

segment,including

header


UDP チェックサム

始点ホスト:セグメントの内容を16ビット整数の系列として扱う

チェックサム: セグメントの内容の和の１の補数

始点ホストは，UDPチェックサムフィールドにチェックサム値を入力

終点ホスト:受信セグメントの内容の和をチェックサムフィールドを含めて計算

全てのビットが１となる

NO – 誤り検出YES – 誤り未検出．誤りはないのか？

目的:転送セグメント中の“誤り”を検出する（例えば，ビット反転など）

0110011001100110+0101010101010101+0000111100001111=1100101011001010

1の補数=0011010100110101 Transport Layer 3-18

Chapter 3 内容





フロー制御



4


高信頼データ転送の原理アプリ層，トランスポート層，リンク層において重要

重要課題トップ１０！

低信頼性チャネルの特徴が高信頼データ転送プロトコル(rdt: reliable data transfer) の複雑さを決定付ける


高信頼データ転送：はじめに

送信側受信側

rdt_send():上位層（例：アプリ層）から呼び出される．データを終点ホスト側で上位層に渡してください．

udt_send(): rdt によって呼び出される．低信頼性チャネルを介してパケットを終点ホストに転送

rdt_rcv():チャネルの終点ホスト側にパケットが到着すると呼び出される

deliver_data():上位層にデータを配信するためにrdtによって呼び出される．


高信頼データ転送：はじめに

以後:高信頼転送プロトコル(rdt)の始点ホスト，終点ホストを順に発展させる

一方向転送のみを考えるただし，制御情報は両方向に流れる

始点ホスト，終点ホストを記述するために有限状態マシン (FSM: finite state machines) を用いる

state1

state2

状態遷移を引き起こすイベント

状態遷移によってとられるアクション

状態: この状態にいるとき，次のイベントによって次状態が一意に決定される

eventactions


Rdt1.0: 高信頼チャネルを介した高信頼転送

下層チャネルは完全に信頼できるビットエラーなし

パケット損失なし

始点ホストと終点ホストは分離:始点ホストはデータを下層チャネルに送信する

終点ホストは下層チャネルからデータを読む

Wait for call from above packet = make_pkt(data)

udt_send(packet)

rdt_send(data)extract (packet,data)deliver_data(data)

Wait for call from

below

rdt_rcv(packet)

sender receiver


Rdt2.0: ビットエラーのあるチャネル

下層チャネルでパケット内のビット反転が発生しうるUDPチェックサムはビットエラーを検出できる

疑問: 誤りからどのように回復するか:acknowledgements (ACKs):終点ホストが受信パケットはＯＫであると明示的に伝える

negative acknowledgements (NAKs): 終点ホストが受信パケットに誤りがあると明示的に伝える

始点ホストは NAK を受信するとパケットを再送するAck, NAK を使ったヒューマンプロトコルは？rdt2.0 における新メカニズム(rdt1.0を上回る):誤り検出

受信側からのフィードバック：終点ホストから始点ホストへの制御メッセージ(ACK, NAK)


rdt2.0: FSM の記述

Wait for call from above

snkpkt = make_pkt(data, checksum)udt_send(sndpkt)

extract(rcvpkt,data)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) &&isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) && corrupt(rcvpkt)

Wait for ACK or

NAK

Wait for call from

below始点ホスト

終点ホストrdt_send(data)

Λ

5


rdt2.0: 誤りがない場合






udt_send(sndpkt)


udt_send(NAK)


Wait for ACK or

NAK

Wait for call from

below

rdt_send(data)

Λ


rdt2.0: 誤りがある場合






udt_send(sndpkt)


udt_send(NAK)


Wait for ACK or

NAK

Wait for call from

below

rdt_send(data)

Λ


rdt2.0 の致命的欠陥！

ACK/NAK が壊れたらどうする？始点ホストは終点ホストで何が起こっているかわからない！

単純に再送はできない：重複受信の可能性あり

どするか？終点ホストからのACK/NAKに対して始点ホストがACK/NAKを返す．それが失われたらどうするか？

再送する，しかしこれは正しく受信されたパケットの再送信を引き起こす

重複の取り扱い: 始点ホストは，各パケットにシーケンス番号を付与するもし，ACK/NAKが誤った場合は，始点ホストは現在のパケットを再送する

終点ホストは（上位層に上げずに）重複パケットを廃棄する

始点ホストは，１パケットを送信し，受信応答を待つ

stop and wait


rdt2.1: 始点ホストでの ACK/NAKs誤りの扱い

Wait for call 0 from

above

sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)

rdt_send(data)

Wait for ACK or NAK 0 udt_send(sndpkt)

rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isNAK(rcvpkt) )


rdt_send(data)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt)

Wait forcall 1 from

above

Wait for ACK or NAK 1

ΛΛ


rdt2.1: 終点ホストでの ACK/NAKs誤りの取り扱い

Wait for 0 from below

sndpkt = make_pkt(NAK, chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) && not corrupt(rcvpkt) &&has_seq0(rcvpkt)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt)

extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)



extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) && (corrupt(rcvpkt)

sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) && not corrupt(rcvpkt) &&has_seq1(rcvpkt)

rdt_rcv(rcvpkt) && (corrupt(rcvpkt)

sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK, chksum)udt_send(sndpkt)


rdt2.1: ディスカッション

始点ホスト:パケットにシーケンス番号を付与

二つのシーケンス番号(0,1) で十分．なぜか？受信ACK/NAKに誤りがあるかどうかチェックする必要あり

２倍の状態状態は，現在のパケットのシーケンス番号が０か１かを記憶しておかなければならない

終点ホスト:受信パケットが重複かどうかをチェックしなければならない状態は，所望のパケットシーケンス番号が0か1かを示している

注意：受信ホストは，最後のACK/NACが送信側に正しく受信されたかどうかを知ることはできない

6


rdt2.2: NAK フリープロトコル

ACKのみを使って rdt2.1 と同一機能を実現NAKの代わりに，終点ホストは最後に正しく受信されたパケットに対する ACK を送信終点ホストは，最後に正しく受信されたパケットのシーケンス番号をACKに陽に含まなければならない

始点ホストは，重複ACKに対して NAK と同様に対処する：パケットの再送


rdt2.2: 始点ホスト，終点ホストの FSM（一部）


above


rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||

isACK(rcvpkt,1) )

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0)

Wait for ACK

0sender FSM

fragment



extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK1, chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) && (corrupt(rcvpkt) ||

has_seq1(rcvpkt))

udt_send(sndpkt)receiver FSM

fragment

Λ


rdt3.0: 誤りと廃棄があるチャネル

新しい仮定:下層チャネルはパケット(data, ACK)を損失する可能性があるチェックサム，シーケンス番号，ACK，再送が助けになるが，不十分

疑問: ロスをどう扱うか？始点ホストは，失われたデータやACKを待って，再送する

おいおい: 具合悪い？

アプローチ:始点ホストは，“適切な”時間 ACK を待つこの時間内に ACK を受信しなければ再送

もしパケット（またはACK）が（廃棄ではなく）たんに遅れたのなら:再送が重複するが，シーケンス番号で対処できる

終点ホストは，最後に受信したパケットのシーケンス番号を記述しなければならない

カウントダウンタイマーが必要


rdt3.0: 始点ホストsndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)start_timer

rdt_send(data)

Wait for

ACK0

rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isACK(rcvpkt,1) )


above

sndpkt = make_pkt(1, data, checksum)udt_send(sndpkt)start_timer

rdt_send(data)


rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isACK(rcvpkt,0) )


stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

Wait for call 0from

above

Wait for

ACK1

Λrdt_rcv(rcvpkt)

ΛΛ

Λ


rdt3.0: 動作


rdt3.0: 動作

7


rdt3.0 の性能rdt3.0 は動作するが，性能は悪い例: 1 Gbps リンク，15 ms エンド間伝播遅延, 1KB パケット:

Ttransmit = 8kb/pkt10**9 b/sec = 8 microsec

U sender: 利用率 – 始点ホストが送信している時間割合30ms ごとに 1KB パケット -> 1 Gbpsリンク上で33kB/sec スループットネットワークプロトコルが物理的資源の利用を制約している！

U sender =

.008 30.008

= 0.00027 L / R RTT + L / R

=

L (packet length in bits)R (transmission rate, bps) =


rdt3.0: stop-and-wait の動作

first packet bit transmitted, t = 0

sender receiver

RTT

last packet bit transmitted, t = L / R

first packet bit arriveslast packet bit arrives, send ACK

ACK arrives, send next packet, t = RTT + L / R

U sender =

.008 30.008

= 0.00027 L / R RTT + L / R

=


パイプラインプロトコル

パイプライン:始点ホストは，ACK を待つことなく複数のパケットを送信できるシーケンス番号の範囲が増加する

始点ホスト／終点ホストにおけるバッファリング

2種類の一般的なパイプラインプロトコル形式: go-Back-N, selective repeat（選択的再送）


パイプライン: 利用率の改善

first packet bit transmitted, t = 0

sender receiver

RTT

last bit transmitted, t = L / R

first packet bit arriveslast packet bit arrives, send ACK

ACK arrives, send next packet, t = RTT + L / R

last bit of 2nd packet arrives, send ACKlast bit of 3rd packet arrives, send ACK

U sender =

.024 30.008

= 0.0008 3 * L / R RTT + L / R

=

利用率は３杯に増加!


Go-Back-N始点ホスト:パケットヘッダ内に k ビットのシーケンス番号最大 N までのウインドウ, 連続する ACK 身受信のパケット

ACK(n): シーケンス番号 n までの（n を含む）連続する全パケットへ正常受信を通知 – 累積重複 ACK をまるめこむ

ACK未受信パケットに対するタイマーtimeout(n): ウインドウ内の n 以上のシーケンス番号のパケットを再送


GBN: 始点ホストの拡張

Wait start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])…udt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum < base+N) {sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum)udt_send(sndpkt[nextseqnum])if (base == nextseqnum)

start_timernextseqnum++}

elserefuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum)

stop_timerelsestart_timer


base=1nextseqnum=1


Λ

8


GBN: 終点ホストの拡張 FSM

ACKのみ: 正しく受信したパケットに対して，順序どおりに正しく受信された最大シーケンス番号に対してACK を送信重複 ACK を生成するかもしれないExpectedseqnum のみを記憶しておく必要あり

順序誤りのパケット: 廃棄-> 終点ホストのバッファリングなし！最大順序シーケンス番号をもつ ACK パケットの再送

Wait

udt_send(sndpkt)default

rdt_rcv(rcvpkt)&& notcurrupt(rcvpkt)&& hasseqnum(rcvpkt,expectedseqnum)

extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(expectedseqnum,ACK,chksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnum,ACK,chksum)

Λ


GBN の動作


選択的再送

終点ホストは，正しく受信された個々のパケットに ACK を送信する必要に応じ，上位層に順序正しく配送するためにパケットをバッファリング

始点ホストは，ACK 未受信のパケットのみを再送ACK 未受信のパケットごとに始点ホストタイマー

始点ホストウインドウN 累積シーケンス番号送信済の ACK 未受信のパケットのシーケンス番号を制限


選択的再送: 始点ホスト，終点ホストのウインドウ


選択的再送

上位層からのデータ :ウインドウ内で有効なシーケンス番号があれば，パケット送信

timeout(n):パケット nを再送し，タイマーをリセット

ACK(n)（[sendbase,sendbase+N]間）:

パケット n は受信されたものと記録

n がACK未受信の最小パケットであったなら，ウインドウベースを次の ACK 未受信パケットに移動

始点ホストパケット n（[rcvbase, rcvbase+N-1] 内）

ACK(n)を送信順序がおかしい: バッファリング順序どおり: （バッファ内に含まれる順序どおりのパケットも含めて）上位層に配信し，ウインドウをまだ未受信のパケットに進める

パケット n（[rcvbase-N,rcvbase-1] 内）

ACK(n)その他:無視

終点ホスト


選択的再送の動作

9


選択的再送:ジレンマ

例: シーケンス番号: 0, 1, 2, 3ウインドウサイズ = 3

終点ホストは二つのシナリオ間の差がわから

(a) では，重複データを新規データとして上位層に誤配送する

疑問: シーケンス番号の大きさとウインドウサイズの間の関係は？ウインドウサイズ＜シーケンス番号


Chapter 3 内容





フロー制御




TCP: 概要 RFCs: 793, 1122, 1323, 2018, 2581

全二重データ:同一コネクション上での双方向データフロー

MSS: maximum segment size，最大セグメントサイズ

コネクション指向型:データ交換の前に，ハンドシェイク (制御メッセージ交換) により，始点ホスト，終点ホストの状態を設定

フロー制御:始点ホストが終点ホストを過負荷にすることはない

ポイント・ツー・ポイント:１始点ホスト，１終点ホスト

高信頼，順序保証，バイトストリーム：メッセージの境界なし

パイプライン:TCP 輻輳制御，フロー制御によりウインドウ設定

送信＆受信バッファ

socketdoor

TCPsend buffer

TCPreceive buffer

socketdoor

segment

applicationwrites data

applicationreads data


TCP セグメント構造

source port # dest port #

32 bits

applicationdata

(variable length)

sequence numberacknowledgement number

Receive windowUrg data pnterchecksum

FSRPAUheadlen

notused

Options (variable length)

URG: 緊急データ(通常未使用)

ACK: ACK 番号有効

PSH: 上位層に直ちに渡す(通常未使用)

RST, SYN, FIN:コネクション設定

(セットアップ，終了コマンド)

終点ホストが次に受信を望むバイト番号

データのバイト単位でのカウント(セグメントではない!)

Internetチェックサム

(UDPと同様)


TCP シーケンス番号とACKシーケンス番号:

セグメントデータの開始バイトのバイトストリームにおけるバイト単位の通し番号

ACK:次に受信すべきバイトのシーケンス番号

累積 ACK質問: 終点ホストは，順序逆転して到着したセグメントをどのように扱うのか

答え: TCP RFCは規定せず，実装者任せ

Host A Host B

Seq=42, ACK=79, data = ‘C’

Seq=79, ACK=43, data = ‘C’

Seq=43, ACK=80

Usertypes

‘C’

host ACKsreceipt

of echoed‘C’

host ACKsreceipt of‘C’, echoes

back ‘C’

timesimple telnet scenario


TCP ラウンドトリップ時間とタイムアウト

疑問: TCPはどのようにタイムアウト時間を設定するのか？RTTより長い時間しかし，RTTは可変

短すぎると…: はやまったタイムアウト

不要な再送

長すぎると…: セグメントロスに対する応答が遅い

疑問： RTTをどのように見積もるか?SampleRTT: セグメント送信からACK受信までの時間を測定再送は無視

SampleRTT は変動するので，より安定した値が欲しい

最近のいくつかの測定結果の平均，最新の RTT ではない

10



EstimatedRTT = (1- α)*EstimatedRTT + α*SampleRTT

指数加重移動平均

過去のサンプルの影響は指数的に減少

典型的な値: α = 0.125


RTT 推定の例:RTT: gaia.cs.umass.edu to fantasia.eurecom.fr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106time (seconnds)

RTT

(mill

iseco

nds)

SampleRTT Estimated RTT



タイムアウトの設定

EstimtedRTT ＋ “安全マージン”EstimatedRTTの変動大 -> より大きな安全マージン

SampleRTT がEstimatedRTTからどの程度変動するかの一次推定:

TimeoutInterval = EstimatedRTT + 4*DevRTT

DevRTT = (1-β)*DevRTT +β*|SampleRTT-EstimatedRTT|

(推奨値, β = 0.25)

タイムアウト値の設定:


Chapter 3 内容





フロー制御




TCP 始点ホストのイベント:アプリからのデータ受取り:シーケンス番号つきセグメントの生成

シーケンス番号は，セグメントの1バイト目のバイトストリーム値

タイマ未動作ならタイマ起動 (ACK未受信の最も古いセグメントに対するタイマ）

タイムアウト間隔: TimeOutInterval

タイムアウト:タイムアウトを引き起こしたセグメントの再送

タイマ再起動

Ack受信:ACKがセグメントに対して初めてのものならどこまで ACK されたのかを更新

もし未決着のセグメントがあれば，タイマを起動


TCP 送信ホスト(単純化)

NextSeqNum = InitialSeqNumSendBase = InitialSeqNum

loop (forever) {switch(event)

event: data received from application above create TCP segment with sequence number NextSeqNumif (timer currently not running)

start timerpass segment to IP NextSeqNum = NextSeqNum + length(data)

event: timer timeoutretransmit not-yet-acknowledged segment with

smallest sequence numberstart timer

event: ACK received, with ACK field value of y if (y > SendBase) {

SendBase = yif (there are currently not-yet-acknowledged segments)

start timer }

} /* end of loop forever */

コメント:• SendBase-1: 最も最近に累積 ACK されたバイト

例:• SendBase-1 = 71;y= 73の場合，終点ホストは73以上を望んでおり，y > SendBaseであるから，新規データはACK される

11


TCP: 再送シナリオHost A

Seq=100, 20 bytes data

ACK=100

time早まったタイムアウトの場合

Host B


ACK=120


Seq=

92 t

imeo

ut

ACK=120

Host A


ACK=100

loss

tim

eout

ACK損失の場合

Host B

X


ACK=100

time

Seq=

92 t

imeo

ut

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100


TCP 再送シナリオ (つづき)Host A


ACK=100

loss

tim

eout

累積ACKの場合

Host B

X


ACK=120

time

SendBase= 120


TCP ACK 生成 [RFC 1122, RFC 2581]

終点ホストにおけるイベント

予定したシーケンス番号のセグメント到着，このシーケンス番号のセグメントまでの全データはACK済み

予定したシーケンス番号のセグメントの到着，ACK の送信待ち状態のセグメントが存在する

予定したシーケンス番号より大きい値のセグメントの到着，データ欠損の検出

受信データの欠損部を部分的または完全に埋めるセグメントの受信

終点ホストにおけるアクション

ACK を遅らせる，正しい順序の次のセグメントの到着を 500ms 待つ，この間に到着がない場合，当然 ACK を送信

２つのセグメントに対する累積 ACK を直ちに送信

予定するシーケンス番号（欠損部の小さい側）を示す重複ACKを直ちに送信

そのセグメントが欠損部の番号の小さい側から連続している場合は，直ちにACK を送信


高速再送

タイムアウト間隔は，相対的に長い：損失パケット再送前の長期遅延

重複ACKによるセグメントロスの検出始点ホストは，しばしば連続してセグメントを送信する

セグメントが廃棄された場合，重複 ACK が送信される傾向がある

始点ホストが同一データに対する ACK を３つ受信した場合，ACKが対象とするセグメントが失われた後のセグメントに対するものと推定する:高速再送：タイマが切れる前にセグメントを再送


event: ACK received, with ACK field value of y if (y > SendBase) {

SendBase = yif (there are currently not-yet-acknowledged segments)

start timer }

else { increment count of dup ACKs received for yif (count of dup ACKs received for y = 3) {

resend segment with sequence number y}

高速再送アルゴリズム:

既に ACK を受信したセグメントに対する重複 ACK

高速再送


Chapter 3 内容





フロー制御



12


TCP フロー制御

TCPコネクションの終点ホストは受信バッファをもつ：

スピード制御サービス：アプリケーション読み出し速度に送信速度を調整する

アプリプロセスは，バッファからの読み出しに遅れるかもしれない

始点ホストが速く送信しすぎることにより終点ホストのバッファをオーバフローさせることがないようにする

フロー制御


TCP フロー制御: どのように動作するか

(TCP 終点ホストは，ことなる順序で到着したセグメントを廃棄すると仮定)バッファ内の空きスペース

= RcvWindow= RcvBuffer-[LastByteRcvd -

LastByteRead]

終点ホストは，セグメント内にRcvWindow 値を含むことで，空きスペースを通知

始点ホストは，ACK未受信のデータをRcvWindowに制限受信バッファがオーバフローしないことを保証


Chapter 3 内容





フロー制御




TCP コネクション管理Recall: TCP 始点ホストと終点ホストは，データセグメント交換の前にコネクションを設定する

TCP 変数の初期化:シーケンス番号

バッファ，フロー制御情報（例，受信ウインドウ）

クライアント：コネクション開始側Socket clientSocket = new Socket("hostname","port

number");

ｻｰﾊﾞ: クライアントによってコンタクトをうけるSocket connectionSocket = welcomeSocket.accept();

スリーウェイハンドシェイク:Step 1: クライアントホストは，TCP

SYN セグメントをサーバに送信初期シーケンス番号を記述

データなし

Step 2: サーバホストは，SYNを受信すると，SYNACKセグメントで応答

サーバはバッファを割当る

サーバの初期シーケンス番号を記述

Step 3: クライアントは，SYNACKを受信すると，ACKセグメントで応答する．このセグメントはデータを含みうる


TCP コネクション管理(つづき)

コネクションの終了:

client closes socket:clientSocket.close();

Step 1: クライアントエンドシステムは，TCP FIN 制御セグメントをサーバに送信

Step 2: serverサーバは，FINを受信すると，ACKで応答，FINを送信

client

FIN

server

ACK

ACK

FIN

close

close

closed

tim

ed w

ait



Step 3: client はFINを受信すると，ACKで応答

タイムアウトに入る – 受信した FIN に対して ACK で応答するため

Step 4: serverはACKを受信すると，コネクションをクローズ

注意: わずかな変更で，同時にFIN （双方が同時にコネクションを終了する場合）を行う場合を取り扱うことができる

client

FIN

server

ACK

ACK

FIN

closing

closing

closed

tim

ed w

ait

closed

13



TCP clientlifecycle

TCP serverlifecycle


Chapter 3 内容





フロー制御




輻輳制御の原理

輻輳:簡単にいうと: “多くのソースが大量のデータをネットワークが扱うことができる速度より速く送信している”フロー制御とは異なる！

現象:パケット廃棄 (ルータにおけるバッファオーバーフロー)遅延大 (ルータバッファにおける待ち)

非常に重要な問題のトップ１０！


輻輳の原因/コスト：シナリオ１

始点ホスト２，終点ホスト２

ルータ１，無限バッファ

再送なし

輻輳時は遅延大

最大スループット達成可能

unlimited shared output link buffers

Host Aλin : original data

Host B

λout


輻輳の原因/コスト：シナリオ２

ルータ１，有限バッファ

始点ホストは，ロスしたパケットを再送

finite shared output link buffers

Host A λin : original data

Host B

λout

λ'in : original data, plus retransmitted data


輻輳の原因/コスト：シナリオ２常に (goodput)が成立

ロス発生時のみの“完璧な”再送：

（廃棄されていなくとも）遅延大のパケットの再送は，同じに対し，（

完璧な再送の場合よりも）を増大させる

λin

λout=

λin

λout>

λin

λout

輻輳のコスト:ある “goodput” に対してより多くの再送不必要な再送：リンクは同一パケットの複数のコピーを伝送

λin

ルータの空きバッファ検出可能な場合パケットロスを正確に検出可能な場合タイムアウト値が小さくパケットロスを正確に検出できない場合

14


輻輳の原因/コスト：シナリオ３始点ホスト４

マルチホップパス

タイムアウト/再送

λin

質問: とが大きく

なると，何が起こるか？

λin

finite shared output link buffers

Host Aλin : original data

Host B

λout

λ'in : original data, plus retransmitted data


輻輳の原因/コスト：シナリオ３

輻輳の別のコスト:パケット廃棄が発生した場合，そのパケットのために利用された上流リンクの帯域は浪費されたことになる！

Host A

Host B

λou

t


輻輳制御へのアプローチ

エンド間輻輳制御:ネットワークからの陽なフィードバックなし

輻輳は，エンドシステムが観測する遅延やロスから推定される

TCP によってとられるアプローチ

ネットワーク支援型輻輳制御:ルータがエンドシステムにフィードバックを提供

輻輳かどうかを示す１ビット(SNA, DECbit, TCP/IP ECN, ATM)始点ホストが送信可能な速度

輻輳制御のための２つの基本的アプローチ:


ケーススタディ: ATM ABR 輻輳制御

ABR: available bit rate:エラスティックサービス（elastic service）始点ホストのパスが低負荷なら：

送信ホストは利用可能な帯域を使用すべき

始点ホストのパスが輻輳しているなら：

始点ホストは，最小保証速度まで速度を落とすべき

資源管理 (RM: resource management)セル:始点ホストによって送信され，データセルの間に分散して挿入される

RMセル内のビットはスイッチによって設定される(ネットワーク支援型)

NI bit: レート非増加（中程度の輻輳）

CI bit:輻輳通知RMセルは，これらのビットを保持したまま，終点ホストによって始点ホストに送り返される


ケーススタディ: ATM ABR 輻輳制御

RMセル内の２バイト明示的レート(ER: explicit rate)フィールド輻輳スイッチは，セル内のER値を下げるパス上の最小対応レートに送信レートを適応できる

データセル内のEFCIビット: 輻輳スイッチ内で1にセットされるRMセルにEFCIビットがセットされている場合，終点ホストは，次にくる RMセル内のCIビットに1をセットして送り返す


Chapter 3 内容





フロー制御



15


TCP 輻輳制御

エンド間制御 (ネットワーク支援なし)始点ホストは，伝送を制限:LastByteSent-LastByteAcked

≤ CongWin

大雑把に言うと

CongWinは，知覚されたネットワーク輻輳に応じて，動的に制御される

始点ホストはどうやって輻輳を知覚するのか?ロスイベント = タイムアウトまたは３重複 ACKTCP 始点ホストは，ロスイベントの後，レート(CongWin) を減少させる

３つのメカニズム:AIMD（加算増加，乗算減少）

スロースタート

タイムアウトへの対応

rate = CongWinRTT Bytes/sec


TCP AIMD

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

乗算的減少: ロスイベント認識後，CongWin を半減させる

加算的増加: ロスイベントがない場合，RTTごとにCongWin を 1 MSS だけ増加：プロービング

Long-lived TCP connection


TCP スロースタート

コネクション開始時，CongWin = 1 MSS例: MSS = 500 bytes & RTT = 200 msec初期レート = 20 kbps

利用可能帯域はおそらくMSS/RTT より十分大きい相当なレートまで，すばやく上昇させることが望ましい

コネクション開始時は，最初のロスイベントまで，レートを指数関数的に増加させることが望ましい


TCP スロースタート (つづき)

コネクション開始時，最初のロスイベントまでレートを指数関数的に増加：

RTTごとに CongWin を倍増

ACK受信ごとに CongWinをインクリメント

まとめると…:初期レートは小さいが，指数関数的に増加

Host A

one segment

RTT

Host B

time

two segments

four segments


改善

３つの重複ACK受信後：CongWin を半減

その後，ウインドウを線形増加

しかし，タイムアウトイベント

後は：

CongWin を1 MSSに設定その後，window を指数関数的に増加

閾値に到達後，線形的に増加

• ３つの重複 ACKは，セグメントをいくらかは配送できるということを示している• ３つの重複 ACK 以前にタイムアウトは，“より強い警告”である

フィロソフィー:


改善 (つづき)質問: いつ指数増加から線形増加に切り替えるべきか？

答え: CongWin がタイムアウト以前の半分の値に到達したとき

実装:可変閾値

ロスイベント時，閾値は，ロスイベント直前の CongWinの半分に設定

0

2

4

6

8

10

12

14

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Transmission round

cong

estio

n w

indo

w s

ize

(seg

men

ts)

threshold

TCP Tahoe

TCP Reno

16


まとめ: TCP 輻輳制御

CongWinが Threshold 以下のとき，始点ホストはスロースタートフェーズに入り，ウインドウを指数的に増加させる

CongWinが Threshold を超えると，始点ホストは，輻輳回避フェーズに入り，ウインドウを線形的に増加させる

３重ACK受信後，Threshold を CongWin/2 に設定し，CongWin を閾値に設定する

タイムアウト発生後は，閾値を CongWin/2 に設定し，CongWin を 1 MSS に設定する


公平性の目的: K本のTCPセッションが帯域 R の同一ボトルネックリンクを共有している場合，各セッションは平均R/Kの速度を持つべきである

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP 公平性


TCP はなぜ公平化？２本の競合セッション:加算増加は，スループット増加時，傾き１の増加を与える

乗算減少は，スループットを比例的に減少させる

R

R

等しい帯域分割

Connection 1 throughput

Conn

ecti

on 2

thr

ough

put

輻輳回避: 加算増加廃棄: ウインドウ半減

輻輳回避: 加算増加廃棄: ウインドウを半減


公平性 (つづき)公平性と UDPマルチメディアアプリはTCP を使わないことが多い

輻輳制御による速度調整を望まない

代わりに UDP を仕様:一定レートで音声／映像を送信，パケット廃棄への耐性

研究テーマ: TCP friendly

公平性と並列TCPコネクションアプリがホスト間で複数コネクションをはることを妨げるものはない

Webブラウザはこれを実行例: レート R のリンクが9コネクションをサポート：新規アプリが1TCPを設定すれば，レート R/10 を得る新規アプリが 9 TCPを設定すれば，レート R/2 を得る


遅延モデル

Q: リクエスト送信後，Webサーバからオブジェクトを受信するのにどのくらいの時間を要するか？

輻輳を無視すると，遅延は以下に影響される:TCP コネクション設定データ伝送遅延

スロースタート

記号と仮定:クライアント・サーバ間は帯域R の１リンクS: MSS (bits)O: オブジェクトサイズ (bits)再送なし (廃棄なし，誤りなし)

ウインドウサイズ:最初の仮定: 固定輻輳ウインドウ，W セグメントその後，スロースタートをモデ

ル化した可変ウインドウに


固定輻輳ウインドウ (1)

ケース１:WS/R > RTT + S/R: ウインドウ内のデータを全て送信する前にウインドウ内の第１セグメントに対する ACK が返ってくる

遅延 = 2RTT + O/R

17


固定輻輳ウインドウ (2)

ケース２:WS/R < RTT + S/R: ウインドウ内のデータを送信した後，ACKが返ってくるのを待つ

遅延 = 2RTT + O/R+ (K-1)[S/R + RTT - WS/R]


TCP 遅延モデル: スロースタート (1)

ウインドウがスロースタートに従って増加すると仮定

オブジェクト転送遅延が以下の式で与えられることを示す:

RS

RSRTTP

RORTTLatency P )12(2 −−⎥⎦

⎤⎢⎣⎡ +++=

ここで，P はサーバで TCP がアイドルとなる回数であり，

}1,{min −= KQP

- ここで，Q は，オブジェクトが無限サイズとしたときに，サーバがアイドルとなる回数- K は，オブジェクト全てを送信するのに必要なウインドウ回数


TCP 遅延モデル: スロースタート (2)

RTT

initiate TCPconnection

requestobject

first window= S/R

second window= 2S/R

third window= 4S/R

fourth window= 8S/R

completetransmissionobject

delivered

time atclient

time atserver

例:• O/S = 15 セグメント• K = 4 ウィンドウ• Q = 2• P = min{K-1,Q} = 2

サーバは P=2 回アイドル

遅延要素:• 2 RTT：コネクション設定と要求に対するもの• O/R：オブジェクト転送のため• スロースタートによりサーバがアイドルとなる時間

サーバーアイドル回数: P = min{K-1,Q}


TCP 遅延モデル (3)

RS

RSRTTPRTT

RO

RSRTT

RSRTT

RO

idleTimeRTTRO

P

kP

k

P

pp

)12(][2

]2[2

2delay

1

1

1

−−+++=

−+++=

++=

−

=

=

∑

∑

イドル時間　　　　　　　　　ア

番目のウインドウ後のk 2 1 =⎥⎦⎤

⎢⎣⎡ −+

+−

RSRTT

RS k

を受信するまでの時間信開始してからサーバがセグメント送 ACK=+ RTTRS

k2 1

要する時間　　　　送信するのに

番目のウインドウを=−

RSk

RTT

initiate TCPconnection

requestobject

first window= S/R

second window= 2S/R

third window= 4S/R

fourth window= 8S/R

completetransmissionobject

delivered

time atclient

time atserver


TCP Delay Modeling (4)

⎥⎥⎤

⎢⎢⎡ +=

+≥=

≥−=

≥+++=

≥+++=−

−

)1(log

)}1(log:{min

}12:{min

}/222:{min}222:{min

2

2

110

110

SO

SOkk

SOk

SOkOSSSkK

k

k

k

L

L

無限サイズのオブジェクトに対してサーバがアイドルとなる回数 Q の計算も同様（テキストの課題）

K = オブジェクト全てを送信するのに必要なウインドウ回数K をどのように計算するか？


HTTP モデリングWeb ページが以下から構成されると仮定:

1 基本 HTML ページ (サイズ O bits)M 個の画像 (各サイズ O bits)

非継続型 HTTP: M+1 TCP コネクションが順番に設定される応答時間 = (M+1)O/R + (M+1)2RTT + アイドル時間の総和

継続型 HTTP:2 RTT ：ベース HTML ファイルを要求，受信するための時間1 RTT ：M画像を要求，受信するための時間応答時間 = (M+1)O/R + 3RTT + アイドル時間の総和

非継続型 HTTP （X 本の並列コネクション）M/X は整数と仮定1 TCP はコネクション用M/X セットの画像用並列コネクション応答時間 = (M+1)O/R + (M/X + 1)2RTT + アイドル時間の総和

18


02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP 応答時間 (秒単位)RTT = 100 msec, O = 5 Kbytes, M=10 and X=5

狭帯域に対しては，伝送時間がコネクション，応答時間において主要因

継続型コネクションは，並列コネクションに対して若干の改善を与えるのみ


0

10

20

30

40

50

60

70

28Kbps

100Kbps

1Mbps

10Mbps

non-persistent

persistent

parallel non-persistent

HTTP 応答時間 (秒単位)RTT =1 sec, O = 5 Kbytes, M=10 and X=5

RTTが大きくなると，TCP設定，スロースタート遅延が応答時間において大きな要因になる．継続型コネクションは，特に帯域遅延積大のネットワークにおいて，重大な改善をもたらす．


Chapter 3: まとめトランスポート層サービスの背後にある原理:多重化，逆多重化

高信頼性データ転送

フロー制御

輻輳制御

インターネットにおける事例と実装

UDPTCP

Next:ネットワークのエッジ（アプリ層，トランスポート層）を離れて

ネットワークのコアに

Chapter 3 Chapter 3: トランスポート層 Transport Layer

Documents