FAST TCP ( FastTCPとも表記)は、カリフォルニア工科大学のNetlabで開発され、現在はFastSoftによって商品化されている、長距離、高遅延リンクを特に対象としたTCP輻輳回避アルゴリズムです。FastSoftは2012年にAkamai Technologiesに買収されました。[1]
FastTCP は既存の TCP アルゴリズムと互換性があり、データを送信するコンピューターのみを変更する必要があります。
名前
FASTという名前は、FAST A QM Scalable T CPの再帰頭字語です。AQMはA ctive Q ueue M anagementの略で、TCPはTransmission C ontrol P rotocolの略です。
動作原理
輻輳制御の役割は、ネットワークの容量と他のユーザーの送信速度に応じて、データが送信される速度(「輻輳」)を調整することです。TCP Vegasと同様に、FAST TCP [2] [3]は輻輳信号として 損失確率の代わりにキューイング遅延を使用します。
現在の輻輳制御アルゴリズムのほとんどは輻輳を検出し、パケットがドロップされていることを発見すると速度を落とすため、平均送信速度は損失確率に依存します。これには 2 つの欠点があります。まず、高いデータ レートを維持するには損失確率を低くする必要があります。TCP Reno の場合、非常に低い損失確率が必要ですが、H-TCP、BIC TCP、HSTCPなどの新しい輻輳回避アルゴリズムでも、ほとんどのワイヤレスワイド エリア ネットワークで提供される損失率よりも低い損失率が必要です。さらに、パケット損失は輻輳レベルについて 1 ビットの情報しか提供しませんが、遅延は連続量であり、原則としてネットワークに関するより多くの情報を提供します。
FAST TCP フローは、ネットワーク全体のキュー内のパケット数を一定に維持しようとします。キュー内のパケット数は、観測されたラウンドトリップ時間(RTT) と、キューイングがない場合のラウンドトリップ時間として定義されるベース RTTとの差を測定することによって推定されます。ベース RTT は、接続で観測された最小 RTT として推定されます。キューイングされたパケットが少なすぎる場合は送信速度が上がり、多すぎる場合は速度が下がります。この点では、TCP Vegas の直接の派生です。
TCP Vegas と FAST TCP の違いは、保存されているパケットの数が少なすぎたり多すぎたりした場合にレートを調整する方法にあります。TCP Vegas は、現在のレートがターゲット レートからどれだけ離れているかに関係なく、レートを固定サイズで調整します。FAST TCP は、システムが平衡状態から遠い場合はステップを大きくし、平衡状態に近い場合はステップを小さくします。これにより、収束速度と安定性が向上します。
強みと弱み
遅延ベースのアルゴリズムは、原理的には一定のウィンドウ サイズを維持できるため、損失ベースのアルゴリズムに固有の振動を回避できます。ただし、遅延は部分的に満たされたバッファに対応するのに対し、損失は完全に満たされたバッファから発生するため、損失ベースのアルゴリズムよりも早く輻輳を検出します。これは長所にも短所にもなり得ます。ネットワークで使用されるプロトコルが遅延ベースだけであれば、損失の非効率性は回避できます。ただし、損失ベース プロトコルと遅延ベース プロトコルがネットワークを共有する場合、[4]遅延ベース アルゴリズムはそれほど積極的ではありません。これは、パラメータを適切に選択することで克服でき、Tang らが研究した複雑な相互作用につながります。
遅延測定は、オペレーティング システムのスケジューリングやバス競合 の結果としてジッタの影響を受けることもあります。
強みと弱みのどちらが優勢になるかは明確ではなく、特定のシナリオに大きく依存します。
伝播遅延は、FAST ウィンドウ制御アルゴリズムで使用されます。クリーンなネットワークでは、既存の FAST フローによって維持されるキューイング遅延が、後から参加する新しいフローによる伝播遅延の一部であると誤解される可能性があります。これは、ns-2 シミュレーションで示されています。[5]この推定誤差の影響は、基礎となるユーティリティ関数を変更して、既存のフローよりも新しいフローを優先することと同じです。この誤差を排除する方法は、[5]で提案されています。
一般化された FAST TCP
FAST TCP は、システムの安定性、スループット、公平性の点で有望であることが示されています。ただし、リンクでボトルネックになるフローの数に比例して増加するバッファリングが必要です。論文[6]では、定常状態で ( α、n ) 比例公平性 を実現するために FAST TCP を拡張した新しい TCP アルゴリズムが提案されており、バッファ要件はフロー数の n 乗でのみ増加します。著者らは、新しいアルゴリズムを一般化 FAST TCP と呼んでいます。著者らは、フィードバック遅延がない場合の均質なソースを持つ単一のボトルネック リンクの場合の安定性を証明しています。シミュレーション結果により、新しい方式はフィードバック遅延があっても安定しており、そのバッファリング要件を標準の FAST TCP よりも大幅に拡張できることが検証されています。
知的財産
ほとんどのTCP輻輳回避アルゴリズムとは異なり、FAST TCPはいくつかの特許で保護されています。[7] [8] FASTの発明者、特にSteven H. LowとCheng Jinは、 IETFによる標準化を求める代わりに、FastSoft社を通じて商品化を目指しています。現在、FastSoftは、送信側で展開でき、両端で他のソフトウェアやハードウェアの変更を必要とせずに済む1ユニットラックアプライアンスを販売しています。
参照
参考文献
- ^ Young, Jeff (2012 年 9 月 13 日)。「Akamai が FastSoft を買収」。PR Newswire。2012年9 月 13 日閲覧。
- ^ Nick, Barone; Jin, Cheng; Low, Steven H. & Hegde, Sanjay (2006). 「FAST TCP: 動機、アーキテクチャ、アルゴリズム、パフォーマンス」(PDF) . IEEE/ACM Transactions on Networking . 14 (6): 1246–1259. doi :10.1109/TNET.2006.886335. 2006年9月6日時点のオリジナル(PDF)からアーカイブ。
- ^ Jin, Cheng; Wei, D.; Low, SH; Bunn, J.; Choe, HD; Doyle, JC; Newman, H.; Ravot, S.; Singh, S.; Paganini, F.; Buhrmaster, G.; Cottrell, L.; Martin, O.; Wu-Chun Feng (2005). 「FAST TCP: 理論から実験へ」(PDF) . IEEE Network . 19 (1): 4–11. doi :10.1109/MNET.2005.1383434. 2006年5月12日時点のオリジナル(PDF)よりアーカイブ。
- ^ 唐、蒼;王建桃。スティーブン・H・ロウ氏、ムン・チャン氏(2005年3月)。 「異種輻輳制御プロトコルのネットワーク平衡」(PDF)。IEEE インフォコム。フロリダ州マイアミ。
- ^ ab L. Tan、C. Yuan、M. Zukerman、「FAST TCP: 公平性とキューイングの問題」、IEEE Commun. Lett.、vol. 9、no. 8、pp. 762–764、2005 年 8 月。
- ^ Yuan, Cao; Tan, Liansheng; Andrew, Lachlan LH; Zhang, Wei; Zukerman, Moshe (2008). 「一般化された FAST TCP スキーム」.コンピュータ通信. 31 (14): 3242–3249. doi :10.1016/j.comcom.2008.05.028. hdl : 1959.3/44051 .
- ^ Jin, Cheng; Low, Steven H.; Wei, Xiaoliang (2005 年 1 月 27 日)。「ネットワーク輻輳制御の方法および装置」。米国特許商標庁。2012 年 12 月 14 日時点のオリジナルよりアーカイブ。2006年11 月 5 日閲覧。
- ^ Jin, Cheng; Low, Steven H.; Wei, David X.; Wydrowski, Bartek; Tang, Ao; Choe, Hyojeong (2006 年 3 月 9 日)。「キュー制御と片道遅延測定を使用したネットワーク輻輳制御の方法と装置」。米国特許商標庁。2012 年 12 月 14 日時点のオリジナルからアーカイブ。2006年11 月 5 日閲覧。
外部リンク
- FASTホームページ。
- スーパーコンピューティング 2005 帯域幅チャレンジ
- FastSoftホームページ
