第 5 章 評価実験
5.1 CUBIC TCP，TCP-Fusion および HRF TCP の実装環境での性能評価
基礎的な実験として，実機環境においてTCP Reno，CUBIC TCP，TCP Fusion，HRF TCP の各種特性を比較する実験を行う．
5.1.2 実験環境
図5.1のネットワークトポロジを用いて評価を行う．Sender,Recieverの各マシンのスペ ックは表5.1の通りである．なおPacketStorm[15]はIPネットワークエミュレータであり，
IP ネットワーク上で起こる遅延，ジッタ，パケットロスなどの様々な障害を通過するパケ ットに与えることができるハードウェアである．ネットワークのトラヒックの送信には Iperf[16]を用いる．輻輳ウィンドウ（Cwnd）の値やスロースタート閾値（Ssthresh）など のTCPパラメータの観測，解析にはWeb100[17]のカーネルパッチを用いた．
図5.1.ネットワークトポロジ
表5.1：各マシンのスペック
Sender1 Sender2 Reciecer1 Reciecer2
CPU Intel
PentiumDualCore E2180 2.0GHz
Intel Pentium4 3.0GHz
Intel PentiumDualCore
E2180 2.0GHz
Intel Xeon3040 1.86GHz
Memory DDR2 SDRAM
2.0GB
DDR2 SDRAM 4.0GB
DDR2 SDRAM 2.0GB
DDR2 SDRAM 1.0GB NIC Broadcom
Corporation BCM5754
Broadcom Corporation
BCM5754
Intel 82572EI Broadcom Corporation
BCM5721 OS Fedora8
kernel2.6.22
Fedora8 kernel2.6.22
Fedora8 kernel2.6.22
Fedora8 kernel2.6.22
PacketStorm
Sender １ Receiver １
Sender2 Reciever2
100Mbps
100Mbps
100Mbps
100Mbps
5.1.3 パケットロス率がスループットに与える影響
はじめにTCP Reno，CUBIC TCP，TCP-Fusion，HRF TCPの各単独のフローでのスル ープットとロス率の影響を測定する．図5.1.のトポロジのもとSender1からReciever1に
向けてIperfによって100sのフローを流したときのスループットを各3回計測し平均する．
この実験では3つの環境を想定して行った．各環境でPacketStormに設定したパラメータ は以下の表5.2の通りである．設定1は遅延時間が短くバッファの大きさがBDP（帯域遅 延積）と同じ値である環境，設定2は，遅延時間が大きくバッファがBDPと同じ値の環境，
設定3は遅延時間が大きくバッファがBDPの10％だけである環境となっている．
表5.2：実験5.1.3.における実験パラメータ
図5.2. 設定1，遅延時間10ms，ボトルネック部分のバッファサイズがBDPの100％の
環境でのランダムロス率とスループットの関係 10ms
遅延時間（往復）
設定1 設定2
ボトルネックの帯域幅 ボトルネック部分のバ
ッファサイズ
設定3
100ms 100ms
100Mbps 100Mbps 100Mbps
BDPの100％ BDPの100％ BDPの10％
図5.3. 設定2，遅延時間100ms，ボトルネック部分のバッファサイズがBDPの100％の 環境でのランダムロス率とスループットの関係
図5.4. 設定3，遅延時間100ms，ボトルネック部分のバッファサイズがBDPの10％の 環境でのランダムロス率とスループットの関係
図5.2より比較的遅延時間が小さいネットワークにおいては傾向がLoss-based手法であ るTCP Reno，CUBIC TCPとHybrid手法を採用するTCP-Fusion，HRF TCPで分かれ る結果となった．これはHybrid手法がDelay-based手法で振る舞うモードを持つためにパ
ケットロスに対してロバストなためである．Loss-based手法のTCP RenoやCUBIC TCP はランダムロス率が高い環境でスループットを落としている．
図5.3の遅延が大きくバッファがBDPと同じだけ存在する場合のスループットは各方式 で差が見られる結果となった．この場合でもHybrid手法のほうがLoss-based手法よりも 高いスループットを得られる傾向は図5.2の場合と同じである．TCP Renoはランダムロス 率が小さい段階から十分にスループットが得られていないのに対し同じLoss-based手法の
CUBIC TCPはより高遅延・広帯域に対応しアグレッシブに輻輳ウィンドウを制御するため
により帯域を利用できている．HRF TCPが高いスループットを得ているのはHRF TCPは 高いRTTのときに輻輳ウィンドウの増加幅が大きくする制御とバッファリングされている ときに輻輳ウィンドウの上げ幅を小さくしパケットロスを抑える制御があるためと考えら れる．
図5.4はバッファの容量がBDPの10％と比較的小さい場合を想定したときの結果であり，
方式ごとに特徴が見られる．ランダムロス率が高い場合は図5.3の結果と近い傾向を示す．
一方，ランダムロス率が低い場合は特にTCP-FusionおよびTCP Renoでスループットが 一定レートで頭打ちになっている．これはバッファの容量が BDP の 10％と少なく十分に ウィンドウサイズを増加させられなかったことが原因と考えられる．
5.1.4 TCP Renoとの親和性
次にCUBIC TCPおよびTCP-Fusion，HRF TCPのTCP Reno対する親和性について実 験・評価する．この実験ではSender1からReciever1にTCP Renoのフローを，Sender2
からReciever2に各方式のフローを流しスループットを測定する．また比較としてCUBIC
TCPに対するTCP-FusionおよびHRF TCPのスループットも同様にして計測した．
この実験でも5.1.3と同じく設定1から設定3のパラメータで行い，それぞれIperfで100s のフローを流す．
表5.3：実験5.1.4.における実験パラメータ
10ms 遅延時間（往復）
設定1 設定2
ボトルネックの帯域幅 ボトルネック部分のバ
ッファサイズ
設定3
100ms 100ms
100Mbps 100Mbps 100Mbps
BDPの100％ BDPの100％ BDPの10％
(a) TCP RenoとCUBIC TCPの競合 (b) TCP RenoとTCP-Fusionの競合
(c) TCP RenoとHRF TCPの競合
(d)CUBIC TCPとTCP-Fusionの競合 (e)CUBIC TCPとHRF TCPの競合
図5.5. 設定1（遅延時間10ms），設定2（遅延時間100ms，バッファがBDPの100％），
設定3（遅延時間100ms，バッファがBDPの10％）のときの各方式のスループット
図5.5(a)よりCUBIC TCPは遅延時間が小さい場合は帯域をTCP Renoと公平に分け合 っているのに対し，遅延時間が大きい場合はTCP Renoとスループットに大きな差が出て いる．これはCUBICがRTTの小さいネットワークではTCP Modeで振る舞うためである．
一方，図5.5(a),(b)よりHybrid手法であるTCP-Fusion，HRF TCPは遅延時間が大きい ネットワークでもボトルネック部分のバッファが十分に存在している場合は比較的 TCP Renoとの公平性を保っていることが分かる．しかしHRF TCPは遅延時間10msのときに
TCP Renoに比べてスループットが小さくなっている．これはHRF TCPはRTT公平性を
実現するためにLoss-based手法の制御を行う際に輻輳ウィンドウの上げ幅をRTTの2乗 に比例させ，またその基準となる競合相手のRTTが40msとして実装されているためと考 えられる．