特別研究報告

題目

無線 LAN 環境における遅延に基づく輻輳制御を用いた TCP の性能評価

指導教員
中野 博隆 教授

報告者
橋本 匡史

平成 20 年 2 月 19 日

大阪大学 基礎工学部 情報科学科

平成 19 年度 特別研究報告

無線 LAN 環境における遅延に基づく輻輳制御を用いた TCP の性能評価
橋本 匡史

内容梗概
近年，インターネットが様々なネットワーク技術により大規模化・高速化するとともに，無線 LAN によるインターネットアクセスが一般化している．無線 LAN 規格には，無線伝送速度が最大 11 [Mbps] である IEEE 802.11b や無線伝送速度が最大 54 [Mbps] である IEEE

802.11a などが標準化され一般に利用されている．さらに，無線伝送速度が最大 300 [Mbps]
を越える IEEE 802.11n も標準化が進み，無線ネットワーク環境は今後も高速化される傾向にある．
一方，高速・高遅延ネットワークを対象に従来の TCP Reno に替わる TCP 改良手法が数多く提案されている．それらの提案手法の中には，TCP コネクションのラウンドトリップ時
間 (RTT) をネットワークの輻輳の指標として用いる手法 (delay-based 手法) がある．Delay-

based 手法はパケット廃棄の発生を指標として用いる手法に比べ，早期に輻輳を検出することにより高いスループットを得ることができる．しかし ，そのような手法は，無線ネット
ワークのような RTT がネットワークの輻輳とは関係なく変動する環境では正しく動作しな
いことが予想される．しかし，無線端末においてネットワーク環境に応じてトランスポート
層プロトコルを切り替えるのは現実的ではなく，無線ネットワーク環境が今後も高速化される傾向にあるため，delay-based 手法がそのまま利用される可能性が十分ある．また，無線

LAN は上りと下りでネットワーク帯域を共有するため，特に無線端末が TCP 送信側になる
場合には，アクセスポイントが輻輳を起こすことが考えられる．しかし ，この問題が TCPの性能に与える影響はこれまでほとんど 検証されていない．
そこで本報告では，無線 LAN 環境において，RTT をネットワークの輻輳の指標として用いる delay-based 手法の性能評価をシミュレーションによって行う．その結果，無線端末が送信側である場合において，無線端末のバッファにデータパケットが蓄積することや TCP 改
良手法が実装レベルで RTT 情報をフィルタリング処理することによって， RTT の変動の影響を抑えることができることを示す．また，無線アクセスポイントに ACK パケットが蓄積することが原因となり TCP コネクション間に深刻な不公平性が発生することを明らかに
する．

1

目次
1 はじめに

6

2 RTT を利用する TCP 改良手法

8

2.1

TCP Vegas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.2

FAST TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

2.3

Compound TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

2.4

TCP-Adaptive Reno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.5

CUBIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 シミュレーション評価

12

3.1 ボトルネックが無線区間にある場合 . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.1

シミュレーション環境 . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1.2

シミュレーション結果と考察. . . . . . . . . . . . . . . . . . . . . . 16

3.2 ボトルネックが有線区間にある場合 . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.1

シミュレーション環境 . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.2.2

シミュレーション結果と考察. . . . . . . . . . . . . . . . . . . . . . 38

4 まとめと今後の課題

45

謝辞

46

参考文献

47

2

図目次
1

IEEE 802.11b を用いた場合のボトルネックが無線区間にあるネットワークモ
デル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2IEEE 802.11a を用いた場合のボトルネックが無線区間にあるネットワークモ
デル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3

無線アクセスポイントにおけるキュー長の変化およびパケット廃棄数の変化(TCP Vegas，伝搬遅延: 200 [msec]) . . . . . . . . . . . . . . . . . . . . . . . 17
4

無線アクセスポイントにおけるキュー長の変化およびパケット廃棄数の変化(AReno，伝搬遅延: 200 [msec]) . . . . . . . . . . . . . . . . . . . . . . . . . 18
5

無線アクセスポイントにおけるキュー長の変化およびパケット廃棄数の変化(CUBIC，伝搬遅延: 200 [msec]) . . . . . . . . . . . . . . . . . . . . . . . . . 19
6無線区間にボトルネックがある場合の無線区間の遅延変動 (AReno，伝搬遅
延: 100 [msec])

7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

無線区間にボトルネックがある場合の無線区間に送出されるパケットの総数の変化 (AReno，伝送遅延: 100 [msec]) . . . . . . . . . . . . . . . . . . . . . 228無線区間にボトルネックがある場合の無線アクセスポイントにおけるキュー
長の変化およびパケット廃棄数の変化 (AReno，伝送遅延: 100 [msec]) . . . . 23

9無線区間にボトルネックがあるネットワークにおけるシミュレーション結果(TCP Vegas, コネクション数: 2，伝搬遅延: 200 [msec])
10

無線区間にボトルネックがあるネットワークにおけるシミュレーション結果(FAST TCP, コネクション数: 2，伝搬遅延: 200 [msec])
11. . . . . . . . . . . . 25
. . . . . . . . . . . . 26

無線区間にボトルネックがあるネットワークにおけるシミュレーション結果(CTCP, コネクション数: 2，伝搬遅延: 200 [msec]) . . . . . . . . . . . . . . . 27
12無線区間にボトルネックがあるネットワークにおけるシミュレーション結果(AReno, コネクション数: 2，伝搬遅延: 200 [msec])
13. . . . . . . . . . . . . . 28

無線区間にボトルネックがあるネットワークにおけるシミュレーション結果(CUBIC, コネクション数: 2，伝搬遅延: 200 [msec]) . . . . . . . . . . . . . . 28
14

不公平が発生する場合の正常なコネクションのシミュレーション結果 (AReno，コネクション数: 16，伝搬遅延: 200 [msec]) . . . . . . . . . . . . . . . . . . . 32

15

不公平が発生する場合の正常なコネクションのシミュレーション結果 (CUBIC，
コネクション数: 16，伝搬遅延: 200 [msec]) . . . . . . . . . . . . . . . . . . . 33

16

不公平が発生する場合の問題のあるコネクションのシミュレーション結果(AReno，コネクション数: 16，伝搬遅延: 200 [msec])

3. . . . . . . . . . . . . 34

17

不公平が発生する場合の問題のあるコネクションのシミュレーション結果(CUBIC，コネクション数: 16，伝搬遅延: 200 [msec]) . . . . . . . . . . . . . 35
18IEEE 802.11a を用いた場合のボトルネックが有線区間にあるネットワークモ
デル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

19

有線区間にボトルネックがある場合の無線区間の遅延変動 (AReno，伝搬遅
延: 100 [msec])

20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

有線区間にボトルネックがある場合の無線区間に送出されるパケットの総数の変化 (AReno，伝送遅延: 100 [msec]) . . . . . . . . . . . . . . . . . . . . . 41

21IEEE 802.11a を用いた場合におけるシミュレーション結果 (CTCP，コネク
ション数: 1，伝搬遅延: 50 [msec]) . . . . . . . . . . . . . . . . . . . . . . . . 43

22IEEE 802.11a を用いた場合におけるシミュレーション結果 (AReno，コネク
ション数: 1，伝搬遅延: 50 [msec]) . . . . . . . . . . . . . . . . . . . . . . . . 44

4

表目次
1

IEEE 802.11b における設定パラメータ . . . . . . . . . . . . . . . . . . . . . 13

2IEEE 802.11a における設定パラメータ5. . . . . . . . . . . . . . . . . . . . . 13

1 はじめに近年のネットワークの高速化にともない，Transmission Control Protocol (TCP) [1] の利用できるネットワークの帯域遅延積が増大している．この高速・高遅延ネットワークにおいて，従来の TCP として一般に利用されている TCP Reno は，その輻輳制御方式が原因となり，十分なスループットが得られないことが知られている [2]．TCP Reno は輻輳ウィンド ウサイズの増加幅がラウンドトリップ時間 (RTT) ごとに 1 パケットと小さいにもかかわらず，パケッ
ト廃棄を検出した際の輻輳ウィンド ウサイズの減少幅が輻輳ウィンド ウの 1/2 以上と大きい
ため，帯域遅延積の大きい高速・高遅延ネットワークでは輻輳ウィンド ウサイズが十分に大きくならない．さらに，帯域遅延積の大きなネットワークのリンク帯域を十分使うためには非常に低いパケット廃棄率である必要がある．このため，高速・高遅延ネットワークにおいて TCP Reno は十分なスループットを得ることができない．
この問題に対して，さまざまな TCP 改良手法の提案が行われている [2–7] ．それらの TCP 改
良手法はネットワークの輻輳の指標としてパケット廃棄の発生を用いる loss-based 手法，ネッ
トワークの輻輳の指標として RTT を用いる delay-based 手法，およびそれらを組み合わせた手法の 3 つに大別される [8]．Loss-based 手法に分類される TCP 改良手法としては High-

Speed TCP [2] や Scalable TCP [7] などがある．また，delay-based 手法に分類される TCP 改良
手法には TCP Vegas [9] や FAST TCP [3] などが挙げられる．Loss-based 手法と delay-based 手法を組み合わせた手法に分類される TCP 改良手法には Compound TCP (CTCP) [4] や TCP-

Adaptive Reno (AReno) [5] などがある．これらの多くは主に有線ネットワークを対象に検証されている [10]．
一方，無線ネットワーク技術の向上により，ノート PC や携帯電話などの端末が無線 LAN や
無線 WAN などを通してインターネットにアクセスすることが一般的となってきている．無線 LAN 規格として，IEEE によって標準化された IEEE 802.11b [11] や IEEE 802.11a [12] などがある．無線伝送速度は，IEEE 802.11b の場合は最大 11 [Mbps] であり，IEEE 802.11a の場合は最大 54 [Mbps] である．さらに，近年標準化が進んでいる IEEE 802.11n では無線伝送速度が最大 300 [Mbps] を越えるなど，さらなる高速化が行われている．それらの無線 LAN 規
格ではアクセス制御方式に CSMA/CA を用いている．CSMA/CA は，搬送波を検出するランダムな時間であるバックオフ時間の間，フレームの送信を待ち，通信中の端末が存在しないことを確認することによって，フレームの衝突をできるだけ避けようと試みるプロトコルである．このことが無線 LAN において伝送遅延時間が変動する一つの要因である．
無線ネットワークは有線ネットワークに比べ，インフラ整備が簡単である反面，通信の信頼性が低いことや遅延ジッタが大きいことが問題となっている．このような無線ネットワー
ク環境において，TCP を利用すると，その輻輳制御方式の特徴により，リンクエラーによる6パケット廃棄をネットワークの輻輳として認識してしまうという問題がある [13]．この問題に対しても，さまざ まな TCP 改良手法が提案されている [14, 15]．しかし，無線 LAN 環境における遅延ジッタが TCP の輻輳制御に与える影響については，ほとんど 検証されておらず，前述の高速・高遅延ネットワークのための TCP 改良手法の多くに対しても，検証は行
われていない．これは，delay-based 手法が比較的新しい TCP 改良手法であり，高速・高遅延ネットワークを対象に考案されているためだと考えられる．
ネットワークの輻輳の指標として RTT を用いる delay-based 手法のような TCP 改良手法
においては，輻輳に関係なく RTT が変動すると，ネットワークの輻輳状態を正しく得ることができないことが予想される．しかし ，無線端末においてネットワーク環境によってト
ランスポート層プロトコルを切り替えるのは現実的ではない．さらに，無線ネットワーク
環境は今後も高速化される傾向にあるため，高速・高遅延ネットワーク向けの delay-based手法がそのまま利用されることは十分考えられる．したがって，無線 LAN 環境において，delay-based 手法の評価を行うことは重要である．
また，無線 LAN は上りと下りでネットワーク帯域を共有するため，特に無線端末が TCP
送信側になる場合には，アクセスポイントが輻輳を起こすことが考えられる．しかし，この問題が TCP の性能に与える影響は検証されていない．
そこで本報告では，無線 LAN 環境において，ネットワークの輻輳の指標として RTT を用いる delay-based 手法の性能評価をシミュレーションによって行う．無線 LAN 規格として IEEE 802.11b および IEEE 802.11a を利用し，ボトルネックリンクが無線区間にある場合と有線区間にある場合の両方について，ns-2 [16] を用いてシミュレーションを行った結果を示す．シミュレーション結果から，無線端末が送信側であるようなネットワーク環境では，無線端末のバッファにパケットが蓄積することや各 TCP 改良手法が実装レベルで実装している，RTT 情報のフィルタリング処理によって，無線 LAN の遅延変動の影響を抑えることができることを示す．さらに，無線端末が送信側となった場合に，無線アクセスポイントに ACK パケットが蓄積されることによって，TCP コネクション間の公平性に深刻な問題が引き起こされることを述べる．
以下，2 章では輻輳制御に RTT を用いる loss-based 手法や delay-based 手法，およびそれらを組み合わせた手法の輻輳制御方式，および観測した RTT の輻輳制御への利用の仕方について簡単に述べる．3 章においては，ボトルネックリンクが無線区間にある場合および有線区間にある場合のそれぞれについてシミュレーションを行った結果を示し，無線 LAN 環
境がさまざ まな TCP 改良手法に与える影響について考察する．最後に，4 章で本報告のまとめと今後の課題について述べる．

7

2 RTT を利用する TCP 改良手法
本章では，RTT を利用する TCP 改良手法の輻輳制御方式のうち，輻輳ウィンド ウサイズの更新アルゴ リズムについて述べる．また，観測した RTT が輻輳ウィンド ウサイズの更新
アルゴ リズムにどのように利用されるかについても述べる．本報告では delay-based 手法として TCP Vegas および FAST TCP，loss-based 手法と delay-based 手法を組み合わせた手法
として CTCP および AReno，そして，loss-based 手法として CUBIC を取り上げる．
どの delay-based 手法においても，方式が提案されている論文などにおいて，輻輳ウィン
ド ウの更新に RTT が利用されることは記述されている．しかし，RTT をどのように計測および統計処理を行い，輻輳ウィンド ウの更新がどのような間隔で行われるかについてはほとんど 記述されていない．このため，本報告では Linux 上の実装コード (kernel 2.6.22) およびシミュレーションソフトウェアである ns-2 のシミュレーションコードから，各 TCP 改良手法における RTT 情報の利用方法を推定する．

2.1 TCP Vegas [9]TCP Vegas は高速・高遅延向けの TCP 改良手法ではないが，多くの delay-based 手法の基本となる輻輳ウィンド ウ更新アルゴ リズムを使用している．TCP Vegas は以下の式によって，ネットワーク上に蓄積されているパケット数を推測する．

Dif f= (Expected − Actual) · baseRT T

Expected = cwnd/baseRT T
Actual = cwnd/RT T(1)

なお，cwnd は輻輳ウィンドウサイズ，baseRT T は今までに観測された最小の RTT，Dif f はネットワーク上に蓄積されているパケット数の推定値，RT T は最新の RTT の値である．ここで，式 (1) で利用している RT T をど う設定するかは，[9] には明記されておらず，Linux
実装においてはラウンドトリップ時間で計測された最小の RTT を minRT T とし，式 (1) のRT T として用いている．TCP Vegas は Dif f の値に基づき，以下の式にしたがって輻輳ウィ
ンド ウサイズを RTT に 1 度増減させる．

 cwnd + 1 (Dif f < αv )cwnd ←
cwnd(αv ≤ Dif f ≤ βv )cwnd − 1 (Dif f > βv )8(2)

ここで，αv と βv は制御パラメータである．式 (2) は，TCP Vegas がボトルネックリンクに蓄積されているパケット数が αv 以上 βv 以下になるように輻輳ウィンド ウサイズを制御することを意味する．

2.2 FAST TCP [3]FAST TCP は TCP Vegas と同様に，今までに観測された最小の RTT である baseRT T を用いて，以下の式にしたがって輻輳ウィンド ウサイズの増減を RTT に 1 回行う．

{()}
baseRT T
cwnd ← min 2cwnd, (1 − γf ) cwnd + γf
cwnd + αf
avgRT T(3)

ここで，avgRT T は以下の式のように輻輳ウィンド ウサイズの 3 分の 1 の重みで指数移動平均化された RTT である．なお，avgRT T は [3] においては明確に指定されておらず，ns-2のシミュレーションコード [17] においては以下の式のように定義されている．

avgRT T= ((cwnd/3 − 1) · avgRT T + RT T ) / (cwnd/3)(4)

ここで，RT T は観測された現在の RTT である．FAST TCP はネットワークの帯域遅延積が大きい場合でもすばやく輻輳ウィンド ウを増加することができるため，TCP Vegas に比べ
ネットワークの利用率を向上できる．

2.3 Compound TCP (CTCP) [4]
TCP Vegas や FAST TCP のような純粋な delay-based 手法は，TCP Reno など の lossbased 手法と混在するネットワーク環境において， loss-based 手法に比べてスループットが低下するという問題がある [18]．この問題に対して，loss-based 手法が混在する環境においても，loss-based 手法との公平性を保ちながらネットワーク帯域を有効に利用することができる手法として，loss-based 手法と delay-based 手法を組み合わせた手法が提案されている．

CTCP は loss-based 手法と delay-based 手法を組み合わせた手法の 1 つである．CTCP は
TCP Vegas と同様に以下の式により，ネットワーク上に蓄積されているパケット数を推測
する．

Dif f

= (Expected − Actual)·baseRT T

Expected = cwnd/baseRT T
Actual = cwnd/RT T

9(5)ここで，baseRT T はいままで観測された最小の RTT，Dif f はネットワーク上で蓄積されているパケット数の推定値，RT T は最新の RTT の値である．なお，式 (5) で利用している

RT T をど う設定するかは [4] には明記されておらず，Linux における実装ではラウンドトリッ
プ時間で計測された最小の RTT を minRT T とし ，式 (5) の RT T として用いている [19]．

CTCP は Dif f の値に基づき，以下の式にしたがって輻輳ウィンド ウサイズを RTT に 1 度増減させる．

cwnd ← cwndreno + dwnd

 dwnd + max(α ·cwndk − 1, 0) (Dif f < γ )ccdwnd ←
 max(dwnd − ζc ·Dif f, 0)(Dif f ≥ γc )(6)

ここで，cwndreno は TCP Reno の場合の輻輳ウィンド ウサイズ，dwnd は遅延ウィンド ウサ
イズ，αc ，ζc および γc は制御パラメータである．CTCP は式 (6) により，ネットワーク帯域が使いきれていないと判断した場合は，ネットワークに蓄積されているパケット数が γc 程度になるように輻輳ウィンド ウサイズを増加させ制御する．さらに，ネットワーク帯域が使い切られ輻輳が発生した状態になると，dwnd が 0 になり，最終的に輻輳ウィンド ウサイズの増加速度が TCP Reno と同じになる．

2.4 TCP-Adaptive Reno (AReno) [5]AReno は CTCP と同様に loss-based 手法と delay-based 手法を組み合わせた手法である．
AReno の CTCP との相違点は，CTCP が輻輳ウィンド ウサイズの増減幅を現在の輻輳ウィ
ンド ウサイズによって決定するのに対し ，AReno はボトルネックリンクのリンク帯域を推定し，それを用いて輻輳ウィンド ウサイズの増減幅を決定する点である．

AReno は以下の式によってネットワークの輻輳レベルを推定する．
()
sRT T − RT Tminc = min, 1
RT Tcong − RT Tmin
RT Tcong = (1 − a)RT Tcong + aRT T(7)

ここで，c はネットワークの輻輳レベル，RT Tmin はいままで観測された最小の RTT，RT Tcong は
式 (8) により求められるパケット廃棄が発生する直前の RTT，sRT T は smoothed RTT である．なお，[5] では式 (7) において使用される RT T の詳細が明確に指定されておらず，Linux 実装では RT T として通常の TCP が管理している平滑化 RTT である sRT T を利用している．

AReno は c の値に基づき，以下の式にしたがって輻輳ウィンド ウサイズの増減を ACK パ

10

ケットを受信するごとに行う．

cwnd ← wbase + wprobe
wbase ← wbase + 1 M SS/cwnd(8)wprobe ← max(wprobe + Winc /cwnd, 0)(9)Winc (c)=max αa cWinc/e+ βa c + γa

max
Winc

=

B/M ·M SS

βa

=

max
2Winc
(1/αa − (1/αa + 1)/eαa )

γa

=

max
1 − 2Winc(1/αa − (1/αa + 1/2)/eαa )ここで，M SS は最大セグ メントサイズ，B は TCP Westwood [14] と同様に ACK の到着間隔から求められるボトルネックリンク帯域の推定値，M はスケーリング係数である．また，
式 (8) は TCP Reno に相当するウィンド ウサイズであり，式 (9) は delay-based 手法に相当す
るウィンド ウサイズである．AReno は c によりネットワーク帯域が使い切れていないと判断すれば wprobe の増加量を大きくし，ネットワーク帯域を使い切るように動作する．さらに，

c に連動して wprobe を変化させることにより輻輳ウィンド ウを一定に保つように動作し，最終的には TCP Reno と輻輳ウィンド ウサイズの増加速度が同じになる．

2.5 CUBIC [6]
CUBIC はパケット廃棄が発生してからの経過時間を用いて，以下の式にしたがって輻輳
ウィンド ウサイズを RTT とは独立な一定時間ごとに 1 回更新する．

√
cwnd ← C(t − 3 Wmax βcubic /C)3 + Wmax

(10)

ここで，C はスケーリング係数，t はパケット廃棄が発生してからの経過時間，βcubic は倍数減少係数，Wmax はパケット廃棄が発生する直前の輻輳ウィンド ウサイズである．CUBIC は式 (10) のように上述の TCP 改良手法とは異なり，輻輳ウィンド ウサイズの更新間隔や増減
量が RTT に依存しない．このため，RTT が変動しても輻輳ウィンド ウサイズの増減に影響
がない．

11

3 シミュレーション評価
本章では，ns-2 [16] を用いて，2 章で紹介した，純粋な delay-based 手法である TCP Vegas
および FAST TCP，loss-based 手法と delay-based 手法を組み合わせた手法である CTCP お
よび AReno，および loss-based 手法である CUBIC を用いて無線端末が TCP の送信側である場合のシミュレーションを行い，無線 LAN 環境におけるそれらの手法の性能について考察する．
シミュレーションにおいて用いる無線 LAN 規格は，IEEE 802.11b および IEEE 802.11a である．それぞれのパラメータを表 1 および表 2 に示す．

TCP Vegas，CTCP，AReno，および CUBIC は NS-2 TCP-Linux [20] を用いることにより，Linux 上の実装コードを ns-2 上で実行できるように変換を行い，シミュレーションを行った．
FAST TCP については，公開されているシミュレーションモジュール [17] を用いた．

3.1 ボト ルネックが無線区間にある場合
本節では，ボトルネックが無線区間にあるネットワーク環境においてシミュレーションを行い，無線 LAN 環境がボトルネックとなる場合の各 TCP 改良手法への影響について考察を行う．

3.1.1 シミュレーション環境
無線 LAN 規格として IEEE 802.11b を使用し，ボトルネックが無線区間にあるネットワー
クモデルを図 1 に示す．複数の無線端末が送信側 TCP として 1 つの無線アクセスポイントを共有し，無線アクセスポイントから受信端末までは有線リンクにより接続されている．無線端末から無線アクセスポイントまでは IEEE 802.11b を利用しているため，無線伝送速度は最大 11 [Mbps] の無線リンクである．また，無線アクセスポイントと受信端末までは，帯域が 100 [Mbps] であり，片道伝搬遅延が 200 [msec] の有線リンクで接続されている．このため，このネットワーク環境では無線端末から無線アクセスポイントまでの無線区間がボト
ルネックとなる．また，無線アクセスポイントのバッファサイズを 100 [pkts] に設定し，無線アクセスポイントから受信端末までの有線リンクにおけるバッファサイズは十分大きな値に設定した．無線端末の送信バッファについても，無線 LAN 環境に影響を与えないように十分大きな値に設定した．なお，無線アクセスポイントから受信端末までの有線リンクのバッファには，キュー管理機構として DropTail を用いた．
また，無線 LAN 規格として IEEE 802.11a を使用し，ボトルネックが無線区間にあるネッ
トワークモデルを図 2 に示す．図 2 は図 1 において，無線 LAN 規格を IEEE 802.11b から

12

表 1: IEEE 802.11b における設定パラメータ
項目

値

伝送速度

11 [Mbps]
144 [µs]
48 [bit]
20 [µs]10 [µs]50 [µs]31
1023

プリアンブル長

PLCP ヘッダ長
スロットタイム
SIFS
DIFS
CWmin
CWmax

表 2: IEEE 802.11a における設定パラメータ
項目

値

伝送速度

54 [Mbps]
16 [µs]
4 [µs]
9 [µs]
16 [µs]34 [µs]151023

プリアンブル長

PLCP ヘッダ長
スロットタイム
SIFS
DIFS
CWmin
CWmax

13

Wireless Node
（Number of Nodes: 1-32）(Sender)

Wired Node
(Receiver)

100 Mbps, 200 msec

802.11b(11 Mbps)
Access Point

図 1: IEEE 802.11b を用いた場合のボトルネックが無線区間にあるネットワークモデル

Wireless Node
（Number of Nodes: 1-32）(Sender)

Wired Node
(Receiver)

100 Mbps, 100 msec

802.11a(54 Mbps)
Access Point

図 2: IEEE 802.11a を用いた場合のボトルネックが無線区間にあるネットワークモデル

14

IEEE 802.11a に変更し，片道の伝搬遅延を 100 [msec] に変更したネットワーク環境である．
さらに，無線アクセスポイントのバッファサイズを 500 [pkts] に変更している．
シミュレーションは図 1 および図 2 のネットワーク環境において，無線端末数を 1 台から

32 台まで変化させ，各無線端末から上り方向の TCP コネクションを無線端末 1 台につき 1本生成することにより行う．つまり，無線端末数が 2 台であるとき，TCP コネクション数は合計で 2 本である．TCP には，TCP Vegas，FAST TCP，CTCP，AReno，および CUBIC を用いて，それぞれの場合について各無線端末の TCP に同一の TCP 改良手法を設定した．各TCP コネクションはシミュレーション開始後，0.01 秒間隔で，データ転送を開始した．各無線端末は生成した TCP コネクションを用いて，アプリケーション層プロトコルとして FTPを用いて，無限大のサイズを持つデータ転送を行う．データパケットのサイズは 1500 [pkts]に設定している．
また，各 TCP 改良手法のパラメータは，それぞれ以下のように設定した．

TCP Vegas αv = 2, βv = 4
FAST TCP αf = 20, γf = 0.5
CTCP αc = 0.125, γc = 30, ζc = 1
AReno αa = 16, βa = 1, γa = 10
CUBIC 設定項目なし

15

3.1.2 シミュレーション結果と考察
図 1 のネットワークモデルにおいて，コネクション数を 1 から 8 まで増やした場合の無線
アクセスポイントのバッファサイズの変化，および無線アクセスポイントにおけるバッファ
溢れによるパケット廃棄数の変化を，TCP Vegas の場合を図 3 に， AReno の場合を図 4 に，

CUBIC の場合を図 5 にそれぞれ示す． なお，図 3-5 中の q data は無線アクセスポイントのバッファに蓄積されているデータパケットの数，q ack は無線アクセスポイントのバッファに蓄積されている ACK パケットの数，drop ack は無線アクセスポイントのバッファ溢れによって発生したパケット廃棄の数である．
図 3 から図 5 をみると，無線アクセスポイントのバッファにデータパケットではなく ACK
パケットが蓄積されていることがわかる．また，コネクション数が増加すると，ど の TCP
改良手法においても，無線アクセスポイントに蓄積される ACK パケット数が増加している
ことがわかる．しかし ，図 3 から TCP Vegas の場合は，無線アクセスポイントに蓄積される ACK パケットがコネクション数によってほぼ一定の値になり，ACK パケットの廃棄は発生していない．これは，無線アクセスポイントに ACK パケットが蓄積されることによってRTT が増加するため，delay-based 手法 である TCP Vegas は輻輳ウィンド ウサイズを制御するためだと考えられる．また，図 5 より，loss-based 手法である CUBIC では，コネクション
数が増えると 無線アクセスポイントにおいて ACK パケットの廃棄が発生していることがわ
かる．図 4(c) より，loss-based 手法と delay-based 手法を組み合わせた手法である AReno は，delay-based 手法で動作している 20 秒までは無線アクセスポイントに蓄積されている ACK
パケット数が 20 [pkts] 程度に保たれている．しかし，20 秒以降に loss-based 手法に切り替わるため，CUBIC と同様に，無線アクセスポイントに蓄積されているパケット数が増加し，最終的には ACK パケットの廃棄が発生している．
コネクション数が増加すると，どの TCP 改良手法においても，無線アクセスポイントに

ACK パケットが蓄積される理由として以下が考えられる．CSMA/CA において，無線端末と無線アクセスポイントの送信機会は平等である．このため，無線端末が増えコネクション
数が増加すると，コネクション数が 1 である場合は無線アクセスポイントの送信機会が 1/2であったのが，コネクション数が 2，4 と増加すると送信機会が 1/3，1/5 と減少する．無線アクセスポイントにおいて送信機会が減少しても，図 1 のネットワーク環境下の帯域遅延積は変化がないため，無線アクセスポイントに到着する ACK パケット数に変化はない．このため，無線アクセスポイントに ACK パケットが到着する間隔より，無線アクセスポイン
トから各無線端末へ ACK パケットが送信されるまでの間隔が長くなり，次第に無線端末のバッファに ACK パケットが蓄積されたと考えられる．これは，CSMA/CA を用い，かつ上りと下りで帯域を共有する無線 LAN 環境に特有の現象であるといえる．

16

20
3
15
2
10
1

5

0

20

40

60

0
80 100 120 140 160 180 200

25

20

20
15
15
10
10
5

5

0
0

20

40

Simulation Time [sec]q_dataq_ack

q_data

25
20

15
15
10
10
5

5

20

40

60

0
80 100 120 140 160 180 200

30

35

25

30
20

25
20

15

15

10

10
5

5
0
0

20

Simulation Time [sec]q_dataq_ack

drop_ack

40

Number of Packets
in Queueing Buffer [pkts]

30

20

q_ack

(b) コネクション数が 2 である場合

Number of Drops [pkts]

Number of Packets
in Queueing Buffer [pkts]

25

0

0
80 100 120 140 160 180 200

Simulation Time [sec]drop_ack(a) コネクション数が 1 である場合

0

60

40

60

Number of Drops [pkts]

030

Number of Drops [pkts]

25

4

25

Number of Packets
in Queueing Buffer [pkts]

30

Number of Drops [pkts]

Number of Packets
in Queueing Buffer [pkts]

5

0
80 100 120 140 160 180 200

Simulation Time [sec]drop_ack

q_data(c) コネクション数が 4 である場合

q_ack

drop_ack(d) コネクション数が 8 である場合

図 3: 無線アクセスポイントにおけるキュー長の変化およびパケット廃棄数の変化 (TCP Vegas，
伝搬遅延: 200 [msec])

17

20
3
15
2
10
1

5

0

20

40

60

0
80 100 120 140 160 180 200

35

25

30
20

25
20

15

15

10

10
5

5
0
0

20

Simulation Time [sec]q_dataq_ack

q_data

250

80

200

60

150

40

100

20

50

40

60

0
80 100 120 140 160 180 200

Number of Packets
in Queueing Buffer [pkts]

100

Number of Drops [pkts]

Number of Packets
in Queueing Buffer [pkts]

300

20

q_ack

q_ack

drop_ack

120

350

100

300
250

80

200
60
150
40

100

20

50

0
0

20

Simulation Time [sec]q_data0
80 100 120 140 160 180 200(b) コネクション数が 2 である場合

120

0

60

Simulation Time [sec]drop_ack(a) コネクション数が 1 である場合

0

40

40

60

Number of Drops [pkts]

030

Number of Drops [pkts]

25

4

40

Number of Packets
in Queueing Buffer [pkts]

30

Number of Drops [pkts]

Number of Packets
in Queueing Buffer [pkts]

5

0
80 100 120 140 160 180 200

Simulation Time [sec]drop_ack

q_data(c) コネクション数が 4 である場合

q_ack

drop_ack(d) コネクション数が 8 である場合

図 4: 無線アクセスポイントにおけるキュー長の変化およびパケット廃棄数の変化 (AReno，
伝搬遅延: 200 [msec])

18

20
3
15
2
10
1

5

0

20

40

60

0
80 100 120 140 160 180 200

35

25

30
20

25
20

15

15

10

10
5

5
0
0

20

Simulation Time [sec]q_dataq_ack

q_data

300
250
200

60
150
40

100

20

50

0

0
80 100 120 140 160 180 200

60

Number of Packets
in Queueing Buffer [pkts]

100
80

q_ack

drop_ack

500
450

100

400
350

80

300
60

250
200

40

150
100

20

50
0
0

20

Simulation Time [sec]q_dataq_ack

120

Number of Drops [pkts]

Number of Packets
in Queueing Buffer [pkts]

350

40

0
80 100 120 140 160 180 200(b) コネクション数が 2 である場合

120

20

60

Simulation Time [sec]drop_ack(a) コネクション数が 1 である場合

040

Number of Drops [pkts]

030

Number of Drops [pkts]

25

4

40

Number of Packets
in Queueing Buffer [pkts]

30

Number of Drops [pkts]

Number of Packets
in Queueing Buffer [pkts]

5

40

60

0
80 100 120 140 160 180 200

Simulation Time [sec]drop_ack

q_data(c) コネクション数が 4 である場合

q_ack

drop_ack(d) コネクション数が 8 である場合

図 5: 無線アクセスポイントにおけるキュー長の変化およびパケット廃棄数の変化 (CUBIC，伝搬遅延: 200 [msec])

19

次に，図 2 のネットワーク環境において，AReno を用いた場合の無線区間の遅延変動を
図 6 に，無線区間に送出されるパケットの総数の変化を図 7 に，無線アクセスポイントにおけるキュー長の変化およびパケット廃棄数の変化を図 8 にそれぞれ示す． なお，図 6 において，コネクション数が 2 以上の場合においては，無線端末が複数あるが，より無線区間の遅延変動が大きい端末の遅延変動を表している．また，コネクション数によって，図 6 のシミュレーション時間が異なるが，各コネクションの場合においてより遅延変動が大きい時間を選んでいる．図 6 中の delay data mac は無線端末からフレームが送信されて無線アクセ
スポイントにおいて受信されるまでの時間，delay ack mac は無線アクセスポイントからフレームが送信されて無線端末において受信されるまでの時間である．
図 6 より，コネクション数が増加しても，delay ack mac の変動幅が増加していないのに対し ，コネクション数が増加すると delay data ack の変動幅が増加していることがわかる．
例えば，図 6(a) では，delay ack mac の変動幅が最大で 8 [msec] 程度であり，図 6(f) では最大で 20 [msec] 程度であるが，delay data mac は図 6(a) では変動幅が最大で 5 [msec] 程度であり，図 6(f) では変動幅が最大で 150 [msec] 程度である．これは，ACK パケットサイズが40 [pkts] と小さいのに対し ，データパケットサイズが 1500 [pkts] であるために，データパケットの方が ACK パケットより伝送にかかる時間が長く，フレームの衝突が発生しやすいためだと考えられる．
図 7(a) をみると，無線区間に送出されるデータパケットの総数と ACK パケットの総数がほぼ同数であることがわかる．図 7(b) のように，コネクション数が増加すると，ある時点でデータパケットの総数が増加し， ACK パケットの総数が減少し始めることが分かる．ここで，図 8 から，コネクション数が 1 である場合はシミュレーション時間内では，無線アクセ
スポイントにおいて ACK パケットが廃棄されていないが，コネクション数が大きくなると

ACK パケットが廃棄されていることがわかる．図 7 と図 8 より，ACK パケットが廃棄され始める時間と無線区間に送出されるデータパケットの総数が増大し ACK パケットの総数が減少する時刻が一致することがわかる．例えば，図 7(c) において，無線区間に送出されるパケットの総数が変動する時間は 40 秒付近であり，図 8(c) より ACK パケットが廃棄され始める時間が 40 秒付近と一致している．このことから，無線区間に送出されるデータパケッ
トの総数が増加し ACK パケットの総数が減少する現象が，無線アクセスポイントにおいてACK パケットが廃棄されることの原因であるといえる．
この問題が引き起こされる理由は以下によるものだと考えられる．無線アクセスポイントにおいて，ACK パケットが廃棄されることによって，無線端末では，その ACK パケットに対応するデータパケットが受信端末で正しく受信されたという情報を，そのデータパケット
が受信端末で受信された以降のデータパケットに対応する ACK パケットを受信することによって知ることになる．TCP は，ACK パケットのヘッダに記載された，データパケットの

20

40

8

35

7

30

Delay [msec]

Delay [msec]

9

6
5
4
3

25
20
15

2

10

1

5

0

0
20

22

24

26

28

30

20

22

Simulation Time [sec]delay_ack_mac

delay_data_mac

28

30

delay_ack_mac(b) コネクション数が 2 である場合

80

140

70

120

Delay [msec]

60

Delay [msec]

26

delay_data_mac(a) コネクション数が 1 である場合

50
40
30
20

100
80
60
40
20

10
0
110

115

120

125

0
110

130

115

Simulation Time [sec]delay_data_mac

120

125

130

Simulation Time [sec]delay_ack_mac

delay_data_mac(c) コネクション数が 4 である場合

delay_ack_mac(d) コネクション数が 8 である場合

140

160

120

140
120

100

Delay [msec]

Delay [msec]

24

Simulation Time [sec]

80
60
40

100
80
60
40

20

20

0

0
0

20

40

60

80

100

120

140

160

180

200

Simulation Time [sec]delay_data_mac

0

20

40

60

80

100

120

140

160

180

200

Simulation Time [sec]delay_ack_mac

delay_data_mac(e) コネクション数が 16 である場合

delay_ack_mac(f) コネクション数が 32 である場合

図 6: 無線区間にボト ルネックが ある場合の無線区間の遅延変動 (AReno，伝搬遅延:
100 [msec])

21

4500

4000

4000

Number of Packets
in Wireless LAN [pkts]

Number of Packets
in Wireless LAN [pkts]

4500
3500
3000
2500
2000
1500
1000
500
0

3500
3000
2500
2000
1500
1000
500
0

0

20

40

60

80

100 120 140 160 180 200

0

20

40

Simulation Time [sec]total
data_packets

ack_packets

100 120 140 160 180 200
ack_packets(b) コネクション数が 2 である場合

4500

4500

4000

4000

Number of Packets
in Wireless LAN [pkts]

Number of Packets
in Wireless LAN [pkts]

80

total
data_packets(a) コネクション数が 1 である場合

3500
3000
2500
2000
1500
1000
500
0

3500
3000
2500
2000
1500
1000
500
0

0

20

40

60

80

100 120 140 160 180 200

0

20

40

Simulation Time [sec]total
data_packets

ack_packets

Number of Packets
in Wireless LAN [pkts]

3500
3000
2500
2000
1500
1000
500
0
40

60

80

100 120 140 160 180 200

Simulation Time [sec]total
data_packets

100 120 140 160 180 200
ack_packets(d) コネクション数が 8 である場合

4000

20

80

total
data_packets

4500

0

60

Simulation Time [sec](c) コネクション数が 4 である場合

Number of Packets
in Wireless LAN [pkts]

60

Simulation Time [sec]

5000
4500
4000
3500
3000
2500
2000
1500
1000
500
0
0

20

40

60

80

100 120 140 160 180 200

Simulation Time [sec]ack_packets

total
data_packets(e) コネクション数が 16 である場合

ack_packets(f) コネクション数が 32 である場合

図 7: 無線区間にボトルネックがある場合の無線区間に送出されるパケットの総数の変化(AReno，伝送遅延: 100 [msec])

22

15
150
10

100

5

50
0
0

20

40

60

0
80 100 120 140 160 180 200

500

500

400

400

300

300

200

200

100

100

0
0

Simulation Time [sec]
q_ack

300
200
100
0
0

600
500
400
300
200
100
0
0

Simulation Time [sec]
q_ack

300
200
100
0
0

600
500
400
300
200
100
0
0

Simulation Time [sec]q_ack

drop_ack(d) コネクション数が 8 である場合

Number of Packets
in Queueing Buffer [pkts]

400

1300
1200
1100
1000
900
800
700
600
500
400
300
200
100
0
20 40 60 80 100 120 140 160 180 200
q_ack

Number of Drops [pkts]

Number of Packets
in Queueing Buffer [pkts]

500

1600
1500
1400
1300
1200
1100
1000
900
800
700
600
500
400
300
200
100
0
20 40 60 80 100 120 140 160 180 200

drop_ack

Simulation Time [sec]drop_ack(c) コネクション数が 4 である場合
600

080 100 120 140 160 180 200(b) コネクション数が 2 である場合

Number of Packets
in Queueing Buffer [pkts]

400

60

q_ack

Number of Drops [pkts]

Number of Packets
in Queueing Buffer [pkts]

500

1100
1000
900
800
700
600
500
400
300
200
100
0
20 40 60 80 100 120 140 160 180 200

40

Simulation Time [sec]drop_ack(a) コネクション数が 1 である場合
600

20

Number of Drops [pkts]

20

200

600

Number of Drops [pkts]

25

250

600

1700
1600
1500
1400
1300
1200
1100
1000
900
800
700
600
500
400
300
200
100
0
20 40 60 80 100 120 140 160 180 200

Simulation Time [sec]drop_ackq_ack(e) コネクション数が 16 である場合

drop_ack(f) コネクション数が 32 である場合

図 8: 無線区間にボトルネックがある場合の無線アクセスポイントにおけるキュー長の変化
およびパケット廃棄数の変化 (AReno，伝送遅延: 100 [msec])

23

Number of Drops [pkts]

300

Number of Packets
in Queueing Buffer [pkts]

30

Number of Drops [pkts]

Number of Packets
in Queueing Buffer [pkts]

350

最大シーケンス番号を管理することによって，ネットワーク上にデータパケットを送出するかを決定する．TCP は現在の輻輳ウィンド ウサイズのデータパケットをネットワーク上に送出すると，ACK パケットを受信しない限り，新たにデータパケットをネットワーク上に送出しない．データパケットおよび ACK パケットが廃棄されない場合は，ACK パケットに記載されている最大シーケンス番号は連続であるため，ACK を 1 つ受信するたびにデータパケットが 1 つ送信可能となる．しかし，図 8(b) から図 8(f) のように，無線アクセスポイントにおいて ACK パケットが損失すると，最大シーケンス番号が不連続となる．このため，無線端末が ACK パケットを受信すると，送信可能となるデータパケット数が 1 ACK パケットにつき複数になり，無線区間において送出されるデータパケットの総数が急激に増加するため，無線 LAN において衝突が増加する．このため，無線区間において送出される ACK パ
ケットの総数が減少したと考えられる．
データパケットは前述のとおり ACK パケットより衝突しやすいため，さらなる衝突を誘発すると考えられる．このため，ACK パケットが無線アクセスポイントに蓄積されてからネットワークに送出するまでの時間が増加し，さらに，無線アクセスポイントにおいて ACK
パケットの廃棄が増大すると考えられる．
これを考慮し ，図 6(e) と図 7(e)，図 6(f) と図 7(f) をそれぞれ比較すると，無線区間に送出されるデータパケットの総数と ACK パケットの総数がほぼ同数である場合より，無線区間に送出されるデータパケットの総数が ACK パケットの総数より大きい場合の方が，無線区間の遅延変動が大きくなっていることがわかる．以上から，無線アクセスポイントにおいて ACK パケットが廃棄されることによって，無線 LAN 内の輻輳がより悪化することがいえる．
図 1 のネットワークモデルにおけるシミュレーション結果について，コネクション数が2 であり，TCP として TCP Vegas を用いた場合の結果を図 9 に，FAST TCP を用いた場合の結果を図 10 に示す．また，CTCP を用いた場合の結果を図 11 に AReno を用いた場合の結果を図 12 に，CUBIC を用いた場合の結果を図 13 に示す． 各図の (a) は輻輳ウィンド ウの変化と 各 TCP 改良手法が輻輳ウィンド ウの制御に用いる RTT 情報の変化を表し，(b) はスループットの変化を表す，また，(c) は無線区間における遅延変動，すなわち，TCP においてデータパケットが発生してから無線アクセスポイントにおいて受信されるまでの時間(delay data)，無線端末からフレームが送信されて無線アクセスポイントにおいて受信されるまでの時間 (delay data mac) ，および無線アクセスポイントからフレームが送信されて無線端末において受信されるまでの時間 (delay ack mac) を表す．
図 9 から図 12 の (c) より，純粋な delay-based 手法である TCP Vegas および FAST TCPの場合は，delay data がそれぞれ 60 [msec] を中心に 60 [msec] の幅，100 [msec] を中心に100 [msec] の幅で変動し，遅延が一定になるように動作していることがわかる．しかし，loss24

90

Window Size [pkts]

80
70
60
50
40
30
20
10
0
0

20

40

60

600
550
500
450
400
350
300
250
200
150
100
50
0
80 100 120 140 160 180 200

Time [msec]

100

Simulation Time [sec]cwndminRTT(a) 輻輳ウィンド ウサイズの変化および RTT の変化

2000

Delay [msec]

Throughput [kbps]

2500

1500
1000
500
0

200
180
160
140
120
100
80
60
40
20
0
0

0

20

40

60

80

100 120 140 160 180 200

Simulation Time [sec]

20

40

60

delay_data
delay_data_mac

throughput(b) スループットの変化

80

100

120

140

160

180

200

Simulation Time [sec]delay_ack_mac(c) 無線区間の遅延変動

図 9: 無線区間にボトルネックがあるネットワークにおけるシミュレーション結果 (TCP Vegas,
コネクション数: 2，伝搬遅延: 200 [msec])

25

100
80
60
40
20

0

20

40

60

600
550
500
450
400
350
300
250
200
150
100
50
0
80 100 120 140 160 180 200

Time [msec]

Window Size [pkts]

120

Simulation Time [sec]cwndavgRTT(a) 輻輳ウィンド ウサイズの変化および RTT の変化

2500

350

Delay [msec]

Throughput [kbps]

300
2000
1500
1000
500

250
200
150
100
50
0

0

0
0

20

40

60

80

100 120 140 160 180 200

Simulation Time [sec]

20

40

60

delay_data
delay_data_mac

throughput(b) スループットの変化

80

100

120

140

160

180

200

Simulation Time [sec]delay_ack_mac(c) 無線区間の遅延変動

図 10: 無線区間にボトルネックがあるネットワークにおけるシミュレーション結果 (FAST
TCP, コネクション数: 2，伝搬遅延: 200 [msec])

26

180

1000
800

140
120

600

100
80

400

60
40

Time [msec]

Window Size [pkts]

160

200

20
0

20

40

60

0
100

80

Simulation Time [sec]cwndminRTT(a) 輻輳ウィンド ウサイズの変化および RTT の変化

600
500

2000

Delay [msec]

Throughput [kbps]

2500

1500
1000

400
300
200
100

500

0
0

0
0

20

40

60

80

100 120 140 160 180 200

Simulation Time [sec]20

40

delay_data
delay_data_mac

throughput(b) スループットの変化

60

80

100

Simulation Time [sec]delay_ack_mac(c) 無線区間の遅延変動

図 11: 無線区間にボトルネックがあるネットワークにおけるシミュレーション結果 (CTCP,
コネクション数: 2，伝搬遅延: 200 [msec])

27

180

1000
800

140
120

600

100
80

400

60
40

Time [msec]

Window Size [pkts]

160

200

20
0

20

40

60

0
100

80

Simulation Time [sec]
cwnd

sRTT

(a) 輻輳ウィンド ウサイズの変化および RTT の変化

600
500

2000

Delay [msec]

Throughput [kbps]

2500

1500
1000

400
300
200
100

500

0
0

0
0

20

40

60

80

20

100 120 140 160 180 200

40

60

80

100

Simulation Time [sec]Simulation Time [sec]delay_data
delay_data_mac

throughput(b) スループットの変化

delay_ack_mac(c) 無線区間の遅延変動

3000
2800
2600
2400
2200
2000
1800
1600
1400
1200
1000
800
600
400
200
0

16000

2500

12000
10000
8000
6000
4000

Throughput [kbps]

14000

Time [msec]

Window Size [pkts]

図 12: 無線区間にボトルネックがあるネットワークにおけるシミュレーション結果 (AReno,
コネクション数: 2，伝搬遅延: 200 [msec])

2000
1500
1000
500

2000
0

0
20 40 60 80 100 120 140 160 180 200

00Simulation Time [sec]
cwnd

20

40

60

80

100 120 140 160 180 200

Simulation Time [sec]RTTthroughput(a) 輻輳ウィンド ウの変化および RTT の変化(b) スループットの変化

図 13: 無線区間にボトルネックがあるネットワークにおけるシミュレーション結果 (CUBIC,
コネクション数: 2，伝搬遅延: 200 [msec])28

based 手法と delay-based 手法を組み合わせた手法である CTCP および AReno の場合は，シミュレーション開始時から 50 秒経過した辺りから delay data が変動しながら単調増加していることがわかる．これは，CTCP および AReno がシミュレーション開始時から 50 秒経過す
るまでは，delay-based 手法による動作によって TCP Vegas や FAST TCP のように delay dataの値を一定に保つように動作しているが，50 秒移行は TCP Reno の輻輳制御によって求められる輻輳ウィンド ウサイズが 各方式の delay-based 手法による動作に求められる輻輳ウィ
ンド ウサイズより大きくなり，輻輳ウィンド ウの増加速度をそれぞれの手法が TCP Reno と同じにしたためだと考えられる．
また，CTCP や AReno が TCP Reno に対抗するための loss-based 手法の動作に切り替わっ
た後において，delay data が増加しつづけている．これは，前述のように図 1 のネットワー
ク環境下においては，ACK パケットが無線アクセスポイントにおいて廃棄されるが，デー
タパケットが廃棄されないことに起因していると考えられる．TCP はデータパケットの損失に対しては輻輳制御を行い，輻輳ウィンド ウサイズを減少させるが，ACK パケットの損失に対しては 1 RTT 内のすべての ACK パケットが損失しない限り輻輳制御を行わない．このため，loss-based 手法の輻輳制御による輻輳ウィンド ウサイズの増加がとまらず，データパケットが無線端末内の送信バッファに蓄積されることにより，delay data，すなわち，TCP
においてデータパケットが発生してから無線アクセスポイントにおいて受信されるまでの時間が増加しつづけていると考えられる．
このことと前述の ACK パケットが廃棄されることによって無線 LAN の輻輳状態が悪化してしまうということから，loss-based 手法や loss-based 手法と delay-based 手法を組み合わせた手法では，最終的に無線アクセスポイントにおいて ACK パケットの廃棄が発生するため，今回検討したような環境においては，純粋な delay-based 手法のように遅延の増加によって制御するべきだといえる．

TCP として TCP Vegas を用いた場合は，図 9 (a) より，TCP Vegas が式 (2) によって輻輳
ウィンド ウサイズを増加させると，輻輳ウィンド ウサイズがシミュレーション開始から 70秒で本シミュレーション環境下での帯域遅延積に相当するパケット数になっていることがわ
かる．また，図 9(c) より，60 秒以降から，delay data mac は 10 [msec] から最大 60 [msec]
程度の幅で変動し ，delay ack mac は 20 [msec] から最大 120 [msec] 程度の幅で変動していることがわかる．これらの無線区間の遅延変動にともない，図 9(a) より，minRT T の値が変動しているが，輻輳ウィンド ウサイズの変化が 5 [pkts] 程度と変動幅が小さいことがわかる．これは，式 (2) より，TCP Vegas の輻輳ウィンド ウサイズの増減幅が 1 であるために，
無線区間の遅延変動により minRT T の値が大きく変動したとしても，輻輳ウィンド ウサイズに対して影響がほとんど 現れないためだと考えられる．

TCP として FAST TCP を用いた場合は， 図 10(c) より，delay data mac が 10 [msec] から29

最大 100 [msec] 程度変動しており，delay ack mac に関しては 30 [msec] から最大 200 [msec]
程度変動していることがわかる．この無線区間の遅延変動によって，図 10(a) より，FAST

TCP が輻輳制御に用いる RTT 情報である avgRT T が 100 [msec] 程度の幅で変動していることがわかる．さらに，avgRT T の変動にともなって，輻輳ウィンド ウサイズの増減が15 [pkts] 程度の幅で変動していることがわかる．これは，FAST TCP が式 (3) のように，現在の輻輳ウィンド ウサイズと avgRT T の値に応じて，輻輳ウィンド ウサイズの増減幅を決定するため，TCP Vegas より輻輳ウィンド ウが大きく変動していると考えられる．

TCP として CTCP を用いた場合は，図 11(a) より，CTCP は 20 秒付近から delay-based 手法の動作によって輻輳ウィンド ウサイズが大きくしており，50 秒付近から TCP Reno と同じ増加速度で輻輳ウィンド ウサイズが大きくなっていることがわかる．また，図 11(c) より，

delay data mac が 10 [msec] から 50 [msec] 程度変動しており，delay ack mac は 20 [msec]
から 50 [msec] 程度の幅で変動していることがわかる．図 11(a) と図 11(c) から，CTCP が

delay-based 手法の動作によって輻輳制御を行っている間，無線区間の遅延変動による影響はほとんど 現れず，無線端末の送信バッファにパケットが蓄積されることによる遅延の変動に応じて，minRT T が変動し ，それにしたがって輻輳ウィンド ウが変動していることがわ
かる．

TCP として AReno を用いた場合は，図 12(a) より，AReno は 40 秒付近まで delay-based
手法の動作によって輻輳ウィンド ウサイズを増減させており，40 秒以降は TCP Reno と同
じ 増加速度で輻輳ウィンド ウサイズを増加させていることがわかる．また，図 12(c) より，

delay data mac が 10 [msec] から 50 [msec] 程度変動しており，delay ack mac は 20 [msec]
から 20 [msec] 程度変動していることがわかる．図 12(a) と図 12(c) から，送信バッファにパケットが蓄積されることによって発生する遅延の変動と無線区間における遅延変動によって，AReno は輻輳ウィンド ウサイズを 90 [pkts] 程度を中心に 30 [pkts] 程度変動させている
ことがわかる．

TCP として CUBIC を用いた場合は，図 12(a) から，CUBIC は，シミュレーション時間内において常に輻輳ウィンド ウサイズを増加していることがわかる．これは，前述のとおり，
図 1 のネットワーク環境下において，ACK パケットは廃棄されるがデータパケットが廃棄されないために，loss-based 手法である CUBIC はネットワークの輻輳を検出できないためだと考えられる．

2.5 節で述べたとおり，CUBIC は輻輳ウィンド ウサイズの制御に RTT を用いないため無線区間の変動による影響は受けないと考えられる．このため，CUBIC のスループットの変化は図 1 によって表されるネットワーク環境下では無線区間の遅延変動がない場合の結果であると考えることができる．図 13(b) より，CUBIC のスループットは 200 [kbps] 程度変動していることから，無線区間の遅延の影響とは無関係に 200 [kbps] 程度スループットが変動す

30

ることがわかる．図 9(b) から図 12(b) より，どの TCP 改良手法に置いてもスループットの変動幅が 200 [kbps] 以内であることがわかる．これは，FAST TCP や AReno の場合は輻輳
ウィンド ウを大きく変化させるが，その変動が無線端末の送信バッファ内に蓄積されたデー
タパケット数の変動にしか影響を与えないため，スループットまでは影響が出なかったと考えられる．
以上のことから，無線端末が TCP の送信側で無線区間がボトルネックとなる場合においては，無線区間の遅延変動は delay-based 手法の動作に影響を与えないということができる．
図 1 のネットワーク環境において，コネクション数が多くなった場合，輻輳ウィンド ウが大きくなるコネクションが存在する反面，輻輳ウィンド ウサイズがほとんど 増加しないコネクションが出現するという現象が現れる．TCP として AReno を用いた場合の正常なコネクションのシミュレーション結果を図 14 に，問題のあるコネクションのシミュレーション結果を図 16 に，また，TCP として CUBIC を用いた場合の正常なコネクションのシミュレー
ション結果を図 15 に，問題のあるコネクションのシミュレーション結果を図 17 に示す．
図 14(a) および図 15(a) より，それらの TCP コネクションでは輻輳ウィンド ウサイズが十分大きくなっているのに対し，図 16(a) および図 17(a) のような TCP コネクションの場合は輻
輳ウィンド ウサイズが 1 [pkts] からほとんど 増加していないことがわかる．図 16(b) および
図 17(b) から，輻輳ウィンド ウが 1 [pkts] からほとんど 増加しないコネクションでは，無線
アクセスポイントにほとんど ACK パケットが蓄積せず，ACK パケットが廃棄されていることがわかる．それらに対し，正常に輻輳ウィンド ウサイズを増加させているコネクションは
図 14(b) および図 15(b) のように，無線アクセスポイントにおいて ACK パケットが廃棄されているが，無線アクセスポイントのバッファ内にも ACK パケットが保持されていることがわかる．
これらのことから，このよう TCP コネクション間で深刻な不公平性が発生した原因は，以下によるものであると考えられる．図 1 のようなネットワーク環境下では，前述のとおり，コネクション数が増加すると，ACK パケットが無線アクセスポイントに蓄積し，ACK パケッ
トが廃棄される．また，TCP はデータパケットが 1 つでも廃棄された場合においては輻輳
制御によって輻輳ウィンド ウサイズを減少させる．しかし ，ACK パケットが廃棄される場
合においては，TCP は 1 ウィンド ウ中のすべての ACK パケットが廃棄されなければ輻輳制御が動作せず，輻輳ウィンド ウサイズを減少させない．このため，図 1 のようなネットワー
ク環境のような ACK パケットが廃棄される環境では，TCP はネットワークの輻輳を 1 ウィ
ンド ウ中のすべての ACK が廃棄されることによって発生するタイムアウトによってのみ認
識し，輻輳ウィンド ウサイズを 1 に減少させる．しかし，このとき，無線アクセスポイントのバッファは一杯であり，ACK パケットが無線端末までほとんど 到達しない．以上により，
輻輳ウィンド ウサイズの回復が行われず，深刻な不公平性を生じたものだと考えられる．

31

4000

50
40

3000
2500

30

2000
20

1500
1000

Time [sec]Window Size [pkts]

3500

10

500
0
0

20

40

60

0
80 100 120 140 160 180 200

Simulation Time [sec]
cwnd

sRTT

(a) 輻輳ウィンド ウサイズの変化

80
70

25

60
20

50

15

40
30

10

20
5

10

0
0

20

40

60

Number of Drops [pkts]

Number of Packets
in Queueing Buffer [pkts]

30

0
80 100 120 140 160 180 200

Simulation Time [sec]q_dataq_ack

drop_ack(b) 無線アクセスポイントにおけるキュー長の変化およびパケット廃棄率の変化

図 14: 不公平が発生する場合の正常なコネクションのシミュレーション結果 (AReno，コネ
クション数: 16，伝搬遅延: 200 [msec])

32

900

40

700

30

600
500

20

400
300

Time [sec]Window Size [pkts]

800

10

200
100
0
0

20

40

60

0
80 100 120 140 160 180 200

Simulation Time [sec]
cwnd

sRTT

Number of Packets
in Queueing Buffer [pkts]

30
25
20
15
10
5
0
0

20

40

60

80
75
70
65
60
55
50
45
40
35
30
25
20
15
10
5
0
80 100 120 140 160 180 200

Number of Drops [pkts](a) 輻輳ウィンド ウサイズの変化

Simulation Time [sec]q_dataq_ack

drop_ack(b) 無線アクセスポイントにおけるキュー長の変化およびパケット廃棄率の変化

図 15: 不公平が発生する場合の正常なコネクションのシミュレーション結果 (CUBIC，コネ
クション数: 16，伝搬遅延: 200 [msec])

33

1.4

14

1.2

12

1

10

0.8

8
0.6

6

Time [sec]Window Size [pkts]

16

0.4

4

0.2

2
0
0

20

40

60

0
80 100 120 140 160 180 200

Simulation Time [sec]
cwnd

sRTT

(a) 輻輳ウィンド ウサイズの変化

10

3.5
8

3
2.5

6

2
4

1.5
1

2

0.5
0
0

20

40

60

Number of Drops [pkts]

Number of Packets
in Queueing Buffer [pkts]

4

0
80 100 120 140 160 180 200

Simulation Time [sec]q_dataq_ack

drop_ack(b) 無線アクセスポイントにおけるキュー長の変化およびパケット廃棄率の変化

図 16: 不公平が発生する場合の問題のあるコネクションのシミュレーション結果 (AReno，コ
ネクション数: 16，伝搬遅延: 200 [msec])

34

1.6

14

1.4

12

1.2

10

1

8

0.8

6

0.6

4

0.4

2

0.2

0
0

20

40

60

Time [sec]Window Size [pkts]

16

0
80 100 120 140 160 180 200

Simulation Time [sec]
cwnd

sRTT

4

14

3.5

12

3

10

2.5

8

2
6

1.5

4

1

2

0.5
0
0

20

40

60

Number of Drops [pkts]

Number of Packets
in Queueing Buffer [pkts](a) 輻輳ウィンド ウサイズの変化

0
80 100 120 140 160 180 200

Simulation Time [sec]q_dataq_ack

drop_ack(b) 無線アクセスポイントにおけるキュー長の変化およびパケット廃棄率の変化

図 17: 不公平が発生する場合の問題のあるコネクションのシミュレーション結果 (CUBIC，
コネクション数: 16，伝搬遅延: 200 [msec])35

また，この現象は，無線アクセスポイントにおいて ACK パケットが廃棄されるほどバッ
ファに ACK パケットが蓄積されているために生じているため，既にこのような輻輳が発生している無線 LAN 環境に新たに無線端末が参加しようとした場合でも，同様な現象が発生すると考えられる．
以上の結果から，無線端末が TCP の送信側であり無線区間がボトルネックとなるネット
ワーク環境においては，delay-based 手法に対して無線区間の遅延変動による影響が抑えられるため問題はなく，loss-based 手法や最終的に loss-based 手法として動作する loss-based 手
法と delay-based 手法を組み合わせた手法では，ACK パケットが無線アクセスポイントに蓄積されることに起因して，無線 LAN の輻輳を悪化させ， TCP コネクション間に不公平性を生じる．そのため，輻輳制御を遅延のみに基づいて行う方が良いといえる．

36

3.2 ボト ルネックが有線区間にある場合
本節では，ボトルネックが有線区間にあるネットワーク環境においてシミュレーションを行い，無線 LAN 環境がボトルネックとなる場合の各 TCP 改良手法への影響について考察する．さらに，ボトルネックが無線区間にある場合のネットワーク環境でのシミュレーショ
ン結果を踏まえ，無線 LAN 環境において無線端末が送信側である場合の各 TCP 改良手法への影響について考察する．

3.2.1 シミュレーション環境
無線 LAN 規格として IEEE 802.11a を使用し ，ボトルネックリンクが有線区間にある場
合のネットワークモデルを図 18 に示す．図 18 は，図 1 と同様に，複数の無線端末が送信側

TCP として 1 つの無線アクセスポイントを共有し ，無線アクセスポイントから受信端末までが有線リンクにより接続されている構成である．無線端末から無線アクセスポイントまで
は IEEE 802.11a を利用しているため無線伝送速度は最大 54 [Mbps] の無線リンクである．また，無線アクセスポイントから受信端末まではリンク帯域が 22 [Mbps] であり，片道の伝搬
遅延が 50 [msec] である．このため，このネットワークモデルでは，無線アクセスポイント
から受信端末までの有線区間がボトルネックリンクとなる．なお，無線アクセスポイントト
から受信端末までの有線リンクのバッファには，キュー管理機構として DropTail を用いた．
シミュレーションは 3.1.1 節で記述した内容と同様に，無線端末数を 1 台から 32 台まで変化させ，各無線端末から有線端末に対して TCP コネクションを 1 本生成する．TCP には

CTCP および AReno を用いて，それぞれの場合について各無線端末の TCP に同一の TCP 改
良手法を設定した．また，有線ボトルネックリンクのバッファサイズは，TCP に CTCP を用いた場合は 40 [pkts] に，TCP に AReno を用いた場合は 20 [pkts] に設定した．これは，有線ボトルネックリンクのバッファサイズを小さくすることにより，無線区間の遅延変動の影
響を相対的に大きくするためである．各 TCP コネクションはシミュレーション開始後，0.01
秒間隔で，データ転送を開始した．各無線端末は生成した TCP コネクションを用いて，ア
プ リケーション層プロトコルとして FTP を用いて無限大のサイズを持つデータの転送を行う．データパケットのサイズは 1500 [pkts] に設定した．
また，AReno に関しては，図 18 のネットワークモデルにおいて，有線ボトルネックのリンク帯域を 100 [Mbps] に，有線ボトルネックリンクのバッファサイズを 500 [pkts] にそれぞれ設定し，前述のシミュレーションを行った．
各 TCP 改良手法のパラメータは，それぞれ以下のように設定した．

CTCP αc = 0.125, γc = 30, ζc = 1

37

AReno αa = 16, βa = 1, γa = 10

3.2.2 シミュレーション結果と考察
図 18 のネットワーク環境において，有線ボトルネックのリンク帯域を 100 [Mbps]，有線
ボトルネックのバッファサイズを 500 [pkts] に設定し ，TCP として AReno を用いた場合のシミュレーションにおける，無線区間の遅延変動を図 19 に，無線区間に送出されるパケットの総数の変化を図 20 に示す． なお，図 19 において，図 6 と同様に，コネクション数が 2以上の場合においては，無線端末が複数あるが，より無線区間の遅延変動が大きい端末の無線区間の遅延変動を示している．

3.1.2 節で述べたとおり，無線区間にボトルネックがある場合はコネクション数が増加する
につれ，無線区間の遅延変動が大きくなるという結果であったが，有線区間にボトルネックがある場合では，図 19 より，コネクション数が増加しても遅延変動がほとんど 増加しない
ことがわかる．また，図 20 をみると，コネクション数が増加しても，無線区間に送出される
データパケットの総数と ACK パケットの総数がほぼ同数であることがわかる．このことから，有線区間にボトルネックがある場合における，無線区間の遅延変動が無線区間にボトル
ネックリンクがある場合と比べて小さいのは以下の理由によるものだと考えられる．図 7 および図 20 より，無線区間の送出されるパケット総数が，無線区間がボトルネックである場
合は約 4400 [pkts] であるのに対して，有線区間にボトルネックがある場合は約 3500 [pkts]と小さい．これは，有線区間にボトルネックがある場合は無線区間のネットワークには余裕があるということを意味する．したがって，フレームが衝突する確率が，無線区間にボトルネックがある場合に比べて低いと考えられる．このため，無線区間の遅延変動が小さくなると考えられる．さらに，無線区間がボトルネックである場合のように，ACK パケットが廃棄されることによる遅延変動の増大も発生しない．
また，コネクション数が増加すると無線区間に送出されるパケットの総数が変動しているのがわかる．これは，データパケットが有線ボトルネックリンクにおいて廃棄されることによって，TCP が輻輳制御を行った結果，輻輳ウィンド ウサイズが減少したためだと考えられる．

38

Wireless Node
（Number of Nodes: 1-32）(Sender)

Wired Node
(Receiver)

22 Mbps, 50 msec

802.11a(54 Mbps)
Access Point

図 18: IEEE 802.11a を用いた場合のボトルネックが有線区間にあるネットワークモデル

39

6

8
7

5

Delay [msec]

Delay [msec]

6
4
3
2

5
4
3
2

1

1

0

0
0

20

40

60

80

100

120

140

160

180

200

0

20

40

Simulation Time [sec]delay_data_mac

delay_ack_mac

100

delay_data_mac

120

140

160

180

200

180

200

180

200

delay_ack_mac(b) コネクション数が 2 である場合

9

5

8

4.5
4

Delay [msec]

7

Delay [msec]

80

Simulation Time [sec](a) コネクション数が 1 である場合

6
5
4
3

3.5
3
2.5
2
1.5

2

1

1

0.5

0

0
0

20

40

60

80

100

120

140

160

180

200

0

20

40

Simulation Time [sec]delay_data_mac

60

80

100

120

140

160

Simulation Time [sec]delay_ack_mac

delay_data_mac(c) コネクション数が 4 である場合

delay_ack_mac(d) コネクション数が 8 である場合

35

8

30

7
6

25

Delay [msec]

Delay [msec]

60

20
15
10

5
4
3
2

5

1

0

0
0

20

40

60

80

100

120

140

160

180

200

Simulation Time [sec]delay_data_mac

0

20

40

60

80

100

120

140

160

Simulation Time [sec]delay_ack_mac

delay_data_mac(e) コネクション数が 16 である場合

delay_ack_mac(f) コネクション数が 32 である場合

図 19: 有線区間にボトルネックがある場合の無線区間の遅延変動 (AReno，伝搬遅延:
100 [msec])

40

4500

3500

4000

Number of Packets
in Wireless LAN [pkts]

Number of Packets
in Wireless LAN [pkts]

4000

3000
2500
2000
1500
1000
500
0

3500
3000
2500
2000
1500
1000
500
0

0

20

40

60

80

100 120 140 160 180 200

0

20

40

Simulation Time [sec]total
data_packets

ack_packets

100 120 140 160 180 200
ack_packets(b) コネクション数が 2 である場合

4500

4500

4000

4000

Number of Packets
in Wireless LAN [pkts]

Number of Packets
in Wireless LAN [pkts]

80

total
data_packets(a) コネクション数が 1 である場合

3500
3000
2500
2000
1500
1000
500
0

3500
3000
2500
2000
1500
1000
500
0

0

20

40

60

80

100 120 140 160 180 200

0

20

40

Simulation Time [sec]total
data_packets

60

80

100 120 140 160 180 200

Simulation Time [sec]ack_packets

total
data_packets(c) コネクション数が 4 である場合

ack_packets(d) コネクション数が 8 である場合

4500

4500

4000

4000

Number of Packets
in Wireless LAN [pkts]

Number of Packets
in Wireless LAN [pkts]

60

Simulation Time [sec]

3500
3000
2500
2000
1500
1000
500
0

3500
3000
2500
2000
1500
1000
500
0

0

20

40

60

80

100 120 140 160 180 200

Simulation Time [sec]total
data_packets

0

20

40

60

80

100 120 140 160 180 200

Simulation Time [sec]ack_packets

total
data_packets(e) コネクション数が 16 である場合

ack_packets(f) コネクション数が 32 である場合

図 20: 有線区間にボトルネックがある場合の無線区間に送出されるパケットの総数の変化(AReno，伝送遅延: 100 [msec])41

次に，図 18 のネットワーク環境において，CTCP のシミュレーション結果を図 21 に，ARenoのシミュレーション結果を図 21 に示す． 図 21 および図 22 をみると，前述のとおり有線区
間にボトルネックがある場合は無線区間における遅延変動が小さいことがわかる．また，2.3
節で述べたように，CTCP は式 (5) の RTT 情報として，1 RTT 内に観測した最小の RTT である minRT T を用いる．このため，1 RTT 以上の間，無線区間の遅延変動による RTT の増加が継続されなければ，minRT T に影響を与えない．このため，図 21(a) のように RT Tには無線区間の遅延変動による影響が現れているが，minRT T には影響はなく，さらには
輻輳ウィンド ウサイズの増減に対しても影響がないといえる．

2.4 節で述べたとおり，AReno は式 (8) に用いる RTT 情報として，TCP が管理している
平滑下 RTT である sRT T を用いているが，図 22(b) のように，無線区間の遅延変動が 最大で 2.5 [msec] と sRT T の値より相対的に小さく，それをさらに平滑化するため，図 22(a) において，輻輳ウィンド ウサイズの増減に対してほとんど 影響がないといえる．また，FAST

TCP の場合は，AReno より重みが大きな式 (4) を用いているため，AReno のよりさらに影響が出にくいと考えられる．
以上の結果と，3.1 節の結果から，無線端末が TCP の送信側であるときには，無線区間にボトルネックがある場合は，無線端末の送信バッファに蓄積されるパケットにより無線区間
における遅延変動による影響が抑えられ，有線区間にボトルネックがある場合は，無線区間における遅延変動の幅が無線区間がボトルネックである場合より小さく，各 TCP 改良手法
で用いられている RTT 情報のフィルタリング処理により遅延変動の抑えられるため，TCP
スループットに与える影響は小さい，ということが明らかとなった．

42

160
155
150
145
140
135
130
125
120
115
110
105
100

Window Size [pkts]

240
230
220
210
200
190
180
170
160
36

38

40

42

44

46

48

Time [msec]

250

50

Simulation Time [sec]
cwnd

RTT

minRTT(a) 輻輳ウィンド ウサイズの変化

3

Delay [msec]

2.5
2
1.5
1
0.5
0
36

38

40

42

44

46

48

50

Simulation Time [sec]delay_data
delay_data_mac

delay_ack_mac(b) 無線区間における遅延変動

図 21: IEEE 802.11a を用いた場合におけるシミュレーション結果 (CTCP，コネクション数:
1，伝搬遅延: 50 [msec])

43

120
118
116
114
112
110
108
106
104
102

Round Trip Time [msec]

Window Size [pkts]

210
200
190
180
170
160
150
140
130
120
110
100

100
34

36

38

40

42

44

Simulation Time [sec]
cwnd

sRTT

(a) 輻輳ウィンド ウサイズの変化

3

Delay [msec]

2.5
2
1.5
1
0.5
0
34

36

38

40

42

44

Simulation Time [sec]delay_data
delay_data_mac

delay_ack_mac(b) 無線区間における遅延変動

図 22: IEEE 802.11a を用いた場合におけるシミュレーション結果 (AReno，コネクション数:
1，伝搬遅延: 50 [msec])44

4 まとめと今後の課題
本報告では，ns-2 を用いたシミュレーションを行うことにより，無線 LAN 環境がさまざ
まな TCP 改良手法へ与える影響を検証するとともに，RTT を輻輳の指標として用いる TCP
改良手法の，無線 LAN 環境における有効性を評価した．
シミュレーション結果から，無線区間がボトルネックとなる場合においては，無線区間の遅延変動が大きくなるものの，TCP スループットに対してほとんど 影響を与えないことがわかった．また，有線区間がボトルネックとなる場合においては，無線区間の遅延変動が小さくなるため，各 TCP 改良手法で用いられている RTT 情報のフィルタリング処理により無線区間の遅延変動の影響が抑えられ，輻輳ウィンド ウおよびスループットにほとんど 影響を与えないことがわかった．以上から，本報告において対象にしたネットワーク環境においては，RTT を輻輳の指標として用いる TCP 改良手法は，無線 LAN 環境下でも正常に動作するということがいえる．
一方で，無線区間がボトルネックとなる場合においては，無線端末が増え，TCP コネク
ションが増加すると，無線アクセスポイントにおいて ACK パケットがバッファ溢れを引き起こし，TCP コネクション間に深刻な不公平が発生することが明らかとなった．
今後の課題として，無線端末が受信側となる場合および上りと下りのコネクションが混在する場合における性能評価や，本報告において指摘した，各 TCP コネクション間に深刻な不公平が発生する問題に対しての対策の提案が挙げられる．

45

謝辞
本報告を終えるにあたり，御指導，御教授を頂きました中野博隆教授，村田正幸教授に深く感謝致します．また，本報告を作成するにあたり，日頃から熱心かつ的確な指導および助言をして頂きました長谷川剛准教授に心より感謝致します．最後に，日頃の研究生活を送るにあたり，相談に答えて頂きました平岡祐一朗氏，児玉瑞穂氏および堀江拓郎氏をはじめとする中野研究室の皆様方，また，津川知朗氏をはじめとする村田研究室の皆様方に心より御礼申し上げます．

46

参考文献[1] W. R. Stevens and G. R. Wright, TCP/IP Illustrated, Volume 2 : The Implementation.
Addison-Wesley, 1995.
[2] S. Floyd, “HighSpeed TCP for large congestion windows,” Request for Comments 3649
(Experimental), Dec. 2003.
[3] C. Jin, D. X. Wei, and S. H. Low, “FAST TCP: Motivation, architecture, algorithms, performance,” in Proceedings of IEEE INFOCOM 2004, Mar. 2004.
[4] K. Tan, J. Song, Q. Zhang, and M. Sridharan, “Compound TCP: A scalable and TCP-friendly
congestion control for high-speed networks,” in Proceedings of PFLDnet 2006, Feb. 2006.
[5] H. Shimonishi, T. Hama, and T. Murase, “TCP-Adaptive Reno: Improving efﬁciencyfriendliness tradeoffs of TCP congestion control algorithms,” in Proceedings of PFLDnet
2006, Feb. 2006.
[6] I. Rhee and L. Xu, “CUBIC: A new TCP-friendly high-speed TCP variant,” in Proceedingsof PFLDnet 2005, Feb. 2005.
[7] T. Kelly, “Scalable TCP: Improving performance in highspeed wide area networks,” ACM
SIGCOMM Computer Communication Review, vol. 33, pp. 83–91, Apr. 2003.
[8] 長谷川 剛，村田 正幸, “高速・高遅延ネットワークのためのトランスポート層プロトコル ,” 電子情報通信学会技術研究報告 (IN2006-169), vol. 106, pp. 41–46, Jan. 2007.

[9] L. S. Brakmo and L. L. Peterson, “TCP Vegas: End to end congestion avoidance on a global
Internet,” IEEE Journal on Selected Areas in Communications, vol. 13, no. 8, pp. 1465–1480,
1995.
[10] H. Shimonishi, M. Sanadidi, and T. Murase, “Assessing interactions among legacy and highspeed TCP protocols,” in Proceedings of PFLDnet 2007, pp. 91–96, Feb. 2007.
[11] IEEE 802.11b, Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer(PHY) speciﬁcations: Higher-Speed Physical Layer Extension in the 2.4 GHz Band. IEEE,
Feb. 1999.

47

[12] IEEE 802.11a, Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer(PHY) speciﬁcations High-speed Physical Layer in the 5 GHz Band. IEEE, Feb. 1999.
[13] V. Tsaoussidis and I. Matta, “Open issues on TCP for mobile computing,” Wireless Communications and Mobile Computing, vol. 2, pp. 3–20, Feb. 2002.
[14] C. Casetti, M. Gerla, S. Mascolo, M. Y. Sanadidi, and R. Wang, “TCP Westwood: Bandwidth
estimation for enhanced transport over wireless links,” in Proceedings of ACM Mobicom
2001, pp. 287–297, July 2001.
[15] K. Xu, Y. Tian, and N. Ansari, “TCP-Jersey for wireless IP communications,” IEEE JSAC,
vol. 22, pp. 747–756, May 2004.
[16] “The network simulator ns-2.” available at http://www.isi.edu/nsnam/ns/.
[17] “FAST TCP simulator module for ns-2.” available at http://www.cubinlab.ee.mu.
oz.au/ns2fasttcp/.
[18] G. Hasegawa, K. Kurata, and M. Murata, “Analysis and improvement of fairness between
TCP reno and vegas for deployment of TCP vegas to the Internet,” in Proceedings of IEEE
ICNP 2000, Nov. 2000.
[19] “Compound TCP in Linux.” available at http://netlab.caltech.edu/lachlan/
ctcp/.
[20] D. X. Wei and P. Cao, “A Linux TCP implementation for NS2.” available at http://www.
cs.caltech.edu/∼weixl/technical/ns2linux/index.html, May 2006.

48