DEIM Forum2015 C2-2

無線LAN-APにおけるTCP ACKパケット蓄積回避のための協調的輻輳制御手法の提案と実装

早川 愛† 山口 実靖†† 小口 正人†

†お茶の水女子大学 〒 112-8610東京都文京区大塚 2-1-1

††工学院大学 〒 163-8677　新宿区西新宿 1-24-2

E-mail: †ai@ogl.is.ocha.ac.jp,††sane@cc.kogakuin.ac.jp,†††oguchi@computer.org

あらまし 近年のロスベース TCPはより高いスループットを確保するためにアグレッシブな輻輳制御手法を用いてい

るが，有線接続と比べて脆弱な無線接続環境においては，その手法によって膨大なパケットが蓄積されたり，その結

果ロスしたりしてしまうという問題が生じている．本研究では，そのロスベース TCPの一つである TCP CUBICを輻

輳制御アルゴリズムとして使用している Android端末を用いて，無線 LAN アクセスポイントにおける ACK パケット

の蓄積を回避する協調的制御手法の提案と実装を行う．本手法では，同一アクセスポイントに接続された端末数とそ

のネットワークの混み具合を示す往復遅延時間の二つのパラメータにより，各端末の最大輻輳ウィンドウ値を補正す

る．それにより，アクセスポイントでの ACKパケットの蓄積を防ぎ，かつ端末間で可用帯域を公平に分け合うことで

全体の通信速度を最大で約 3.35倍，公平性を約 1.16倍向上させることを可能にしている．

キーワード TCP,輻輳制御

Suggestion and Implementation of the Cooperative Congestion Control

Mechanism for Reducing the TCP ACK Packet Backlog

at the WLAN Access Point

Ai HAYAKAWA †, Saneyasu YAMAGUCHI††, and Masato OGUCHI†

† Ochanomizu University　 2-1-1 Otsuka, Bunkyou-ku, Tokyo, 112-8610, JAPAN

†† Kogakuin University　 1-24-2 Nishi-shinjuku, Shinjuku-ku, Tokyo,163-8677, Japan

E-mail: †ai@ogl.is.ocha.ac.jp,††sane@cc.kogakuin.ac.jp,†††oguchi@computer.org

Key words TCP，Congestion control

1. は じ め に

輻輳制御方式には，ロスベース方式，遅延ベース方式とその

二つを複合させたハイブリット方式がある．その中でも近年の

ロスベース TCPはより高いスループットを確保するためにア

グレッシブな輻輳制御手法を用いている．しかしながら，比較

的強く安定したコネクションを持つ有線接続と比べて低帯域で

ノイズの影響を受けやすい脆弱な無線接続環境においては，特

に同一アクセスポイント (AP)に接続する端末台数が多い場合

は APの通信機会が減ってしまうため，その手法によって AP

に膨大な ACK パケットが蓄積されてしまう．それにより，端

末と AP間において頻繁にパケットロスやタイムアウト，輻輳

が発生してしまい，エンドホスト側の端末は十分な通信速度を

得ることができないという問題点がある．

そこで本研究では，そのような問題を引き起こすロスベース

TCPの一つである TCP CUBICを輻輳制御アルゴリズムとして

使用している Android端末を用いて，無線 LAN-AP における

ACK パケットの蓄積を回避するための協調的制御手法の提案と

実装を行う．本手法では，同一 APに接続された端末数と現在

のトラフィックの混み具合を示す往復遅延時間 (RTT)の二つの

パラメータをリアルタイムに観測することで，そのネットワー

ク環境における理想的な輻輳ウィンドウ値 (CWND)をシステ

ムが自動で算出し，各端末の最大の CWNDとして補正を行う．

それにより，APでの ACK パケットの蓄積を回避し，かつ端末

間で可用帯域を公平に分け合うことで全体の通信速度と公平性

を向上させることを目指す．

2. 研 究 背 景

2. 1 Android OS

本研究では，Androidプラットホーム上で動作するシステム

の開発を行う．Android [1]は Google社が開発したモバイル端

末用プラットフォームであり，オープンソースであることから

誰でも自由にカスタマイズできるという特徴がある．

さらに，linuxカーネルがベースとなっており，ロスベース方

式の TCP CUBIC [3]を輻輳制御アルゴリズムとして採用してい

る．TCP CUBICは TCP BIC [2]の改良版であり，ウィンドウ制

御を単純かつ高度化するように設計されている．TCP CUBIC

の増加関数は式 1で定義される．Cはスケールファクター，tは

最後にパケット廃棄が発生した時点からの経過時間，Wmax は

最後にパケット廃棄が発生した時点のウィンドウサイズである．

Wcubic = C(t− 3

√Wmaxβ

C)3 +Wmax (1)

実際の TCP CUBICの振舞いを図 1に示す．縦軸は CWND

横軸が時間で，パケットロスを検出したときウィンドウサイズ

を減少させ，最後のパケット廃棄が発生してからの経過時間を

元に三次関数的にウィンドウサイズを増加させる．TCP CUBIC

では，遅延ベース方式のものと比べて各端末が通信経路の状

況を把握しないため，パケットロスが生じるまで各端末がアグ

レッシブに通信しすぎる傾向にある．それにより，特に同時に

通信する端末数が多いときには APで ACK パケットが蓄積し

やすく，タイムアウトや再送が生じてしまい，エンドホスト側

の端末は十分な通信速度を得ることができないという問題点が

ある．

図 1 TCP CUBICの振舞い

2. 2 輻輳制御ミドルウェア

先行研究 [4] で開発された輻輳制御ミドルウェアは，同一 AP

に接続した端末間でお互いの接続状況を把握し，その接続台数

によって混み具合を予測し，CWNDの上限値を設定する組込み

システムである．可用帯域を公平に分け合うことで，全体の通

信速度と公平性の向上に成功している．しかしながら，この先

行研究における CWNDの補正値は経験則により決め打ちの値

が用いられていたため，必ずしも最適に補正が行われていると

は限らず，さらにシステム環境が変わるとその補正値自体を決

め直さなければならないという問題点がある．本研究ではそれ

らの問題点を解決し，本システムのさらなる性能と利便性の向

上を目指す．

2. 3 カーネルモニタリングツール

カーネル内部の処理は，通常バックグラウンドで進められて

いるため，通常ユーザ空間からその処理を監視することはでき

ない．近年，汎用 PC向け Linuxディストリビューションにお

いては，TCP Probe [5]が利用できる場合もあるが，Androidに

おいてはサポートされていない．そこで本研究では，カーネル

内部の通信処理を解析するために，カーネルモニタを利用する．

カーネルモニタとは，Linuxシステムのカーネル内部の処理を

解析する汎用 PC向けシステムツールである．既存研究 [6] は，

既にカーネルモニタの Androidへの組込みに成功しており，同

様の方法で導入を行った端末を本研究においても利用する．図

2にその概要を示す．カーネルモニタは，通信時におけるカー

ネル内部のパラメータ値の変化を記録することが可能である．

カーネル内部の TCPソースにモニタ関数を挿入し再コンパイ

ルすることで，輻輳ウィンドウ値やソケットバッファのキュー

長，各種エラーイベントの発生タイミングなどの TCPパラメー

タを見ることができる．このツールを用いることで，本システ

ムにおいてもカーネル内のパラメータをリアルタイムに解析す

ることができる．

図 2 カーネルモニタの概要

3. 提 案 手 法

第 2. 2章で述べたように，先行研究で開発されたシステムで

はある特定した環境でのみ適応する値に固定された CWNDの

補正値を用いていた．さらに，トラフィックの状況を判断する

パラメータが通信端末数のみであったため，通信経路の混み具

合をより詳細に把握するために追加の情報を用いることで，性

能向上が実現できると考えられる．そこで本研究では，RTTの

増加が通信速度の低下に影響するという知見 [7] から RTTの増

減比率を観察することでトラフィックの状況を把握し，通信端

末数と RTTの増減比率の二つのパラメータを用いて，その環

境にあった CWNDの補正値を自動で算出するシステムを構築

した．

本研究における提案手法の概要を図 3に示す．具体的な制御

としてはまず，先行研究と同様に UDPパケットを 0.3秒ごとに

ブロードキャストすることで，周辺端末に自端末の通信状況を

通知する．それと同時に IPアドレスで固有化した周囲からの

UDPパケットを受け取り，接続端末数を把握する．その情報を

用いて CWNDを補正するのだが，本研究ではその補正値を本

システムが自動で算出するために CWNDの理想値を示す式 2

を用いた．また，先行研究 [8] において帯域幅は接続台数に伴

い変化することが確認されているので，帯域幅に関しては，式

3のように計算した値を用いている．ただし，BWmaxはその

通信環境における最高通信速度である．f(端末数)は端末数の増

加による合計通信速度の低下を表す単調減少の関数であり，先

行研究 [8] を元に式 4とした．

Ideal cwnd =Bandwidth[Mbps]×RTT [sec]

Segmentsize(1.5Kbyte)×端末数(2)

Bandwidth = BWmax× f(端末数) (3)

f(端末数) =端末数−0.15 (4)

図 3 提案手法の概要

これらの式を用いて算出された CWND値を，プロセスイン

ターフェースに CWNDの最大値として 0.5秒ごとに書き込み

補正する．さらに，通信中はカーネルモニタを 0.5秒単位で常

時監視し，RTTとその最小値 (min-rtt)を取得する．min-rttは，

通信中で最も小さい RTTを常に上書きしていくことで値を更

新する．取得した値をもとに式 5を用いて RTTの増減の比率

(ratio rtt)を求める．

ratio rtt =RTT

min rtt(5)

この ratio rttが 6.0以上になると，トラフィックが混んできたと

みなし，式 2を用いた端末数による CWNDを補正するフェー

ズに切り替わる．また，その補正をした上でも RTTが増加し

てしまう場合においては，ratio rttが 5.0以上になると CWND

を 1にして一時的に通信最小モードに移行し，その後に起こり

得るさらなる遅延を回避する．

これらの制御によって，通信中においても同じ APを共有す

る他端末が通信を始めたことやそれに伴って急に RTTの値が増

加したことを本システムが検知すると，リアルタイムに CWND

を適切な値に補正することでトラフィック発生量を制限し，途

中から通信を始めた端末にも均等に帯域を分け合えるよう制

御することができる．さらに本システムにおいては，基本的な

TCPの輻輳制御アルゴリズムは変更しておらず，これはデフォ

ルト時同様に機能している．ただし，AP周りの通信状況に基

づき，問題が発生した場合にのみ迅速に対応することで，通信

の最適化を実現する．

4. 提案手法の性能評価

4. 1 実 験 概 要

図 4と表 1に示す環境において，Android端末 10台に本提案

ミドルウェアを導入したときの，本提案手法の評価実験を行っ

た．本実験環境における BWmaxは，1.9× 103 である．APと

サーバ機の間には，人工遅延装置 Dummynet [9]を挟み，有線

部の往復遅延時間を特に輻輳が生じやすい高遅延環境を模擬す

るために 256msに設定している．この環境において，Iperf [10]

を用いて通信スループットを測定した．

図 4 実験トポロジ

表 1 実 験 環 境Android Model number Nexus S

Firmware version 4.1.1

Baseband version I9023XXKD1

Kernel version 3.0.31-ai

Build number JRO03L

server OS Ubuntu 12.04 (64bit) / Linux 3.0.1

CPU Intel(R) Core 2Quad CPU Q8400

Main Memory 7.8GiB

AP Model MZK-MF300N(Planex)

Sommunication systemIEEE 802.11g

4. 2 実 験 結 果

合計の通信速度の評価結果を図 5に示す．青のグラフは，補

正を行わないデフォルトの状態で，赤のグラフは本提案手法に

よる補正を行った結果である．グラフより，RTTの増加が観測

されたと考えられる 4台以降において本提案手法による性能向

上が確認され，最大で 10台の端末が同時に通信するときの通

信速度は約 3.35倍向上した．

図 5 合計通信速度

この時の CWNDの時間遷移を図 6に示す．1台から 3台まで

は，帯域に余裕があり ratio rttの値が 6.0以下なので補正が行

わていないが，4台で通信中に APの負荷が増加し，ratio rttが

6.0を超えると本提案手法による補正が行われ，算出された上

限値以下に制御されていることが分かる．さらに，図 7の RTT

の時間遷移に示すように，補正が行われた 5台目以降では RTT

の増加が観測されていないことから，全体のトラフィックがス

ムーズになり APへの負荷が削減されたことが確認できる．

図 6 CWNDの振舞い

図 7 ratio rtt の振舞い

次に，FairnessIndex [11]を用いて通信時における公平性の評

価を行った (図 8)．Fairness Indexとは，公平性を示す指標であ

り，式 6で算出された値が 1に近いほど高い公平性を示す．

FairnessIndex : fi =(∑k

i=ixi)

2

k∑k

i=ixi

2(1 <= i <= k) (6)

青のグラフに示す本提案手法を用いない場合には，同時通信

台数が多くなるほど公平性が損なわれているが，それに対し，

本提案手法を適応した赤のグラフでは台数が 10台まで増加し

てもほぼ 1の値を維持し，デフォルトの状態よりも約 1.16倍値

が向上している．つまり本提案手法を用いることで，公平性が

向上することを確認した．

図 8 公平性の評価

5. 未実装端末と混在する場合の評価

5. 1 実 験 概 要

第 4.1章では，全ての端末が輻輳制御を補正した時の通信性

能を測定したが，現実世界においては，本提案ミドルウェアが

普及していく過程において，標準 TCPを利用する端末と APを

共有することは避けられない．よって本章では，同一 APを共

有する端末間において，本提案ミドルウェアを持たない端末が

混在する場合に，各端末と全体の通信性能にどのような影響を

及ぼすかについての実験を行った．

5. 2 実 験 結 果

本環境においては，ミドルウェアが有効になるのは，同時通

信台数 4台以降であるので，4，7，10台における測定結果を

図 9，図 10，図 11に示す．赤いグラフが本提案ミドルウェア

を導入していない端末の平均通信速度，緑のグラフが本提案手

法を導入した端末の平均通信速度，青いグラフが両者の合計通

信速度を表している．グラフより，本提案手法を導入する端末

が 1台でも存在すれば，補正を全く行わないデフォルトの状態

よりも合計通信速度は向上していることが分かる．また，ミド

ルウェアを導入している端末は CWNDの上限を定められてい

ることにより，導入していない端末と比べて非積極的な通信を

行うため，平均通信速度では特に，補正をしない端末が 1台の

時はデフォルトの方が多く上回っている．しかしながら，その

1台のみが補正を行わないという場合を除けば，全ての端末が

本手法による補正を加えたときには，加えない時と比べて平均

通信速度は向上しているため，本手法を用いることのメリット

は十分大きいはずである．さらに，10台同時通信時における公

平性を図 12に示す．10台中 1台のみが未実装の場合，公平性

が大幅に損なわれているのが分かる．本提案手法は同一 APに

接続するすべての端末で公平に可用帯域を分け合うことを目的

としているため，そのすべての端末が本手法を用いるような方

法を考えなければならない．その一つの案として，例えば AP

を提供する側が本手法を用いる端末にのみパスワードを提示す

るなどのような手法を導入すれば実現可能である．

図 9 4台通信時における評価

図 10 7台通信時における評価

図 11 10台通信時における評価

図 12 10台通信時における公平性

6. 端末数変化時の評価

6. 1 実 験 概 要

　第 4.1章および第 4.2章では，通信台数を固定にした状態

で評価実験を行った．しかしながら，実環境ではモバイル端末

は移動することから，頻繁にハンドオーバや通信のオンオフを

繰り返す．それにより，同一 APに接続されるアクティブな通

信端末台数が動的に変動する可能性が考えられる．そこで本章

では，通信中に接続端末数が変化する状況において本提案手法

の評価を行った．今回は，図 13と図 14に示すように，通信端

末数が増加する場合と減少する場合の二つのモデルを用いた．

通信端末が増加する場合では，本研究における実験環境におい

て本提案ミドルウェアが有効化されると考えられる，4台同時

通信状態からスタートし，その後 20秒ごとに 1台ずつアクティ

ブ端末が増えていくモデルである．一方で，通信端末が減少す

る場合では，逆にアクティブな端末が 20秒ごとに減っていく

モデルである．尚，通信端末数が頻繁に変動する場合において

は，通信台数が固定となっている状態よりも，RTTの増減が頻

繁に生じることが考えられる．そこで，本提案手法の一つであ

る，ratio rttが 5.0以上になると CWNDを 1にして一時的に通

信停止モードに移行する手法の効果を検証するため，本提案ミ

ドルウェアの導入しないデフォルト時との比較に加え，ratio rtt

による制御のみを除去した提案ミドルウェア導入時との比較も

同時に行った．

図 13 通信端末が増加する場合のモデル

図 14 通信端末が減少する場合のモデル

6. 2 実 験 結 果

図 15に示すのは，本提案ミドルウェア未導入時 (baseline)，

本提案手法導入時 (proposed)，本提案手法の RTTによる制御

を排除したミドルウェア導入時 (without RTT)の合計通信速度

である．グラフより，通信端末が増加する場合においては，本

提案ミドルウェアを導入することで，本提案手法未導入時に比

べて 1.36倍，RTTによる制御なしの場合より 1.05倍通信速度

が向上することを確認した．一方，通信端末が減少する場合に

おいても，同様にそれぞれ 1.57倍，1.34倍向上することが分

かった．

また，各端末における通信速度の平均値を図 16，図 17に示

す．すべての端末において，本提案手法を導入した場合の方が，

未導入時に比べて通信速度が向上していることが分かる．ただ，

RTTによる制御を除いた場合と本手法を比較すると，通信時間

が短い端末，つまり増加する場合では，node 9，node 10，減少

する場合では node 1，node 2においては，全体の通信時間のう

ちの RTTによる制御によって CWNDが抑えられる時間が占め

る割合が多いため，RTTによる制御も含めた本提案手法の方が，

若干通信速度が低下している．しかしながら，長く通信する端

末においては，RTTの増加を緩和することができる本提案手法

により効果的に RTTの増加が抑えられ，各端末の平均通信速

度は向上することを確認した．

図 15 合計通信速度

図 16 端末増加時における各端末の合計通信速度

図 17 端末減少時における各端末の合計通信速度

さらに，このときの CWNDの時間遷移を，本提案ミドルウェ

ア未導入時 (baseline)，本提案手法導入時 (proposed)，本提案手

法の RTTによる制御を排除したミドルウェア導入時 (without

RTT)の通信端末が増加する場合と減少する場合のそれぞれに

ついて，図 18，図 19，図 20，図 21，図 22，図 23に示す．本

提案ミドルウェア未導入の図 18と図 21では，CWNDの上限

値が制御されていないので各端末が大きなパケットを送り続け

ている様子が分かる．それに対し，本提案手法を用いた図 19，

図 20および図 22，図 23では，帯域幅遅延積から算出された値

を CWNDの上限値として制御されており，特に図 19と図 22

では，RTTの増減による制御により通信停止モードに移行する

端末の様子が確認できる．以上の評価より，本提案手法は通信

中に接続端末数が動的に変動する場合においても，その接続台

数を常時正確に把握し，適切な CWNDを算出し，制御するこ

とが可能であることを示した．さらに，RTT比率の著しい増加

が観測された場合に発動する通信停止モードの効果を確認した．

図 18 端末増加時における CWNDの遷移 (baseline)

図 19 端末増加時における CWNDの遷移 (proposed)

図 20 端末増加時における CWNDの遷移 (without RTT)

図 21 端末減少時における CWNDの遷移 (baseline)

図 22 端末減少時における CWNDの遷移 (proposed)

図 23 端末減少時における CWNDの遷移 (without RTT)

7. 関 連 研 究

TCPでは，基本的にはパケット損失がネットワーク輻輳を

指し示していると想定されているが，そのパケット損失の主な

原因としては，他のコミュニケーションピアへの経路に沿った

ルータにおいてキューがオーバーフローを起こすことであると

考えられる．しかしながら，無線通信においてはパケット損失

の他の原因として，フェ－ジングや衝突，干渉なども考えられ，

それらは TCP輻輳制御アルゴリズムでは下位層で生じた問題

であるかどうかの区別がつかない．TCP性能における無線区間

のそれらの効果は，[12] [13] [14] [15]によって広範囲にわたって

研究され続けてきた．

輻輳を回避する手段として，Explicit Congestion Notifica-

tion [16]は経路上の不特定の地点においてパケットにビット

を立てることで輻輳状態を通知する．また Active Queue Man-

agement [17]や Random Early Detection [18]は，輻輳崩壊が起

きる前に，ルーティング機器上で意図的にパケットを損失させ

る仕組みである．これらの仕組みは差し迫った輻輳に備えて，

セグメント送出量を減らすタイミングを検出する．しかし，こ

れらの仕組みは，経路上の全てのネットワーク機器が対応する

時のみ効果的であることから，通信インフラを新規に導入する

必要があるためコストが大きく，実際に導入が進んでいない．

我々の先行研究も輻輳を回避する手法の一つであるが，その

仕組みとしては，同一 APに接続する端末数のみにおいて全体

のトラフィックを把握し，可用帯域を公平に分け合うという手

法であり，本提案手法のように実際のネットワークトラフィッ

クの混み具合を示す RTTは制御パラメータとして用いておら

ず，常に正確にネットワーク状況を把握しきれていたとは限ら

ないという点で，本研究とは異なる．さらに，先行研究との大

きな差分として，先行研究では CWNDの補正値を経験則によ

り決めうちの値を用いて，ある特定の実験環境にのみ対象にし

ていたが，本研究では，ユーザが使用するネットワーク環境と

して，最大の帯域幅である BWmaxを指定さえすれば，本シス

テムが自動で補正値を算出し，適応させることが可能である．

8. まとめと今後の課題

本研究では，ロスベース TCPを使用する端末が多数台同時

に通信する場合において，APに ACK パケットが蓄積し輻輳を

起こす問題を回避するために，先行研究によって開発された輻

輳制御ミドルウェアの改変と高機能化を行った．具体的には，

同一 APに接続する端末間で通信状況を通知し合い，その接続

端末数と RTTによる混み具合を把握することで，自動的にそ

の通信環境にあった CWNDを各端末ごとに協調的に補正する

手法を提案し，実装を行った．本提案手法を用いることで，10

台で同時に通信するときの通信速度が約 3.35倍，公平性が約

1.16倍向上することを確認した．また，本提案ミドルウェアを

持たない端末が混在している環境下においても，本提案手法に

よる CWNDの補正を行う端末が 1台以上存在すれば，すべて

の端末が本提案手法を用いない場合よりも全体の通信速度を向

上させることが分かった．さらに，通信中に接続端末数が変動

する場合においては，端末が増加する場合にはデフォルト時よ

りも 1.36倍，減少する場合には 1.57倍，全体の通信速度が向

上することを確認した．

今後の課題としては，本実験環境で用いた無線 LAN AP は，

IEEE802.11b/gによって定義されるデータレートのみをサポー

トしているため，IEEE802.11nや IEEE802.11acのようなより広

範囲のデータレートを提供する近年の APを用いた場合におけ

る，本提案手法の評価を行いたい．また，本稿における提案手

法の評価として，エンドユーザはすべてベンチマークツールを

利用し，アップリンクにより比較的大きなデータ転送をする場

合の評価を行ったが，実際には，それほど帯域を必要としない

メール送信などの低トラフィックな通信を行う端末も存在する

と考えられる．本提案手法では，エンドユーザの通信の種類に

関わらず，すべての端末に公平に帯域を割り当てるため，この

ような場合には低トラフィックな端末に十分すぎる帯域が割り

当てられてしまい，かえって未使用帯域を残してしまう可能性

がある．そこで，各ユーザごとの通信需要により，帯域割り当

てを行うことで，より効果的な制御ができるのではないかと考

えられる．さらに，本提案手法で自動で算出される帯域幅遅延

積は，そのネットワーク環境における最大の帯域幅と有線部に

かかる往復遅延時間との積で求められるが，このどちらか，あ

るいは両方が極端に小さい環境で通信する端末が存在した場合，

本手法において割り当てられる帯域が他端末と比べて大幅に小

さくなる可能性がある．その場合，本提案手法の性能評価で示

した公平性の向上は必ずしも担保できるとは限らない．よって，

そのような場合の評価と制御方法を検討する必要がある．

謝 辞

本研究を進めるにあたり，ご協力賜りました大阪大学/UCLA

の高井峰生先生に深く感謝致します．

文 献[1] Android open source project, http://source.android.com[2] L. Xu, K. Harfoush, and I. Rhee, ”Binary Increase Congestion Con-

trol for Fast, Long Distance Networks,” Proceedings of Tech. Report,Computer Science Department, NC State University, 2003.

[3] Sangtae Ha, Injong Rhee and Lisong Xu ”CUBIC: a new TCP-friendly high-speed TCP variant” ACM SIGOPS Operating SystemsReview - Research and developments in the Linux kernel, vol.42,pp.64-74, July 2008.

[4] Hiromi Hirai, Saneyasu Yamaguchi, and Masato Oguchi: ”A Pro-posal on Cooperative Transmission Control Middleware on a Smart-phone in a WLAN Environment,” In Proc. the 9th IEEE InternationalConference on Wireless and Mobile Computing, Networking andCommunications (WiMob2013), pp.710-717, October 2013.

[5] http://www.linuxfoundation.org/collaborate/workgroups/networking/tcpprobe[6] Kaori Miki, Saneyasu Yamaguchi, and Masato Oguchi: ”Kernel

Monitor of Transport Layer Developed for Android Working on Mo-bile Phone Terminals,” Proceedings of The Tenth International Con-ference on Networks (ICN), pp. 297-302. 2011.

[7] Ai Hayakawa, Saneyasu Yamaguchi, Masato Oguchi: ”Reducing theTCP ACK Packet Backlog at the WLAN Access Point” In Proc. the9th ACM International Conference on Ubiquitous Information Man-agement and Communication (IMCOM2014), 5-4, Bali, Indonesia,January 2015.

[8] Makiko Matsumoto and Masato Oguchi: ”Multiple Access in MACLayer Based on Surrounding Conditions of Wireless Stations” In

Proc. the 1st International Workshop on Vehicular Communicationsand Applications (VCA2012) in conjunction with the 11th AnnualMediterranean Ad Hoc Networking Workshop (Med-Hoc-Net2012),pp.133-140, Ayia Napa, Cyprus, June 2012.

[9] The dummynet project: http://info.iet.unipi.it/ luigi/dummynet[10] Iperf:http://downloads.sourceforge.net/ project/iperf/iperf/2.0.5[11] D.-M. Chiu and R. Jain,“Analysis of the increase and decrease algo-

rithms for congestion avoidance in computer networks,”ComputerNetworks and ISDN Systems, vol. 17, pp. 1-14, 1989.

[12] Prasun Sinha, Thyagarajan Nandagopal, Narayanan Venkitaraman,Ragupathy Sivakumar, Vaduvur Bharghavan : ”WTCP:a reliabletransport protocol for wireless wide-area networks” Wireless Net-works - Selected Papers from Mobicom’99 archive, Volume 8 Issue2/3, March-May 2002, pp. 301-316

[13] Claudio Casetti, Mario Geria, Saverio Mascolo, M.Y.Sanadidi,Ren Wang: ”TCP westwood: end-to-end congestion control forwired/wireless networks” Wireless Networks archive, Volume 8 Is-sue 5, September 2002, pp. 467 - 479

[14] Luigi A. Grieco and Saverio Mascolo: ”Performance Evaluationand Comparison of Westwood+, New Reno, and Vegas TCP Con-gestion Control,” ACM SIGCOMM Computer Communications Re-view, Vol.34, No.2, pp.25-38, April 2004.

[15] Shao Liu, Tamer Basar, R.Srikant: ”TCP-Illinois: a loss and delay-based congestion control algorithm for high-speed networks” value-tools ’06 Proceedings of the 1st international conference on Perfor-mance evaluation methodolgies and tools, Article No. 55.

[16] Floyd, Sally. ”TCP and explicit congestion notification,” ACM SIG-COMM Computer Communication Review 24, no. 5 : 8-23, 1994.

[17] Firoiu, Victor, and Marty Borden. ”A study of active queue man-agement for congestion control,” Proceedings of IEEE InternationalConference on Computer Communications (INFOCOM), vol. 3, pp.1435-1444, 2000.

[18] Floyd, Sally, and Van Jacobson. ”Random early detection gatewaysfor congestion avoidance,” IEEE/ACM Transactions on Networking- TON , vol. 1, no. 4, pp. 397-413, 1993.