ACK 到着間隔計測に基づくネットワーク状況推定を利用した TCP 輻輳制御

(1)

指導教授印受付印

平成 23 年度修士論文

ACK 到着間隔計測に基づくネットワーク状況推定を利用した

TCP 輻輳制御

早稲田大学大学院基幹理工学研究科情報理工学専攻 5110B102-3

根本洋平

指導甲藤二郎教授

2012 年 1 月 31 日

(2)

第 1 章序論

1.1 はじめに

近年，インターネットをはじめとするIP網の大規模化が進み，ネットワークは世界規模で拡大し続けている．基幹系のネットワークでは光ファイバによる波長多重通信によって拠点間の大容量通信が行われ，アクセス系のネットワークでもFTTH(Fiber to The Home) が一般的になってきている．またクラウドコンピューティングと呼ばれるネットワークを介してアプリケーションや仮想化されたコンピュータシステムを利用する技術も発展してきている．

このようなネットワークではTCP/IPプロトコルが広く用いられている．そのトランスポート層で用いられるTCPはコネクション型のプロトコルでありすべてのデータを確実に届けるための再送制御機構を持ち，また効率的な通信を行うためのフロー制御，輻輳制御などを備えている．

しかし，近年のネットワークの広帯域・高遅延化にともない現在まで標準的に用いられてきた輻輳制御方式である TCP Reno[1]では十分な帯域が確保できないという問題が指摘され，多くのTCPの輻輳制御方式が提案されてきた．TCPの輻輳制御方式の評価指標として広帯域・高遅延環境でのスループット効率性，既存手法との親和性がまず挙げられる．

スループット効率性に関しては，輻輳回避フェーズには輻輳ウィンドウをより高速に増加させ，パケット廃棄が生じた際の減少を抑えるLoss-based手法の高速TCPやRTT(Round

Trip Time)を観測して一定の閾値を超えると輻輳と判断するDelayed-based手法の輻輳制

御方式により改善が行われた．既存手法との親和性に関しては，高速TCPは従来の手法と競合した際にスループットを押し下げてしまう問題点や，Delayed-basd 手法の方式は Loss-based 手法の方式と競合した際に性能が低下してしまう問題点がある．一方 Loss-based手法と Delayed-based 手法を組み合わせた，Hybrid 手法の方式が提案され，

従来手法と競合時に一定の親和性を持つことが確認されている[2]．

また，その他の評価の観点としてはRTT公平性や新たに標準となりつつある輻輳制御方式への対応が挙げられる．RTT公平とは異なるRTTを持つコネクション同士が競合した際の公平性である．RTT 公平を満たす輻輳制御方式の一つとして筆者らが提案した HRF

TCP[2]がある．HRF TCPは競合するコネクションのRTTに応じて輻輳ウィンドウの上げ

幅を変化させることでRTT公平な制御を行っている．しかし他の輻輳制御手法と競合する場合にRTT 公平性を実現するためには，競合するコネクションの RTTを推定する必要がある．新たに標準となりつつある輻輳制御方式として，Windows 系 OS では Compound TCP(CTCP)[3]が，Linux系OSではCUBIC TCP[4]が現在デフォルトで実装されている．

CUBIC TCPは従来の方式に比べよりアグレッシブに帯域を獲得する高速TCPであり，従

来方式との差異が大きい．そのため競合するコネクションのTCP制御方式を識別し，その方式に対応した制御を行っていくことが求められる．制御方式の識別を行うためには，競

(6)

合するコネクションの輻輳ウィンドウの挙動を推定する必要がある．

競合するコネクションの情報を取得する方法としては，中継ノードでの計測やフィードバックパケットを利用する方法もあるが，現状のネットワークが自律分散型であることを考慮するとEnd端末が直接取得可能な情報を利用して推定を行うことが望ましいと考えられる．

これらをふまえ本稿では，End 端末が直接取得可能な情報を利用してネットワークの状況の推定を行い，その情報を用いてTCPの輻輳制御方式の公平性を高めることができることを示す．

(7)

1.2 本論文の構成

第2章では，TCP/IPについて述べる．

第3章では，TCPの輻輳制御方式について述べる．

第4章では，提案手法について述べる．

第5章では，評価実験について述べる．

第6章では，総括と今後の展開について述べる．

(8)

第 2 章 TCP/IP

2.1 TCP/IP

ISO（国際標準化機構：International Oganization for Standardideation）やITU（国際電気通信連合：International Telecommunication Union）といった機関が中心になって異なる種類のコンピュータ間でも自由に通信が可能にするためのネットワークの設計方針であるOSI（開放型システム間相互接続：Open System Interconnection）参照モデルが作成された．

OSI 参照モデルは階層化アーキテクチャであり，それぞれの階層が特定の機能を持ち，

隣接する層とのデータの受け渡し方法を定めておけば，ある機能を変更したときでも他の層に影響が及ばないようになっている．

しかし実際には高い汎用性を想定していたゆえ複雑な仕様となったOSI参照モデルが普及することはなく，IETF（Internet Engineering Task Force）の議論を通して仕様が定め

られたTCP/IPが広く普及した．TCP/IPとはIPを利用して通信を行う際に必要となるプ

ロトコル群の総称である．

OSI参照モデルとTCP/IPの対応を図2.1に示す．また各層の働きを以下で説明する．

図2.1. OSI参照モデルとTCP/IPの階層モデルの関係

・アプリケーション層

対応するプロトコルとして WWW の通信で使われる HTTP や電子メールで用いられる

SMTP，POP3，ファイル転送で用いられる FTP などがある．各アプリケーションの中に

実装されている．

アプリケーション層プレゼンテーション層

セッション層トランスポート層

ネットワーク層データリンク層

物理層ハードウェア

ネットワークインターフェース層インターネット層アプリケーション層

トランスポート層 OSI参照モデル TCP/IPの階層モデル

(9)

・トランスポート層

トランスポート層のプロトコルはアプリケーションプログラムの識別，コネクションの確立，信頼性の確保のための処理などを行う．TCP/IPにはTCPとUDPの2つのトランスポート層プロトコルがある．TCPは信頼性が求められる通信に，UDPはリアルタイム性が求められる通信に主に用いられる．

・インターネット層

IPが使用され，IPアドレスをもとにして経路選択されながら最終目的のホストまでデータパケットを転送する．

・ネットワークインタフェース層

Ethernetなどのデータリンクを利用して通信を行う層である．ATM，FDDIなども該当す

る．

TCP/IPで通信を行う場合，データを送信するときは上位の層から下位の層に向かってデ

ータが渡されていき，各層で必要とされる情報がヘッダとして付加されていく．受信するときはその逆で下位層から上位層に向かってデータが渡され，各層はヘッダを解析してそれを削除する．

図2.2. TCP/IPの階層によるデータ処理

2.2 TCP の基本機能

TCP は IP を利用して信頼性のある通信を実現するための制御を行うトランスポート層のプロトコルである．具体的にはチェックサム，シーケンス番号，応答確認，再送制御，

コネクション管理，ウィンドウ制御などにより信頼性を確保する．トランスポート層で IP を利用する通信に用いるプロトコルにはUDPもあるが，こちらは複雑な制御を行わずにコネクションレスの通信を行いリアルタイム性が重視されるマルチメディア通信などに向いトランスポート層

インターネット層

ネットワークインターフェース層 TCPヘッダ

アプリケーションデータ

アプリケーションデータ IPヘッダ

IPヘッダイーサネットヘッダ

TCPヘッダ TCPヘッダ

アプリケーション層

ヘッダ解析ヘッダ解析

ヘッダ解析ヘッダ付加

ヘッダ付加

(10)

ている．TCPセグメントフォーマットを以下の図3.1に示す．

図2.3. TCPセグメントフォーマット

・送信元ポート番号

送信元のアプリケーションの使用するポート番号が挿入される．

・宛先ポート番号

送信先のアプリケーションの使用するポート番号が挿入される．

・シーケンス番号

送信するセグメントのデータ全体での位置を示す．データを送信する度に送信データのオクテット数だけ値が加算される．

・確認応答番号

次に受信すべきデータのシーケンス番号が挿入される．送信側は返された確認応答番号より前までは正常に受信されたと判断する．

・ヘッダ長

TCPヘッダの長さを示す（4bit）．

・予約ビット

将来の拡張のために予約されているフィールドである（4bit）．

・コントロールフラグ

CWR (Congestion Window Reduced)：ECNにより輻輳ウィンドウを小さくしたことを示す．

ECE (ECN-Echo)：通信相手にネットワークが輻輳していることを伝える．

URG (Urgent Flag)：緊急に処理すべきデータであることを示す．

ACK (Acknowledgement Flag)：確認応答番号フィールドが有効であることを示す．

PSH (Push Flag)：1の場合は受信データをすぐに上位層に渡さなければならない．

送信元ポート番号（16bit）宛先ポート番号（16bit）

シーケンス番号（32bit）

確認応答番号（32bit）

ヘッダ長予約 ^{コントロールフラグ} ウィンドウサイズ（16bit）

チェックサム（16bit）緊急ポインタ（16bit）

オプションパディング

データ

(11)

RST (Reset Flag)：1の場合はコネクションが強制的に切断される．

SYN (Synchronized Flag)：1の場合はコネクションの確立を要求する．

FIN (Fin Flag)：1の場合はコネクションの切断を要求する．

・ウィンドウサイズ

コネクション中に受信側がバッファに格納できるデータサイズを通知する．

・チェックサム

フレームが誤り検出に用いる．

・緊急ポインタ

コードビットのURGが1のときに有効で，データ領域の先頭から緊急ポインタで示している数値分までが緊急データとなる．

・オプション

TCPの通信で機能を追加するために用いられる．

2.2.1 非構造化ストリーム

非構造化ストリームとは，TCPが扱う構造を持たないデータのことである．TCPはデータを単なるビット列として見なし，送信者が送ったストリーム列をそのまま受信者に渡す．

データ構造の解釈は上位層が行う．またTCPは，コネクションの確立時に通信経路に合わせて理想的なセグメントサイズを決定し，送信するストリーム列をデータ構造によらず分割して送信する．

2.2.2 全二重通信

全二重通信とは双方向で行う通信において同時に双方からデータを送信や受信をすることができる通信方式である．対して半二重通信とはデータを送信している時には受信できず，受信しているときは送信できないような通信方式である．全二重通信は電話に，半二重通信はトランシーバーにたとえられることがある．主要データリンクであるEthernetにおいて同軸ケーブルを使う10BASE5，10BASE2は半二重通信を前提としていた．その後追加されたツイストペアケーブルを用いる10BASE-T や100BASE-TX，1000BASE-T などの規格では送受信で別々の線を持つため全二重通信を行うことができるようになった．

また光ファイバでは使用する信号の周波数を変えることで全二重通信を実現している．

2.2.3 コネクション管理

TCP はコネクション指向の通信を提供する．コネクション指向ではデータ通信に先立ち通信相手との間で通信を始める準備をしてから通信を行う．コネクションが確立されると通信を行うアプリケーションの間にバーチャルサーキットが形成され，アプリケーションは下位層を意識することなくバーチャルサーキットにデータを投入するだけで通信を行う

(12)

ことができる．

図2.4. TCPバーチャルサーキット

TCPではコネクションの確立のためにまずクライアントはコネクション確立要求（SYN）

フラグが設定されたパケットをサーバーに送信する．SYNを受け取ったサーバーはそれに対する確認応答（ACK）とクライアントに対するSYNを送信する．最後にクライアントがサーバーに対してACKを送信する．このようにコネクションの確立に3つのパケットがやりとりされるため3ウェイハンドシェイクと呼ばれる．

コネクションの切断時にはハーフクローズという方法が用いられる．TCP は全二重通信であるためにクライアントとサーバー間両方向にコネクションを持つためである．はじめに行われる切断をActive Close，もう片方の切断をPassive Closeという．クライアント側が切断要求（FIN）をサーバーに送ると，サーバーはACKを返信しそれをクライントが受信する．この時点で片方向のコネクションが解放されハーフクローズの状態になる．その後，サーバー側も送信データが無ければFINをクライアントに送信しクライアントがACK を返信する．クライアントはACKを送ると一定時間待機した後にコネクションを終了する．

その待ち時間はMSL(Max Segment Lifetime)の2倍となっている．

TCPバーチャルサーキット

アプリケーションアプリケーション

(13)

図2.5. コネクションの確立

図2.6. コネクションの切断

2.2.4 確認応答

2.2.4.1 確認応答の仕組み

TCPはシーケンス番号と確認応答番号（ACK）によって信頼性の高い通信が行われている．シーケンス番号はセグメントの順番を管理し，セグメントに抜けがないか確認するために用いられる．シーケンス番号はコネクションの確立時にランダムな値を初期値として設定され，その後は送信するデータのオクテット数を加算していく．受信側では受信したパケットのシーケンス番号とデータ長を調べ，つぎに受信すべき番号をACKパケットとして返送する．

Client Server FIN

ACK

Passive Close Active Close

FIN

TIME WAIT

CLOSED

ESTABLISHED ESTABLISHED

Client Server SYN

SYN ＋ ACK

ACK

(14)

図2.7. 確認応答の図

2.2.4.2 遅延確認応答

小さなデータを頻繁に送信する場合，受信側がそれぞれACKを返すとネットワーク中に多くのACK パケットが流れることになる．そのためパケットを受信した際，すぐにACK パケットを送信するのではなく一定の時間待機をする遅延ACKが一般的に実装されている．

待機する時間はRFCにより500ms以内，また待機している間に2つのフルサイズのセグメントが到着するとすぐにACKを送信することと規定されている．よって連続的なデータ送信をするとき，遅延ACKが実装されていない場合に比べACKパケットの数がおよそ半分になる．後述するTCPの輻輳制御においては ACKパケットを受信するたびに，輻輳ウィンドウを増加させる方式があり，その性能に影響を及ぼすことがある．

2.2.5 再送制御

2.2.5.1 再送制御の仕組み

TCP はデータを送信したホストは確認応答を待つ．確認応答が返ってくればデセグメントが正常に到着したことが分かる．そのため一定時間に確認応答が返ってこない場合はセグメントが失われたと判断して再度同じデータを送信する．データを送信してから再送を行うまでの待ち時間を再送タイムアウト値（RTO）と呼ぶ．RTOを短くすると，なんらかの原因でパケットが遅れた場合にタイムアウトと誤判定されることが多くなり，逆に長くすると実際にタイムアウトが生じた際に待ち時間が長くなってしまう．

Client Server

ACK

Seq:1000 ACK:2000 DataSize:1460

Seq:2000 ACK:2460 Seq:2000 ACK:2460 DataSize:1460 Seq:3460 ACK:2460 DataSize:1460 Seq:2460

ACK:4920

(15)

図2.8. 送信データパケットが喪失した場合図2.9.確認応答パケットが喪失した場合

2.2.5.2 再送タイムアウト値の決定方法

再送タイムアウト値を決定する際にはパラメータとして観測された RTT の値を用いる．

しかしネットワークの状態によって観測されるRTTの値は大きく変動する．そのため観測されるRTTを平滑化するために以下の式を用いる．

RTT SRTT

SRTT = α * + ( 1 − α ) *

（RTT は計測したRTT ，SRTT は平滑化されたRTT）

αは0 から1 の値を取る平滑化係数である．αの値によって，これまでの計測値の平均と新しく計測した値の重み付けをすることができる．αの値を 1 に近づけると，これまでの観測値の平均が重視され値が安定し，0 に近づけると変動に対しての反応が早くなる．

この平滑化されたRTT を用いて，再送タイムアウト値RTO は，以下の式より決定する．

SRTT RTO = β *

（βは1 以上の値をとる遅延分散係数）

βの値は一般的に2.0 が利用される．よって通常のRTTの平滑値の2倍がRTOの値として設定される．

2.2.5.3 高速再送制御方式

またTCPには高速再送制御と呼ばれるセグメント再送の効率を上げるための仕組みも導入されている．TCP は累積確認応答により確認応答を返すため，セグメントが失われた後に新たなセグメントを受信しても失われたセグメントを要求する確認応答を送信する．そ

Client Server

ACK

RTO

Client Server

ACK

RTO

ACK

(16)

のためセグメントが失われた場合は送信側に重複した確認応答が届くことになる．高速再送制御では重複した確認応答が 3 個以上届くとセグメントが失われたと判断して再送制御を行う．この方式でのセグメントロスの検出はRTOによる検出に比べ早期にできることから高速再送制御と呼ばれる．

図2.10. 高速再送制御

2.2.6 ウィンドウ制御

TCPで1セグメントごとに確認応答を行うとパケットのRTTが大きくなるにつれ通信性能が悪くなっていく．そのためウィンドウという概念が取り入れられており，確認応答なしでも連続してセグメントを送信することができる．また確認応答を待たずに送信できるデータの大きさをウィンドウサイズという．図2.10ではウィンドウサイズは3セグメント分に設定されており，確認応答なしで 3 セグメントを送信する．確認応答を受信したときには確認応答を受けた番号までウィンドウの枠をずらし，次のセグメントを送信する．このようなウィンドウをずらす送信制御をスライディングウィンドウ制御という．ウィンドウのサイズはフロー制御や輻輳制御によって決定される．

ACK Data

Client Server

1 2 3 4 5 6

1 2

2 2 2 7

2 2

7

(17)

図2.11. スライディングウィンドウ制御

2.2.7 フロー制御

ウィンドウ制御では確認応答なしに続けてデータパケットを送信する．受信側はバッファを用意し処理をするまでパケットを格納する．バッファからあふれたパケットは再送しなければならず効率が悪くなってしまう．そのためTCPでは受信ホストが送信ホストに対して受信可能なデータサイズを通知する仕組みになっている．この値は広告ウィンドウ

（Advertised Window:awnd）とよばれ，ACKパケットに書き込まれ送信側に伝えられる．

この広告ウィンドウの値が大きいほど高いスループットが得られることになる．

受信側ははじめに受信可能なバッファのサイズに広告ウィンドウの値を設定し，その後データを受信してバッファがあふれそうになると値を小さくして，送信側の送信を抑制する．このような処理をフロー制御という．

2.2.8 輻輳制御

TCP はウィンドウ制御により応答確認なしでパケットを連続送信することが可能である．

しかしネットワークの状態により大量のパケットが送信されると混雑が生じ，パケット到着までの遅延時間が大きくなったり，ネットワークのキャパシティを超える場合はパケットが廃棄されることがある．このような状態を輻輳といい，TCP はこのような輻輳を回避するための制御方式を持つ．TCP は 2.2.7 節で説明した広告ウィンドウの値の他に，送信側は輻輳ウィンドウ（Congestion Window:cwnd）と呼ばれる値を持つ．そして広告ウィンドウと輻輳ウィンドウの値を比較して小さい方の値をウィンドウサイズに決定する．よって輻輳ウィンドウの値を設定することで送信側のデータ送信量を調整することができる．

具体的な輻輳制御方式については第3章で詳説する．

6 5 4 3 2 1

1 2 3 4 5 6 7

Client Server

1 2 3 4 5 6 7

(18)

第 3 章 TCP の輻輳制御方式

3.1 輻輳制御

TCPの輻輳制御はスロースタートと輻輳回避の2つのフェーズから構成されている．

3.1.1 スロースタート

スロースタートフェーズはあたらに通信を開始するとき，または輻輳状態から再び通信量を増やそうとするときに利用する．スロースタートの開始時には輻輳ウィンドウを 1 にする．そして確認応答を受信するたびに1MSS（Maximum Segment Size）分の大きさずつ輻輳ウィンドウを増加させていく．増加前の輻輳ウィンドウの大きさをcwnd，増加後を cwndnew，最大セグメント長をMSSとすると以下の式のように表すことができる．

MSS cwnd

cwnd

_new

= +

図3.1. スロースタートフェーズ

図3.1のRTT1の期間はスロースタート開始直後であり，輻輳ウィンドウの値は1となる．そのためデータセグメントを1つ転送する．RTT2の期間はACKを1つ受信したため輻輳ウィンドウは 1 つ増加し 2 となるため 2 つのセグメントが送信される．同様にして RTT3の期間では2つのACKを受信したため輻輳ウィンドウは2つ増加し4と設定され，

結果4つのセグメントが送信される．

よってスロースタートフェーズでは，輻輳ウィンドウは1RTT で2倍となっていき指数関数的な増加をする．

3.1.2 輻輳回避

輻輳回避フェーズでは，ACK を受け取るごとに輻輳ウィンドウを MSS の”MSS/輻輳ウィンドウ”の分だけ増加させる．よってウィンドウサイズは ACK を受け取る度に以下の式のように増加する．

Client Server

RTT1 ACK RTT2

RTT3

Data

(19)

cwnd cwnd MSS

cwnd MSS MSS

cwnd cwnd

_new

2

+

=

× +

=

通常1RTTの間に受信するACKの数は”輻輳ウィンドウ/MSS”と表せるので，1RTTの間に増加する輻輳ウィンドウの大きさは1MSSである．

図3.2. 輻輳回避フェーズ

図3.2ではRTT1の輻輳ウィンドウサイズが2に設定されている．RTT2の期間にACK を受信すると輻輳ウィンドウを1/輻輳ウィンドウつまり1/2だけウィンドウを増加させる．

RTT2の期間には2つのACKを受信するために輻輳ウィンドウサイズは1増加し4となる．

同様にしてRTTごとにウィンドウサイズは1ずつ増加することが分かる．

3.1.3 フェーズの移行

TCP はスロースタート閾値（Ssthresh）という変数を持ち，輻輳ウィンドウの値がその閾値を超えるとスロースタートフェーズから輻輳回避フェーズに移行する．TCP はセグメントのロスを検出したときに輻輳ウィンドウを減少させ輻輳崩壊を避ける．そのときにロスを検出したときの輻輳ウィンドウの半分にスロースタート閾値を設定する．

3.2 Standard TCP

TCPの輻輳制御方式のうち標準的に用いられてきた方式で多くのOSに搭載されてきた．

3.2.1 TCP Tahoe[5]

TCP Tahoeは現在実装されているTCPの基になっている方式であり，スロースタートフ

ェーズ，輻輳回避フェーズから構成されている．スロースタートフェーズから転送を開始し，RTTごとに輻輳ウィンドウを2倍ずつ増加させていく．そしてネットワークの許容量を超えパケットのロスが起こるとロスを検出した輻輳ウィンドウの半分の値をスロースタート閾値に設定する．また輻輳ウィンドウの値は 1 に設定され，再びスロースタートフェ

Client Server

ACK RTT1

RTT2

RTT3

Data

(20)

ーズとなる．パケットのロスを検出した後はスロースタート閾値が設定されているために，

輻輳ウィンドウがスロースタート閾値に達すると，輻輳回避フェーズに移行する．このよ

うにTCP Tahoeは2つのフェーズを繰り返しながら通信を行う．

図3.3にTCP Tahoeの輻輳ウィンドウの変化を示す．

図3.3. TCP Tahoeの輻輳ウィンドウの変化

3.2.2 TCP Reno[1]

TCP Tahoeでは輻輳を検出すると，輻輳ウィンドウを1まで減少させ再びスロースター

トにより輻輳ウィンドウを回復していく．この手法は輻輳に対し保守的すぎる面があり，

転送性能の面から問題がある．そのためTCP RenoはTCP Tahoeの輻輳制御に改良を加えた高速リカバリアルゴリズムと呼ばれる機構を取り入れている．そのためTCP Renoではパケットロスを重複確認応答により検出し，高速再送制御が行われた場合は，タイムアウトによる再送に比べて軽微な輻輳状態であると判断し輻輳ウィンドウを 1 ではなくパケットロス検出時の半分に設定する．

図3.4にTCP Renoの輻輳ウィンドウの変化を示す．図3.3と比較すると高速再送制御が

行われた後はスロースタートフェーズに入らず，輻輳回避フェーズに移行しているのが分かる．このためパケット廃棄による転送効率の低下がTCP Tahoeに比べ小さくなる．

TCP RenoはMicrosoft社のWindowsXP以前のOSや従来のLinux系OSなどで標準的に採用されてきた．

Congestion Window

Time

Ssthresh

Slow Start Congestion Avoidance Slow Start

(21)

図3.4. TCP Renoの輻輳ウィンドウの変化

3.2.3 TCP NewReno[6]

TCP NewRenoではRenoで採用されている高速リカバリアルゴリズムを改良したアルゴ

リズムを使用している．重複確認応答により再送をする部分までは同じだが，再送をした後の制御に変更を加えている．Renoの場合，高速リカバリアルゴリズムでパケットを再送した後は，輻輳ウィンドウを半分にして輻輳回避フェーズに戻る制御になっているがパケットが連続して失われた場合，連続でロスしていると分かっているときでも再び重複確認応答を 3 回待ってから再送を行うことになる．またそのたびに輻輳ウィンドウは半分になるためスループットが低下する問題がある．そこでNewRenoでは重複確認応答を3回受け取るまでに送信したパケットの確認応答が返ってくるまでは再送モードを維持し続けるようになっている．

図3.5にこのアルゴリズムによる再送の様子を示す．この図ではデータ2とデータ 4をロスしている．まずデータ2をロスしているためACK1が重複して返り，送信側が3個の重複確認応答を受け取るとデータ2を再送する．またデータ 4もロスしているため次に返るのはACK3である．この重複確認応答を受信するまでにデータ6までを送信しているためデータ4もロスしていると判断し再送モードを維持して，データ4 をすぐに再送する．

その次に期待したACK6が返った後はRenoと同じ制御を行う．

このような処理により連続でパケットがロスしていても大幅なスループットの減少が起こらないようになっている．

現在はTCP NewRenoの改良をされたものもまとめて一般的にTCP Renoと呼ばれる．

Congestion Window

Time

Ssthresh

Slow Start Congestion Avoidance

(22)

図3.5. NewRenoでの再送制御

3.2.4 SACK[7]

これまでのTCPは累積確認応答方式によって，パケット廃棄が検出されたときに再送の制御を行う仕組みであった．そのため連続してパケット廃棄が起きていた場合，次のパケット廃棄を検出するには再送したパケットの確認応答を待たなければならない．つまり 1RTTに1つのパケット廃棄しか検出できないことになる．SACKとはTCP RenoにSACK

（Selective ACK）を加えたものであり，TCPヘッダのオプションフィールドに正しく受信できたパケットのシーケンス番号を格納することにより正しく受信できたパケットを選択的に送信者に知らせることができる．

SACKのヘッダを図3.6に示す．

図3.6. SACKのヘッダ第1ブロックの開始シーケンス番号第1ブロックの終了シーケンス番号

第ｎブロックの開始シーケンス番号オプションタイプ：5 長さ

第ｎブロックの終了シーケンス番号

Client Server

1 2 3 4 5 6

1

1 1 2

4

3

6 7

ACK Data

(23)

3.3 TCP Variants

近年のネットワークの高速・広帯域化にもなって標準TCPでは十分な帯域を利用することができない問題がある．これらを解決するために多くの輻輳制御方式が提案されてきた．

それらはLoss-based手法，Delay-based手法およびそれらを組み合わせたHybrid手法に大きく分けられる．

3.3.1 Loss-Based TCP

Loss-based手法はTCP Renoと同じくパケットロスを，輻輳を検出する指標とするもの

である．輻輳ウィンドウの増加方法や，ロスを検出した際の制御に変更を加えている．

3.3.1.1 TCP Westwood[8]

TCP WestwoodはTCPのACKの到着間隔を利用し推定したネットワークの利用可能帯

域推定を用いて，スロースタート閾値（ssthresh）を設定する手法である．TCP Renoがパケットロス時の高速リカバリアルゴリズムの後に，ssthreshを単純に半分にするのに対し，

推定した公平利用帯域（FSE）と観測した最小 RTT(RTTmin)を用いて以下のように設定する．

8 * _

*

_min

Size packet

RTT ssthresh = FSE

FSEの求め方にはバージョンにより複数あり，BSE（Bandwidth Share Estimation）は直近のACK到着間隔により帯域を推定する．これはパケットペア方式の計測となるためバースト的なトラヒックになりがちなTCPを用いた通信の場合大きめの値を推定してしまうことがある．よってBEに基づく制御をすると他のフローにフレンドリーでない制御になる．

RE（Rate Estimation）はパケットトレイン方式で計測を行い一定の時間内に観測された ACKの数により帯域を推定する．REはACK間のスペースにより値を小さめに見積もることがある．よってREに基づく制御では十分なスループットを得られないことになる．

3.3.1.2 BIC TCP[9]

BIC TCPはLinux Kernel 2.6.8から2.6.18までデフォルトで実装されてきた．図3.7に

BIC TCPの輻輳ウィンドウの変化を示す．BIC TCPは前回のパケットロス直前の輻輳ウィ

ンドウを記憶し，パケットロス後に減少した輻輳ウィンドウの値との間で二分探索を用いて輻輳ウィンドウを増加させる（Binary Searchモード）．ただし，減少後の輻輳ウィンドウが二分探索の基準点と大きく離れる場合は線形的増加させるAdditive Increaseモードを用いる．輻輳ウィンドウが増加し前回のパケットロス直前の値を超えた場合には，Binary Increase と Additive Increase モードと対称になるように輻輳ウィンドウを増加させる Max Probingモードとなる．

BIC TCPの利点として前回のパケットロスが発生したときの輻輳ウィンドウサイズ付近

に長く留まることで安定性を重視している点である．この凸型の増加方法は，一般的なTCP の凹型の増加方法でウィンドウサイズを増加しすぎて大量のパケットロスの発生しがちな

(24)

点を改良している．ただし，そのため利用可能な帯域幅が前回ロスしたときよりも大きくなっているとその値に達するまでの時間がかかってしまうトレードオフはある．

図3.7. BIC-TCPの輻輳ウィンドウの増加出典：［9］

3.3.1.3 CUBIC TCP[4]

CUBIC TCPはLinux kernel 2.6.19から現在までデフォルトで実装されている輻輳制御方式である．CUBIC TCPはBIC TCP（Binary Increase Control TCP）[6]を改良したものである．

BIC TCPとよく似た輻輳ウィンドウの制御を行うが，名前の通りパケットロスからの経

過時間の三乗（cubic）の関数を用いることで BIC TCP で必要だったモードの切り替えが不要である．CUBIC TCPでは輻輳ウィンドウサイズをパケットロスからの経過時間を利用して決定することからRTTが異なるフローが複数存在している時も，RTTに依存せずに輻輳ウィンドウを決定できるためRTT公平性が高いと言われている．

CUBICはACK受信時に以下の関数に従いウィンドウサイズを設定する．

3 _max

max _

)

3

( )

( C

K W W

K t C t

W

_last ^last

β

= +

−

= 　　

CはCUBICの定数，βはパケットロス時の減少幅，Wlast_maxは前回のパケットロス時の

輻輳ウィンドウサイズ，tは前回のパケットロスからの経過時間である．デフォルトでCの値は0.4，βは0.2に設定されている．

ロス時には以下のように減少幅βを用いて以下のように設定する．

) 1 (

* − β

= cwnd

cwnd

またロスを検出したときの輻輳ウィンドウサイズが前回ロスを検出した時の値より小さいときには輻輳が起こっていると判断し以下の式ように Wlast_max を変更する Fast

Convergenceモードを持つ．これにより三次関数の水平な部分の値が10％ほど減少し，そ

の結果余剰帯域が生まれることになりフローが競合するときに輻輳ウィンドウサイズが収

(25)

束していく．

2 / ) 2 (

max

*

_

= cwnd − β

W

_last

図 3.8 に CUBIC TCP の輻輳ウィンドウの変化を示す．輻輳ウィンドウサイズが

2000Kbyte に達するとバッファあふれによりパケット廃棄が発生して 20％減少し 1600Kbyteになる．この減少前の値がWlast_maxになり，次に増加するときの3次関数の水平部分となる．またロスが起こったときの2回に1回は3次関数の水平部分が10％減少して1800Kbyteになっている．これはFast Convergenceが有効になっているためであり，

元の2000Kbyteまで回復するのに約2倍の時間がかかっていることが分かる．

図3.8. CUBIC TCPの輻輳ウィンドウの変化

CUBIC TCPは輻輳ウィンドウサイズの制御がRTTに依存しない方式となっているため，

RTTが小さいネットワークなどではTCP Renoに比べ，輻輳ウィンドウの上げ幅が小さくなり Reno と公平に帯域を分け合うことができなくなってしまう．そのため CUBIC TCP

ではTCP Renoの輻輳ウィンドウサイズをモデル化した式で計算しWtcp(t)として保持する．

そして先ほどの W(t)と比較をして Wtcp(t)と比べ小さい場合は，TCP Mode となり Wtcp(t)を cwndとする．Wtcp(t)の計算式を以下に示す．

RTT W t

W

_tcp_t

β β β

+ −

−

=

_max

( 1 ) 3 2

) (

(26)

次にCUBIC TCPのコネクション同士が競合した場合の公平性について述べる．図の3.9

よりCUBIC TCPのフローが存在する場合に，別のCUBIC TCPのフローが競合し始める

と徐々に２フロー輻輳ウィンドウの大きさが収束し最終的にはほぼ同一のスループットが安定的に得られていることがわかる．ただし２つのフローが収束するまでの時間が比較的長いという課題もある．

図3.9. CUBIC TCPの２フローが競合する場合

(a) 輻輳ウィンドウの変化 (b)スループット出典：参考文献[4]

また図 3.10に RTT が比較的小さい場合(a)と大きい場合(b)それぞれで CUBIC TCPと

TCP Renoが競合したときの輻輳ウィンドウの変化を表した図を示す．RTTが小さい場合

では前述のTCP ModeとなりTCP Renoとの公平性を保っている一方でRTTが比較的大きい場合は公平性が低くなることがわかる．

図3.10. CUBIC TCPのフローとTCP Renoの競合時の輻輳ウィンドウの変化 (a) RTT：8msのとき (b)RTT：82msのとき出典：参考文献[4]

3.3.2 Delay-based TCP

Delay-based手法はRTTの変化により輻輳を検出するものであり，Loss-based手法に比べパケットロスが起こる前に輻輳を検知できるため単独で用いれば優れたスループット効率を持つ．しかしLoss-basedの手法のコネクションと競合した場合，Loss-based手法が輻輳ウィンドウをパケットロスが起こるまで増加させるのに対し，Delay-based 手法は RTT

(27)

の増加により自発的にレートを下げてしまう問題点がある．

3.3.2.1 TCP-Vegas[10]

TCP-Vegas はDelay-based手法であり，観測したRTTの値によりボトルネックのルー

タのキュー内パケット数(diff)を推定することによって輻輳ウィンドウを制御する．diff の値は以下のように求める．

rtt cwnd rtt

base diff = cwnd − 　 _

cwndは現在の輻輳ウィンドウサイズ，rttは現在のRTT，rttminは観測された最小のRTT である．RTTが最も小さいときがキューにパケットが無い状態で，RTTが大きくなるにつれキュー内パケットが増えていくと考えられる．

そして diff の値がある下限値を下回った場合，帯域が十分利用されていないと判断し輻輳ウィンドウを増加させる．また diff の値がある上限値を超えた場合は初期の輻輳が起こり始めていると判断して輻輳ウィンドウを減少させる．よって diff の値が上限値と下限値の間にある場合は適切に帯域が利用されていると判断し，輻輳ウィンドウは変化しないことになり，ネットワークで単独に用いられた場合Renoに比べて効率よく帯域を使用することができる．しかし前述したようにTCP RenoなどのLoss-based手法の輻輳制御方式との競合の状態ではTCP-VegasはRTTの増加により自発的にウィンドウを減少させてしまう．

以下にTCP-Vegasの輻輳ウィンドウ制御の式を示す．

：

⎪ ⎪

⎪

⎩

⎪ ⎪

⎪

⎨

⎧

<

−

<

+

=

rtt diff if base

cwnd

rtt diff base

rtt if base

cwnd

rtt diff base

if cwnd

cwnd

, _ 1

_ , _

, _ 1

β

β α

α Avoidance

Congestion

3.3.3 Hybrid TCP

Hybrid 手法は Loss-based 手法と Delay-based 手法の制御を組み合わせた方式であり

LossモードとDelayモードの両方の輻輳ウィンドウの値を保持し適応的な切り替えを行う．

3.3.3.1 Compound TCP（CTCP）[3]

CTCPはMicrosoft によって開発され，Microsoft社のWindows Vista以降のOSに実装されている輻輳制御方式である．CTCPではTCP Renoと同様の制御を行うLoss-basedの輻輳ウインドウ（cwnd）とTCP-Vegas と同様にキュー内パケット数の推定値diff によって制御されるDelay basedの輻輳ウインドウ（dwnd）の２つの変数を保持している．CTCP の輻輳ウインドウサイズ(win)は以下の式のように二つのウィンドウサイズの和となる．

(28)

dwnd cwnd

win= +

cwndは以下の式のように，1RTTに1パケットずつ増加する．

) /(

1 cwnd dwnd cwnd

cwnd = + +

dwndは以下の式のように決定される．γは推定したキューのパケット数から輻輳状態であるかどうか判断する閾値でありデフォルトでγ=30に設定される．kはTCPレスポンス関数の傾きを決定する定数であり，k=0.8の場合HSTCP［］と同等の増加率となる．しかし実装する場合の平方根の計算量を考慮してk=0.75に設定する．ζは輻輳を検出した場合にウィンドウを減少させる速度の定数でありζ=1と設定する．またウィンドウの増加率はα

=0.125，減少率はβ＝1/2，に設定される．

⎪⎩

⎪⎨

⎧

−

⋅

≥

⋅

−

<

−

⋅ +

= +

dected is

loss if ), 2 / )

1 ( ) ( (

if ), )

( (

if ), 1 ) ( (

) ( )

1 (

cwnd t

win

diff diff

t dwnd

diff t

win t

dwnd t

dwnd

k

β

γ ξ

γ α

以上の制御よりネットワークの帯域を十分に使い切っていない状態では dwnd が増加し輻輳ウィンドウを高速に増加させる．一方で帯域を十分使っている状況下では dwnd が減少して，従来手法との親和性を高める．

3.3.3.2 TCP-Fusion[11]

TCP-Fusionは2006年に本研究室で提案されたHybrid手法のTCP輻輳制御方式である．

TCP-Vegasと同様に3つのフェーズを持ち，それらは推定したボトルネックルータのキュ

ーパケットの数(diff)によって制御する．diffは以下のように求める．

RTT RTT cwnd RTT

diff ( − _min)

= 　

diffの値がある下限値より小さい場合は，まだ帯域は十分に利用されていないと判断し輻輳ウィンドウを高速に増加させる．diffの値がある上限値を超えた場合は，初期の輻輳状態であると判断し，キューの中に下限値分のパケットを保持するように輻輳ウィンドウを減少させていく．diffが上限値と下限値の間にある場合は回線を十分利用しつつ，キューイング時間も最小限に抑えられている理想的状態と判断し輻輳ウィンドウを一定に保つ．また

reno_cwndはTCP Renoと同様の制御をしている輻輳ウィンドウの値であり，もしFusion

の輻輳制御による輻輳ウィンドウの値がreno_cwndより小さい場合はreno_cwndを輻輳ウィンドウの値とすることで競合するTCP Renoに帯域を奪われるのを防ぐ．

以下にTCP-Fusionの輻輳ウィンドウ制御の式を示す．

(29)

cwnd reno

cwnd if cwnd reno

cwnd

otherwise cwnd

diff cwnd if

cwnd diff

diff cwnd if

cwnd W cwnd

inc

_ ,

_

,

* 3 ) ,

(

,

<

=

⎪ ⎪

⎪

⎩

⎪ ⎪

⎪

⎨

⎧

+ >

+ −

<

+

= α α

α

8 * _

min

* 8

* _

min

* ) / (

size packet

D RE size

packet D N B N

G = ≈

α =

なおパケットロス時には以下のような制御を行う．

2 ) ,

max( ^min _last ^last

new

cwnd cwnd RTT

cwnd = RTT

RTTmin/RTTはTCP-Westwood Rate Estimation[8]の減少率を採用であり，キュー内のパケットを排除する減少率となる．よってバッファの容量が帯域遅延積と同等に設定されているときにパケットロスが起こるとTCP Renoと等しく輻輳ウィンドウの値を半減させる．しかしバッファが帯域遅延積以上に設定されている場合はTCP Renoより輻輳ウィンドウの減少幅が大きくなってしまう．そのためTCP Renoと同等の1/2を閾値として設けることにより，TCP Renoとの競合時にレートが下がってしまうことを防ぐ．

図3.11にTCP-Fusionの輻輳ウィンドウの変化を示す．点線部がTCP Renoの輻輳ウィンドウの変化で，実線がTCP-Fusionの輻輳ウィンドウ変化である．Delay-based手法によって制御されている部分と，Loss-based 手法によって制御されている部分があり Hybrid手法であることが分かる．

2

max

/ cwnd

RTT cwnd

_max

RTT

^min

cwnd

max

Time

Congestion window

reno_cwnd cwnd

図3.11. TCP-Fusionの輻輳ウィンドウの変化出典：参考文献[11]

(30)

3.3.3.3 Hybrid RTT Fair TCP（HRF TCP）[12]

本研究室で2008年に提案されたHRF TCPは，TCP-Fusionに改善を加えRTT公平性を実現した手法である．RTT が異なる競合するフローと公平性を実現するために，

TCP-Libra[13]により提案された制御を導入している．

まずTCP-Libraの制御について説明をする．TCP RenoなどのAIMD型のプロトコルは以下のような式に従って送信レートを表すことができる[14]．αは AIMD 型のプロトコルにおける増加率，βは減少率，ρはパケットロス率である．

ρ ρ β

α −

= 1

1 * RTT R

この式に従うと送信レートがRTTに反比例し，RTTが大きいフローの方がレートが小さくなってしまうことがわかる．そこでTCP-Libraはαの値をRTT の2乗に比例させることで送信レートがRTTに依存せずに一定となる．

2 0

2

0 2

*

* k RTT

RTT RTT RTT

RTT

RTT ≈ =

= γ + γ

α

ρ ρ β

α

− = − = −

= 1

1 *

* * 1

*1

1 k RTT² k

RTT RTT

R

HRF TCPではこの制御をTCP-Fusionに取り入れることにより，送信レートがRTT依

存せずに一定となるような制御とする．以下にHRF TCP の輻輳ウィンドウの制御の式を示す．

) _ ,

( 1 _ *

,

* 3 ) ,

(

,

2 0

2

cwnd reno

cwnd max cwnd

RTT k

cwnd RTT cwnd k

reno

otherwise cwnd

diff cwnd if

cwnd diff

diff cwnd if

cwnd W cwnd

inc

=

= +

⎪ ⎪

⎪

⎩

⎪ ⎪

⎪

⎨

⎧

+ >

+ −

<

+

= α α

α

TCP-Fusionと比べLoss-Based手法となる部分のreno_cwndの増加幅がRTTの2乗に比例するようになっていることがわかる．またパケットロス時には TCP-Fusion と同様の制御を行う．RTT0は競合しているTCP RenoのRTTを推測した値となる．以下の式はパケットロスを検出した時のもので TCP-Fusion と同様にボトルネックのキュー内のパケッ

(31)

トを排除するまで，もしくはTCP Renoと同様の1/2のうち大きい方の割合だけ輻輳ウィンドウを減少させる．

⎟ ⎠

⎜ ⎞

⎝

= ⎛

, 2

min

cwnd

RTT cwnd max RTT

cwnd

また HRF TCPはパケットロスの特性に着目して，パケットロスを公平にする制御も行

っている．HRF TCPはRTT公平にするための制御を行うために，RTTが大きいフローが輻輳ウィンドウをよりアグレッシブに増加させている．つまりネットワークに余剰帯域がなくなりバッファリングが始まると，バッファリングされるパケットの数は輻輳ウィンドウの増加幅と同じになるためキューに入るパケットの割合が RTT が大きいフローに偏り，

結果としてパケットロスの回数も偏ることになる．バッファリングが起こった状態での無駄な輻輳ウィンドウの増加が問題となり，これを改善するために以下のような制御を行う．

20

2 1

*RTT k RTT

k

cwnd+= = ：there is residual capacity

0

* 1

k RTT RTT k

cwnd+ = ′ ′= ：there is no residual capacity

余剰帯域がなくなりバッファリングが開始された後は輻輳ウィンドウの増加幅がRTTによらず一定になるような制御となっている．

(32)

第 4 章提案手法

4.1 ネットワーク状況の推定

4.1.1 TCPとネットワーク状況の推定の必要性

インターネットは統一の管理団体があるわけではなく，世界中で一意な AS 番号

（Autonomous System number）を割り当てられた組織が相互に接続し合うことで成立しているネットワークである．またインターネットを含む現在のネットワークにおいて広く用いられているTCP/IPでは通信を行う端末が主体となって通信の制御を行い，原則としてネットワーク側での制御は行われない．そのためTCPが輻輳制御の機能を持ち，輻輳崩壊と呼ばれる輻輳状態が極度に悪化し通信効率が低下する状態を防ぐことが必要である．

ネットワークにおける端末が輻輳制御を行うためには，ネットワーク状況を知る必要がある．しかし前述したようにネットワーク側が直接的に輻輳状況を通知することは原則として無い．したがってTCPはネットワーク状況を推定して輻輳制御をしなければならない．

TCPは基本的な輻輳制御として，ACKの到着状況を用いて送信可能データ量である輻輳ウィンドウの増減や再送制御を行っている．またDelayed-basedの手法においてはRTTの値を基に輻輳ウィンドウの制御を行う．

4.1.2 ネットワーク状況推定の利用

TCP の輻輳制御において，ネットワーク状況をより詳細に把握することができれば，その情報を基に競合するコネクションに応じた制御を行うことができ公平性を高めることができると考えられる．ネットワーク状況の推定をするための情報は大きく分けて，端末が直接取得可能な情報とネットワークの中継ノードが計測可能な情報になる．

端末上のTCPが取得可能な情報としてはACKの到着状況，自コネクションの到着RTT の値，輻輳ウィンドウサイズ，ACKの到着間隔などがある．一方でネットワークの中継ノードが計測可能な情報は，中継ノードのリンク帯域，利用可能帯域，パケットロス率，各フローの帯域を占める割合など多岐にわたる．しかし，4.1.1項で述べたように現在のネットワークにおいて中継ノードから情報を得る機構は整備されておらず，情報をフィードバックするためのパケットや専用の装置が必要となる．そのため本稿では，端末上のTCPが直接取得可能な情報であるACKの到着間隔を利用して，競合しているコネクションの状態を推定することによりRTT公平な制御を行うことや競合している輻輳制御方式に対応した制御を行うことを提案する．

4.2 ACK の到着間隔を利用した競合コネクションの送信パケット数計測

ネットワークが輻輳状態にあるとき，ボトルネックとなるルーターのバッファにパケットが一時的に格納される．一般的なルーターのバッファはDroptail方式のバッファ管理方式をとっており，バッファにパケットを順次格納していき，バッファの容量を超えた場合

(33)

にパケットを廃棄する．またバッファからは出力先のネットワークの容量にあわせてパケットが一定の速度で出力される．

ボトルネックの帯域幅を 100Mbps，パケットサイズを1500byte とすると，ルーターのバッファから出力されるパケットの時間間隔は0.12msとなる．よってACKの到着間隔の最小値(Interval_min)を観測すると 0.12ms になると考えられる．ここで観測される ACK の到着間隔を到着間隔の最小値で割ると，そのACKの間隔にルーターのバッファから出力された総パケット数が推定できる．

ただしDelayed ACKが有効になっているときやACKパケットが廃棄されてしまった場

合，2つ以上のパケットに対して累積ACK(Cumulative ACK)を返している場合がある．そのため，到着間隔中の総パケット数から累積確認分のパケット数を引くことで競合フローのパケット数を正確に推定することができる．図4.1.はルーターのバッファから出力されるパケットの状態を示している．丸印のついているパケットはACKが返されるパケットである．図4.1. (a)の場合Delayed ACKが有効なため2パケットに対してACKが返されている状況を想定している．ここでACKの間隔が0.48msと観測され，累積ACKにより２パケットの累積確認がされているため競合するコネクションが 2 パケット送信していると考えられる．

0.36ms 0.48ms

pkt 2 12 2

. 0

48 .

0 − =

=

−cumulative_ack in

Interval_m Interval

(a)Delayed ACKが有効の場合

0.24ms 0.36ms

pkt 2 12 1 . 0

36 . _ack 0 cumulative in

Interval_m

Interval − = − =

(b)Delayed ACKが無効の場合

図4.1. ボトルネック部分のルーターから出力されるパケット

(34)

4.3 競合コネクションの RTT 推定

TCP RenoなどのAIMD型のプロトコルの送信レートは，輻輳ウィンドウの増加量α，

減少率β，パケットロス率ρを用いて以下のように表される[14]．

ρ ρ β

α −

= 1

1 * RTT R

よって，各パラメータが同一の場合に送信レートとRTTは反比例の関係になる．これより競合コネクションの送信パケット数を計測し，RTT推定を行うTCP Renoベースの TCP

（TCP RTT Estimation）との送信パケット数を比較することで競合コネクションのRTTを推定することができる．

競合するコネクションの推定RTTは，一定時間に計測されたTCP RTT Estimationの送信パケット数（The Number of Sending Packets），4.2項の手法を用いて計測した競合するコネクションの送信パケット数（The Number of Competing Packets）と，TCP RTT Estimation の観測された最小RTT（RTTmin）を用いて以下のように推定できる．

packets Competing

of Number The

Packets Sending

of Number RTT The

RTT

_estimate

_ _

min

×

=

例えばTCP RTT Estimationの送信パケット数（The Number of Sending Packets）が競合するコネクションの送信パケット数（The Number of Competing Packets）の2倍であれば，競合するコネクションのRTTはTCP RTT EstimationのRTTの2倍であると推定できる．

4.4 競合コネクションの輻輳ウィンドウの挙動推定

TCPにおける輻輳ウィンドウサイズとは送信端末がACKを待たずにネットワークに送信できるパケットの個数であり，1RTTに送信するパケット数と見なすことができる．

4.2項の手法を用いると競合コネクションが送信しているパケット数を計測することができ，一定時間間隔で区切って計測することで，一定時間間隔ごとの送信パケット数を計測することができる．一定時間間隔が競合するコネクションのRTT同等であれば，計測値は競合するコネクションの輻輳ウィンドウサイズと一致する．また実際の競合するコネクションのRTTよりも大きな値であれば，競合するコネクションの輻輳ウィンドウサイズより過剰に推定してしまうことになる．しかし，計測を区切る間隔が一定であれば本来の輻輳ウィンドウサイズから増減する割合は常に一定となるため，輻輳ウィンドウの挙動を推定することに支障はないと考えられる．

4.5 競合コネクションの輻輳制御方式識別

競合コネクションの輻輳制御方式の識別を行うために 4.4 項の輻輳ウィンドウの挙動推

ACK 到着間隔計測に基づく ネットワーク状況推定を利用した TCP 輻輳制御

平成 23 年度 修士論文