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方式のバッファ管理方 式をとっており，バッファにパケットを順次格納していき，バッファの容量を超えた場合
にパケットを廃棄する．またバッファからは出力先のネットワークの容量にあわせてパケ ットが一定の速度で出力される．
ボトルネックの帯域幅を 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. ボトルネック部分のルーターから出力されるパケット
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 項の輻輳ウィンドウの挙動推
定の結果を用いる．広く普及しているOSで用いられているTCP Reno，CTCP，CUBICに 用いられている輻輳ウィンドウの制御方式に着目するとTCP Reno，CTCP が導入している AIMD型と3次関数を用いたCUBICで挙動が区別される．AIMD型の制御では図3.4.で示 したように輻輳ウィンドウが一定の傾きでの増加と，減少を繰り返しているのに対し，図
3.8.にように CUBIC の動作は増減を細かく繰り返している．これらの特徴を基に両方式を
区別するために，輻輳ウィンドウの傾きに着目する．
得られた輻輳ウィンドウの値から最小二乗法を用いて傾きを計測する．AIMD型の制御方 式は傾きが一定で輻輳ウィンドウを増加させるため傾きが一定となる．一方でCUBICは増 加現象を不規則に繰り返すために，傾きが激しく変化する．そのため，傾きが一定時間に 一定の範囲内に収まるかどうかを調べることでAIMD型とCUBICを区別する．
4.6 RTT 公平な輻輳制御方式
HRF TCPにおいて競合するコネクションとのRTT公平性を実現するためには，競合
コネクションの推定RTTの値を求める必要がある．そのため4.3項を用いて競合コネクシ ョンのRTTを推定しHRF TCPにその結果を反映させる．3.3.3.3項で述べたHRF TCP において，ネットワークに輻輳が生じている際の輻輳ウィンドウの更新式は以下の通りで ある．
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 公平性を得るためには，RTT0に競 合するコネクションの RTT を代入する必要がある．従来，RTT0には何らかの方法で取得 した競合するコネクションのRTT の値を手動で入力する必要があった．ここでは，4.3 項 の手法によって取得した競合するコネクションの推定RTTの値を利用することで，自動的 に値を入力してRTT公平な制御を行う輻輳制御方式を提案する．
4.7 CUBIC TCP に親和性のある輻輳制御方式
TCP Renoに代わり新たに標準となりつつある輻輳制御方式として，Windows系OSで
はCTCPが，Linux系OSではCUBICが現在デフォルトで実装されている．CTCPがTCP
Reno に Delay-based 手法の制御を導入した Hybrid 手法の輻輳制御方式であるのに対し
CUBIC TCP は従来の方式に比べよりアグレッシブに輻輳ウィンドウを増加させ帯域を獲
得する高速TCPの一つである．そのためCTCPは輻輳時にはTCP Renoと同様の制御とな る一方，CUBICはTCP RenoやCTCPを抑圧してしまう．
よって，既存の手法にも親和性を持った状態でCUBICに対応した制御を行うことが必要 であると考えられる．そのため競合コネクションの輻輳制御方式がTCP Reno，CTCPで用