Comments
Description
Transcript
無線LAN-APにおけるTCP ACKパケット蓄積回避 のための協調的輻輳
DEIM Forum2015 C2-2 無線 LAN-AP における TCP ACK パケット蓄積回避 のための協調的輻輳制御手法の提案と実装 早川 愛† 山口 実靖†† 小口 正人† † お茶の水女子大学 〒 112-8610 東京都文京区大塚 2-1-1 †† 工学院大学 〒 163-8677 新宿区西新宿 1-24-2 E-mail: †[email protected], ††[email protected], †††[email protected] あらまし 近年のロスベース 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: †[email protected], ††[email protected], †††[email protected] Key words TCP，Congestion control 1. は じ め に そこで本研究では，そのような問題を引き起こすロスベース TCP の一つである TCP CUBIC を輻輳制御アルゴリズムとして 輻輳制御方式には，ロスベース方式，遅延ベース方式とその 使用している Android 端末を用いて，無線 LAN-AP における 二つを複合させたハイブリット方式がある．その中でも近年の ACK パケットの蓄積を回避するための協調的制御手法の提案と ロスベース TCP はより高いスループットを確保するためにア 実装を行う．本手法では，同一 AP に接続された端末数と現在 グレッシブな輻輳制御手法を用いている．しかしながら，比較 のトラフィックの混み具合を示す往復遅延時間 (RTT) の二つの 的強く安定したコネクションを持つ有線接続と比べて低帯域で パラメータをリアルタイムに観測することで，そのネットワー ノイズの影響を受けやすい脆弱な無線接続環境においては，特 ク環境における理想的な輻輳ウィンドウ値 (CWND) をシステ に同一アクセスポイント (AP) に接続する端末台数が多い場合 ムが自動で算出し，各端末の最大の CWND として補正を行う． は AP の通信機会が減ってしまうため，その手法によって AP それにより，AP での ACK パケットの蓄積を回避し，かつ端末 に膨大な ACK パケットが蓄積されてしまう．それにより，端 間で可用帯域を公平に分け合うことで全体の通信速度と公平性 末と AP 間において頻繁にパケットロスやタイムアウト，輻輳 を向上させることを目指す． が発生してしまい，エンドホスト側の端末は十分な通信速度を 得ることができないという問題点がある． 2. 3 カーネルモニタリングツール 2. 研 究 背 景 カーネル内部の処理は，通常バックグラウンドで進められて 2. 1 Android OS いるため，通常ユーザ空間からその処理を監視することはでき 本研究では，Android プラットホーム上で動作するシステム ない．近年，汎用 PC 向け Linux ディストリビューションにお の開発を行う．Android [1] は Google 社が開発したモバイル端 いては，TCP Probe [5] が利用できる場合もあるが，Android に 末用プラットフォームであり，オープンソースであることから おいてはサポートされていない．そこで本研究では，カーネル 誰でも自由にカスタマイズできるという特徴がある． 内部の通信処理を解析するために，カーネルモニタを利用する． さらに，linux カーネルがベースとなっており，ロスベース方 カーネルモニタとは，Linux システムのカーネル内部の処理を 式の TCP CUBIC [3] を輻輳制御アルゴリズムとして採用してい 解析する汎用 PC 向けシステムツールである．既存研究 [6] は， る．TCP CUBIC は TCP BIC [2] の改良版であり，ウィンドウ制 既にカーネルモニタの Android への組込みに成功しており，同 御を単純かつ高度化するように設計されている．TCP CUBIC 様の方法で導入を行った端末を本研究においても利用する．図 の増加関数は式 1 で定義される．C はスケールファクター，t は 2 にその概要を示す．カーネルモニタは，通信時におけるカー 最後にパケット廃棄が発生した時点からの経過時間，Wmax は ネル内部のパラメータ値の変化を記録することが可能である． 最後にパケット廃棄が発生した時点のウィンドウサイズである． カーネル内部の TCP ソースにモニタ関数を挿入し再コンパイ √ Wcubic = C(t − 3 Wmax β 3 ) + Wmax C ルすることで，輻輳ウィンドウ値やソケットバッファのキュー (1) 長，各種エラーイベントの発生タイミングなどの TCP パラメー タを見ることができる．このツールを用いることで，本システ 実際の TCP CUBIC の振舞いを図 1 に示す．縦軸は CWND 横軸が時間で，パケットロスを検出したときウィンドウサイズ ムにおいてもカーネル内のパラメータをリアルタイムに解析す ることができる． を減少させ，最後のパケット廃棄が発生してからの経過時間を 元に三次関数的にウィンドウサイズを増加させる．TCP CUBIC では，遅延ベース方式のものと比べて各端末が通信経路の状 況を把握しないため，パケットロスが生じるまで各端末がアグ レッシブに通信しすぎる傾向にある．それにより，特に同時に 通信する端末数が多いときには AP で ACK パケットが蓄積し やすく，タイムアウトや再送が生じてしまい，エンドホスト側 の端末は十分な通信速度を得ることができないという問題点が 図 2 カーネルモニタの概要 ある． 3. 提 案 手 法 第 2. 2 章で述べたように，先行研究で開発されたシステムで はある特定した環境でのみ適応する値に固定された CWND の 補正値を用いていた．さらに，トラフィックの状況を判断する パラメータが通信端末数のみであったため，通信経路の混み具 合をより詳細に把握するために追加の情報を用いることで，性 能向上が実現できると考えられる．そこで本研究では，RTT の 図 1 TCP CUBIC の振舞い 増加が通信速度の低下に影響するという知見 [7] から RTT の増 減比率を観察することでトラフィックの状況を把握し，通信端 2. 2 輻輳制御ミドルウェア 末数と RTT の増減比率の二つのパラメータを用いて，その環 先行研究 [4] で開発された輻輳制御ミドルウェアは，同一 AP 境にあった CWND の補正値を自動で算出するシステムを構築 に接続した端末間でお互いの接続状況を把握し，その接続台数 した． によって混み具合を予測し，CWND の上限値を設定する組込み 本研究における提案手法の概要を図 3 に示す．具体的な制御 システムである．可用帯域を公平に分け合うことで，全体の通 としてはまず，先行研究と同様に UDP パケットを 0.3 秒ごとに 信速度と公平性の向上に成功している．しかしながら，この先 ブロードキャストすることで，周辺端末に自端末の通信状況を 行研究における CWND の補正値は経験則により決め打ちの値 通知する．それと同時に IP アドレスで固有化した周囲からの が用いられていたため，必ずしも最適に補正が行われていると UDP パケットを受け取り，接続端末数を把握する．その情報を は限らず，さらにシステム環境が変わるとその補正値自体を決 用いて CWND を補正するのだが，本研究ではその補正値を本 め直さなければならないという問題点がある．本研究ではそれ システムが自動で算出するために CWND の理想値を示す式 2 らの問題点を解決し，本システムのさらなる性能と利便性の向 を用いた．また，先行研究 [8] において帯域幅は接続台数に伴 上を目指す． い変化することが確認されているので，帯域幅に関しては，式 3 のように計算した値を用いている．ただし，BWmax はその 通信環境における最高通信速度である．f(端末数) は端末数の増 4. 提案手法の性能評価 加による合計通信速度の低下を表す単調減少の関数であり，先 4. 1 実 験 概 要 行研究 [8] を元に式 4 とした． 図 4 と表 1 に示す環境において，Android 端末 10 台に本提案 ミドルウェアを導入したときの，本提案手法の評価実験を行っ Bandwidth[M bps] × RT T [sec] Ideal cwnd = Segmentsize(1.5Kbyte) × 端末数 (2) Bandwidth = BW max × f (端末数) (3) た．本実験環境における BWmax は，1.9 × 103 である．AP と サーバ機の間には，人工遅延装置 Dummynet [9] を挟み，有線 部の往復遅延時間を特に輻輳が生じやすい高遅延環境を模擬す るために 256ms に設定している．この環境において，Iperf [10] を用いて通信スループットを測定した． f (端末数) = 端末数−0.15 (4) 図4 実験トポロジ 表1 実験環境 Android Model number 図 3 提案手法の概要 これらの式を用いて算出された CWND 値を，プロセスイン ターフェースに CWND の最大値として 0.5 秒ごとに書き込み server 補正する．さらに，通信中はカーネルモニタを 0.5 秒単位で常 時監視し，RTT とその最小値 (min-rtt) を取得する．min-rtt は， 通信中で最も小さい RTT を常に上書きしていくことで値を更 AP Nexus S Firmware version 4.1.1 Baseband version I9023XXKD1 Kernel version 3.0.31-ai Build number JRO03L OS Ubuntu 12.04 (64bit) / Linux 3.0.1 CPU Intel(R) Core 2Quad CPU Q8400 Main Memory 7.8GiB Model MZK-MF300N(Planex) Sommunication system IEEE 802.11g 新する．取得した値をもとに式 5 を用いて RTT の増減の比率 (ratio rtt) を求める． 4. 2 実 験 結 果 RT T ratio rtt = min rtt (5) 合計の通信速度の評価結果を図 5 に示す．青のグラフは，補 正を行わないデフォルトの状態で，赤のグラフは本提案手法に この ratio rtt が 6.0 以上になると，トラフィックが混んできたと よる補正を行った結果である．グラフより，RTT の増加が観測 みなし，式 2 を用いた端末数による CWND を補正するフェー されたと考えられる 4 台以降において本提案手法による性能向 ズに切り替わる．また，その補正をした上でも RTT が増加し 上が確認され，最大で 10 台の端末が同時に通信するときの通 てしまう場合においては，ratio rtt が 5.0 以上になると CWND 信速度は約 3.35 倍向上した． を 1 にして一時的に通信最小モードに移行し，その後に起こり 得るさらなる遅延を回避する． これらの制御によって，通信中においても同じ AP を共有す る他端末が通信を始めたことやそれに伴って急に RTT の値が増 加したことを本システムが検知すると，リアルタイムに CWND を適切な値に補正することでトラフィック発生量を制限し，途 中から通信を始めた端末にも均等に帯域を分け合えるよう制 御することができる．さらに本システムにおいては，基本的な TCP の輻輳制御アルゴリズムは変更しておらず，これはデフォ ルト時同様に機能している．ただし，AP 周りの通信状況に基 づき，問題が発生した場合にのみ迅速に対応することで，通信 の最適化を実現する． 図5 合計通信速度 この時の CWND の時間遷移を図 6 に示す．1 台から 3 台まで は，帯域に余裕があり ratio rtt の値が 6.0 以下なので補正が行 わていないが，4 台で通信中に AP の負荷が増加し，ratio rtt が 6.0 を超えると本提案手法による補正が行われ，算出された上 限値以下に制御されていることが分かる．さらに，図 7 の RTT の時間遷移に示すように，補正が行われた 5 台目以降では RTT の増加が観測されていないことから，全体のトラフィックがス ムーズになり AP への負荷が削減されたことが確認できる． 図8 公平性の評価 5. 未実装端末と混在する場合の評価 5. 1 実 験 概 要 第 4.1 章では，全ての端末が輻輳制御を補正した時の通信性 能を測定したが，現実世界においては，本提案ミドルウェアが 普及していく過程において，標準 TCP を利用する端末と AP を 共有することは避けられない．よって本章では，同一 AP を共 図 6 CWND の振舞い 有する端末間において，本提案ミドルウェアを持たない端末が 混在する場合に，各端末と全体の通信性能にどのような影響を 及ぼすかについての実験を行った． 5. 2 実 験 結 果 本環境においては，ミドルウェアが有効になるのは，同時通 信台数 4 台以降であるので，4，7，10 台における測定結果を 図 9，図 10，図 11 に示す．赤いグラフが本提案ミドルウェア を導入していない端末の平均通信速度，緑のグラフが本提案手 法を導入した端末の平均通信速度，青いグラフが両者の合計通 信速度を表している．グラフより，本提案手法を導入する端末 が 1 台でも存在すれば，補正を全く行わないデフォルトの状態 よりも合計通信速度は向上していることが分かる．また，ミド ルウェアを導入している端末は CWND の上限を定められてい 図 7 ratio rtt の振舞い ることにより，導入していない端末と比べて非積極的な通信を 行うため，平均通信速度では特に，補正をしない端末が 1 台の 時はデフォルトの方が多く上回っている．しかしながら，その 次に，FairnessIndex [11] を用いて通信時における公平性の評 価を行った (図 8)．Fairness Index とは，公平性を示す指標であ り，式 6 で算出された値が 1 に近いほど高い公平性を示す． ∑k xi )2 F airnessIndex : f i = ∑i=i k 2 ( k i=i xi 本手法による補正を加えたときには，加えない時と比べて平均 通信速度は向上しているため，本手法を用いることのメリット は十分大きいはずである．さらに，10 台同時通信時における公 (1 < =i< = k) (6) 青のグラフに示す本提案手法を用いない場合には，同時通信 台数が多くなるほど公平性が損なわれているが，それに対し， 本提案手法を適応した赤のグラフでは台数が 10 台まで増加し てもほぼ 1 の値を維持し，デフォルトの状態よりも約 1.16 倍値 が向上している．つまり本提案手法を用いることで，公平性が 向上することを確認した． 1 台のみが補正を行わないという場合を除けば，全ての端末が 平性を図 12 に示す．10 台中 1 台のみが未実装の場合，公平性 が大幅に損なわれているのが分かる．本提案手法は同一 AP に 接続するすべての端末で公平に可用帯域を分け合うことを目的 としているため，そのすべての端末が本手法を用いるような方 法を考えなければならない．その一つの案として，例えば AP を提供する側が本手法を用いる端末にのみパスワードを提示す るなどのような手法を導入すれば実現可能である． 6. 端末数変化時の評価 6. 1 実 験 概 要 第 4.1 章および第 4.2 章では，通信台数を固定にした状態 で評価実験を行った．しかしながら，実環境ではモバイル端末 は移動することから，頻繁にハンドオーバや通信のオンオフを 繰り返す．それにより，同一 AP に接続されるアクティブな通 信端末台数が動的に変動する可能性が考えられる．そこで本章 では，通信中に接続端末数が変化する状況において本提案手法 の評価を行った．今回は，図 13 と図 14 に示すように，通信端 図 9 4 台通信時における評価 末数が増加する場合と減少する場合の二つのモデルを用いた． 通信端末が増加する場合では，本研究における実験環境におい て本提案ミドルウェアが有効化されると考えられる，4 台同時 通信状態からスタートし，その後 20 秒ごとに 1 台ずつアクティ ブ端末が増えていくモデルである．一方で，通信端末が減少す る場合では，逆にアクティブな端末が 20 秒ごとに減っていく モデルである．尚，通信端末数が頻繁に変動する場合において は，通信台数が固定となっている状態よりも，RTT の増減が頻 繁に生じることが考えられる．そこで，本提案手法の一つであ る，ratio rtt が 5.0 以上になると CWND を 1 にして一時的に通 信停止モードに移行する手法の効果を検証するため，本提案ミ ドルウェアの導入しないデフォルト時との比較に加え，ratio rtt 図 10 7 台通信時における評価 による制御のみを除去した提案ミドルウェア導入時との比較も 同時に行った． 図 11 10 台通信時における評価 図 13 通信端末が増加する場合のモデル 図 14 通信端末が減少する場合のモデル 図 12 10 台通信時における公平性 6. 2 実 験 結 果 図 15 に示すのは，本提案ミドルウェア未導入時 (baseline)， 本提案手法導入時 (proposed)，本提案手法の RTT による制御 を排除したミドルウェア導入時 (without RTT) の合計通信速度 である．グラフより，通信端末が増加する場合においては，本 提案ミドルウェアを導入することで，本提案手法未導入時に比 べて 1.36 倍，RTT による制御なしの場合より 1.05 倍通信速度 が向上することを確認した．一方，通信端末が減少する場合に おいても，同様にそれぞれ 1.57 倍，1.34 倍向上することが分 かった． また，各端末における通信速度の平均値を図 16，図 17 に示 図 17 端末減少時における各端末の合計通信速度 す．すべての端末において，本提案手法を導入した場合の方が， 未導入時に比べて通信速度が向上していることが分かる．ただ， RTT による制御を除いた場合と本手法を比較すると，通信時間 が短い端末，つまり増加する場合では，node 9，node 10，減少 する場合では node 1，node 2 においては，全体の通信時間のう ちの RTT による制御によって CWND が抑えられる時間が占め る割合が多いため，RTT による制御も含めた本提案手法の方が， 若干通信速度が低下している．しかしながら，長く通信する端 末においては，RTT の増加を緩和することができる本提案手法 により効果的に RTT の増加が抑えられ，各端末の平均通信速 度は向上することを確認した． さらに，このときの 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 比率の著しい増加 が観測された場合に発動する通信停止モードの効果を確認した． 図 15 図 16 合計通信速度 図 18 端末増加時における CWND の遷移 (baseline) 図 19 端末増加時における CWND の遷移 (proposed) 端末増加時における各端末の合計通信速度 7. 関 連 研 究 TCP では，基本的にはパケット損失がネットワーク輻輳を 指し示していると想定されているが，そのパケット損失の主な 原因としては，他のコミュニケーションピアへの経路に沿った ルータにおいてキューがオーバーフローを起こすことであると 考えられる．しかしながら，無線通信においてはパケット損失 の他の原因として，フェ−ジングや衝突，干渉なども考えられ， それらは TCP 輻輳制御アルゴリズムでは下位層で生じた問題 であるかどうかの区別がつかない．TCP 性能における無線区間 図 20 端末増加時における CWND の遷移 (without RTT) のそれらの効果は，[12] [13] [14] [15] によって広範囲にわたって 研究され続けてきた． 輻 輳 を 回 避 す る 手 段 と し て ，Explicit Congestion Notifica- tion [16] は経路上の不特定の地点においてパケットにビット を立てることで輻輳状態を通知する．また Active Queue Man- agement [17] や Random Early Detection [18] は，輻輳崩壊が起 きる前に，ルーティング機器上で意図的にパケットを損失させ る仕組みである．これらの仕組みは差し迫った輻輳に備えて， セグメント送出量を減らすタイミングを検出する．しかし，こ れらの仕組みは，経路上の全てのネットワーク機器が対応する 時のみ効果的であることから，通信インフラを新規に導入する 図 21 端末減少時における CWND の遷移 (baseline) 必要があるためコストが大きく，実際に導入が進んでいない． 我々の先行研究も輻輳を回避する手法の一つであるが，その 仕組みとしては，同一 AP に接続する端末数のみにおいて全体 のトラフィックを把握し，可用帯域を公平に分け合うという手 法であり，本提案手法のように実際のネットワークトラフィッ クの混み具合を示す RTT は制御パラメータとして用いておら ず，常に正確にネットワーク状況を把握しきれていたとは限ら ないという点で，本研究とは異なる．さらに，先行研究との大 きな差分として，先行研究では CWND の補正値を経験則によ り決めうちの値を用いて，ある特定の実験環境にのみ対象にし ていたが，本研究では，ユーザが使用するネットワーク環境と して，最大の帯域幅である BWmax を指定さえすれば，本シス 図 22 端末減少時における CWND の遷移 (proposed) テムが自動で補正値を算出し，適応させることが可能である． 8. まとめと今後の課題 本研究では，ロスベース TCP を使用する端末が多数台同時 に通信する場合において，AP に ACK パケットが蓄積し輻輳を 起こす問題を回避するために，先行研究によって開発された輻 輳制御ミドルウェアの改変と高機能化を行った．具体的には， 同一 AP に接続する端末間で通信状況を通知し合い，その接続 端末数と RTT による混み具合を把握することで，自動的にそ の通信環境にあった CWND を各端末ごとに協調的に補正する 手法を提案し，実装を行った．本提案手法を用いることで，10 台で同時に通信するときの通信速度が約 3.35 倍，公平性が約 図 23 端末減少時における CWND の遷移 (without RTT) 1.16 倍向上することを確認した．また，本提案ミドルウェアを 持たない端末が混在している環境下においても，本提案手法に よる CWND の補正を行う端末が 1 台以上存在すれば，すべて の端末が本提案手法を用いない場合よりも全体の通信速度を向 上させることが分かった．さらに，通信中に接続端末数が変動 する場合においては，端末が増加する場合にはデフォルト時よ りも 1.36 倍，減少する場合には 1.57 倍，全体の通信速度が向 上することを確認した． 今後の課題としては，本実験環境で用いた無線 LAN AP は， IEEE802.11b/g によって定義されるデータレートのみをサポー [9] [10] [11] トしているため，IEEE802.11n や IEEE802.11ac のようなより広 範囲のデータレートを提供する近年の AP を用いた場合におけ る，本提案手法の評価を行いたい．また，本稿における提案手 [12] 法の評価として，エンドユーザはすべてベンチマークツールを 利用し，アップリンクにより比較的大きなデータ転送をする場 合の評価を行ったが，実際には，それほど帯域を必要としない [13] メール送信などの低トラフィックな通信を行う端末も存在する と考えられる．本提案手法では，エンドユーザの通信の種類に 関わらず，すべての端末に公平に帯域を割り当てるため，この [14] ような場合には低トラフィックな端末に十分すぎる帯域が割り 当てられてしまい，かえって未使用帯域を残してしまう可能性 がある．そこで，各ユーザごとの通信需要により，帯域割り当 [15] てを行うことで，より効果的な制御ができるのではないかと考 えられる．さらに，本提案手法で自動で算出される帯域幅遅延 積は，そのネットワーク環境における最大の帯域幅と有線部に かかる往復遅延時間との積で求められるが，このどちらか，あ るいは両方が極端に小さい環境で通信する端末が存在した場合， [16] [17] 本手法において割り当てられる帯域が他端末と比べて大幅に小 さくなる可能性がある．その場合，本提案手法の性能評価で示 [18] した公平性の向上は必ずしも担保できるとは限らない．よって， そのような場合の評価と制御方法を検討する必要がある． 謝 辞 本研究を進めるにあたり，ご協力賜りました大阪大学/UCLA の高井峰生先生に深く感謝致します． 文 献 [1] Android open source project, http://source.android.com [2] L. Xu, K. Harfoush, and I. Rhee, ”Binary Increase Congestion Control 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 TCPfriendly high-speed TCP variant” ACM SIGOPS Operating Systems Review - Research and developments in the Linux kernel, vol.42, pp.64-74, July 2008. [4] Hiromi Hirai, Saneyasu Yamaguchi, and Masato Oguchi: ”A Proposal on Cooperative Transmission Control Middleware on a Smartphone in a WLAN Environment,” In Proc. the 9th IEEE International Conference on Wireless and Mobile Computing, Networking and Communications (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 Mobile Phone Terminals,” Proceedings of The Tenth International Conference on Networks (ICN), pp. 297-302. 2011. [7] Ai Hayakawa, Saneyasu Yamaguchi, Masato Oguchi: ”Reducing the TCP ACK Packet Backlog at the WLAN Access Point” In Proc. the 9th ACM International Conference on Ubiquitous Information Management and Communication (IMCOM2014), 5-4, Bali, Indonesia, January 2015. [8] Makiko Matsumoto and Masato Oguchi: ”Multiple Access in MAC Layer Based on Surrounding Conditions of Wireless Stations” In Proc. the 1st International Workshop on Vehicular Communications and Applications (VCA2012) in conjunction with the 11th Annual Mediterranean Ad Hoc Networking Workshop (Med-Hoc-Net2012), pp.133-140, Ayia Napa, Cyprus, June 2012. The dummynet project: http://info.iet.unipi.it/ luigi/dummynet Iperf:http://downloads.sourceforge.net/ project/iperf/iperf/2.0.5 D.-M. Chiu and R. Jain,“ Analysis of the increase and decrease algorithms for congestion avoidance in computer networks, ” Computer Networks and ISDN Systems, vol. 17, pp. 1-14, 1989. Prasun Sinha, Thyagarajan Nandagopal, Narayanan Venkitaraman, Ragupathy Sivakumar, Vaduvur Bharghavan : ”WTCP:a reliable transport protocol for wireless wide-area networks” Wireless Networks - Selected Papers from Mobicom’99 archive, Volume 8 Issue 2/3, March-May 2002, pp. 301-316 Claudio Casetti, Mario Geria, Saverio Mascolo, M.Y.Sanadidi, Ren Wang: ”TCP westwood: end-to-end congestion control for wired/wireless networks” Wireless Networks archive, Volume 8 Issue 5, September 2002, pp. 467 - 479 Luigi A. Grieco and Saverio Mascolo: ”Performance Evaluation and Comparison of Westwood+, New Reno, and Vegas TCP Congestion Control,” ACM SIGCOMM Computer Communications Review, Vol.34, No.2, pp.25-38, April 2004. Shao Liu, Tamer Basar, R.Srikant: ”TCP-Illinois: a loss and delaybased congestion control algorithm for high-speed networks” valuetools ’06 Proceedings of the 1st international conference on Performance evaluation methodolgies and tools, Article No. 55. Floyd, Sally. ”TCP and explicit congestion notification,” ACM SIGCOMM Computer Communication Review 24, no. 5 : 8-23, 1994. Firoiu, Victor, and Marty Borden. ”A study of active queue management for congestion control,” Proceedings of IEEE International Conference on Computer Communications (INFOCOM), vol. 3, pp. 1435-1444, 2000. Floyd, Sally, and Van Jacobson. ”Random early detection gateways for congestion avoidance,” IEEE/ACM Transactions on Networking - TON , vol. 1, no. 4, pp. 397-413, 1993.