Loading article…
伝送制御プロトコル( TCP)は、輻輳回避を実現するために、加算的増加/乗法的減少(AIMD) 方式のさまざまな側面と、スロースタート[1]や輻輳ウィンドウ (CWND) などの他の方式を含む輻輳制御アルゴリズムを使用します。TCP輻輳回避アルゴリズムは、インターネットにおける輻輳制御の主要な基礎です。 [2] [3] [4]エンドツーエンドの原則によれば、輻輳制御は主にインターネットホストの機能であり、ネットワーク自体の機能ではありません。インターネットに接続するコンピューターのオペレーティングシステムのプロトコルスタックに実装されているアルゴリズムには、いくつかのバリエーションとバージョンがあります。
輻輳による崩壊を回避するために、TCP は多面的な輻輳制御戦略を使用します。TCP は各接続に対して CWND を維持し、エンドツーエンドで転送中の未確認パケットの合計数を制限します。これは、フロー制御に使用されるTCP のスライディング ウィンドウに似ています。
加算的増加/乗算的減少
加法的増加/乗法的減少（AIMD）アルゴリズムは、閉ループ制御アルゴリズムです。AIMDは、輻輳が発生したときに輻輳ウィンドウの線形増加と指数関数的減少を組み合わせます。AIMD輻輳制御を使用する複数のフローは、最終的に競合リンクを均等に使用するように収束します。[5]
これはRFC 5681で「輻輳回避」状態について説明されているアルゴリズムです。 [6]
輻輳ウィンドウ
TCP では、輻輳ウィンドウ (CWND) は、いつでも送信できるバイト数を決定する要因の 1 つです。輻輳ウィンドウは送信側によって維持され、送信側と受信側の間のリンクが過度のトラフィックで過負荷になるのを防ぐ手段です。これは、受信側が過負荷になるのを防ぐために存在する、送信側によって維持されるスライディング ウィンドウと混同しないでください。輻輳ウィンドウは、リンク上の輻輳の程度を推定して計算されます。
接続が確立されると、各ホストで独立して維持される値である輻輳ウィンドウが、その接続で許可される最大セグメント サイズ( MSS ) の小さな倍数に設定されます。輻輳ウィンドウのさらなる変化は、加算的増加/乗法的減少(AIMD) アプローチによって決定されます。つまり、すべてのセグメントが受信され、確認応答が時間どおりに送信者に届いた場合、ウィンドウ サイズに定数が追加されます。これは、さまざまなアルゴリズムに従います。
システム管理者は、 TCPチューニングの一環として、最大ウィンドウ サイズ制限を調整したり、加算増加時に追加される定数を調整したりすることができます。
TCP 接続上のデータ フローは、受信側によって通知される受信ウィンドウの使用によっても制御されます。送信側は、自身の輻輳ウィンドウと受信ウィンドウよりも少ないデータを送信できます。
スロースタート
スロースタートは、 RFC 5681 [7]で定義されており、 TCP が他のアルゴリズムと組み合わせて使用する輻輳制御戦略の一部であり、ネットワークが転送できる量を超えるデータの送信を回避し、ネットワーク輻輳を回避するために使用されます。
スロースタートは、最初は1、2、4、または10MSSの輻輳ウィンドウサイズ（CWND）で始まります。[8] [3] : 1 輻輳ウィンドウサイズの値は、受信確認（ACK）ごとに1MSSずつ増加し、実質的にRTTごとにウィンドウサイズが2倍になります。[a]
パケット損失が検出されるか、受信側のアドバタイズされたウィンドウ (rwnd) が制限要因になるか、スロー スタートしきい値 (ssthresh)に達するまで、スロー スタート アルゴリズムによって送信速度が増加します。スロー スタートしきい値は、スロー スタートまたは輻輳回避アルゴリズムのどちらを使用するかを決定するために使用され、スロー スタートを制限するために設定された値です。
CWND がssthreshに達すると、TCP は輻輳回避アルゴリズムに切り替わります。これは、RTT ごとに最大 1 MSS 増加する必要があります。一般的な式では、新しい ACK ごとにCWND がMSS * MSS / CWND だけ増加します。これはほぼ直線的に増加し、許容できる近似値を提供します。
損失イベントが発生した場合、TCP はそれがネットワークの輻輳によるものであると想定し、ネットワークにかかる負荷を軽減する措置を講じます。これらの措置は、使用される TCP 輻輳回避アルゴリズムによって異なります。
TCP 送信者が再送タイマーを使用してセグメント損失を検出し、指定されたセグメントがまだ再送されていない場合、ssthreshの値は、送信されたがまだ累積的に確認応答されていないデータ量の半分以下、または2 * MSS のいずれか大きい方に設定する必要があります。
- TCP タホ
- 損失が発生すると、再送信が行われ、現在の CWND の半分がssthreshとして保存され、スロー スタートが初期 CWND から再び開始されます。
- TCPリノ
- 高速再送信が送信され、現在のCWNDの半分がssthreshとして保存され、新しいCWNDとして保存されるため、スロースタートをスキップして輻輳回避アルゴリズムに直接進むことができます。ここでの全体的なアルゴリズムは早い回復。
スロー スタートでは、未確認のセグメントはネットワークの輻輳によるものと想定します。これは多くのネットワークで許容できる想定ですが、データ リンク層の伝送品質が低いなどの他の理由によりセグメントが失われる場合があります。したがって、ワイヤレス ネットワークなどの受信状態が悪い状況では、スロー スタートのパフォーマンスが低下する可能性があります。
スロースタートプロトコルは、短命な接続に対してもパフォーマンスが悪い。古いウェブブラウザはウェブサーバに対して多数の短命な接続を連続して作成し、要求されたファイルごとに接続を開いたり閉じたりしていた。そのため、ほとんどの接続がスロースタートモードのままとなり、応答時間が遅くなっていた。この問題を回避するために、最近のブラウザは、複数の接続を同時に開くか、特定のウェブサーバから要求されたすべてのファイルに対して1つの接続を再利用している。しかし、ウェブ広告、ソーシャルネットワーキングサービスの共有機能、[9]、ウェブ解析のカウンタースクリプトを実装するためにウェブサイトが使用する複数のサードパーティサーバに対しては、接続を再利用することはできない。
高速再送信
高速再送信は、送信者が失われたセグメントを再送信するまでの待機時間を短縮する TCPの拡張機能です。TCP 送信者は通常、単純なタイマーを使用して失われたセグメントを認識します。指定された時間 (推定往復遅延時間の関数) 内に特定のセグメントの確認応答が受信されない場合、送信者はセグメントがネットワーク内で失われたと想定し、セグメントを再送信します。
重複確認応答は、高速再送信メカニズムの基礎です。パケットを受信すると、受信したデータの最後の順序どおりのバイトに対する確認応答が送信されます。順序どおりのパケットの場合、これは実質的に最後のパケットのシーケンス番号と現在のパケットのペイロード長の合計です。シーケンス内の次のパケットが失われ、シーケンス内の 3 番目のパケットが受信された場合、受信側はデータの最後の順序どおりのバイトに対してのみ確認応答できます。これは、最初のパケットに対して確認応答された値と同じです。2 番目のパケットが失われ、3 番目のパケットは順序どおりではないため、データの最後の順序どおりのバイトは以前と同じままです。したがって、重複確認応答が発生します。送信側はパケットの送信を継続し、4 番目と 5 番目のパケットが受信側によって受信されます。この場合も、2 番目のパケットがシーケンスから欠落しているため、最後の順序どおりのバイトは変更されていません。重複確認応答は、これらの両方のパケットに対して送信されます。
送信側が重複した確認応答を 3 回受信した場合、確認応答で指定された最後の順序どおりのバイトに続くデータを運ぶセグメントが失われたとほぼ確信できます。高速再送信機能を持つ送信側は、タイムアウトを待たずにこのパケットを直ちに再送信します。再送信されたセグメントを受信すると、受信側は受信したデータの最後の順序どおりのバイトを確認することができます。上記の例では、5 番目のパケットのペイロードの最後まで確認応答します。TCP はデフォルトで累積確認応答を使用するため、中間パケットを確認する必要はありません。
アルゴリズム
輻輳制御アルゴリズム（CCA）の命名規則は、1996年にケビン・フォールとサリー・フロイドが発表した論文に由来している可能性がある。[10] [検証失敗]
次の特性に従って分類できる可能性は、次のとおりです。
- ネットワークから受け取ったフィードバックの種類と量
- 現在のインターネット上での段階的な展開可能性
- 改善を目指すパフォーマンスの側面: 高帯域幅遅延積ネットワーク (B)、損失リンク (L)、公平性 (F)、短いフローに対する優位性 (S)、可変レートリンク (V)、収束速度(C)
- 公平性の基準
よく知られている輻輳回避メカニズムのいくつかは、この方式によって次のように分類されます。
TCP タホとリノ
TCP Tahoe および Reno アルゴリズムは、それぞれが最初に登場した4.3BSDオペレーティング システムのバージョンまたは種類にちなんで後から命名されました(これらのバージョンまたは種類自体も、タホ湖とネバダ州リノ市にちなんで名付けられました)。Tahoe アルゴリズムは、4.3BSD-Tahoe ( CCI Power 6/32 "Tahoe" ミニコンピュータをサポートするために作成されました) で最初に登場し、後に 4.3BSD Networking Release 1 の一部として AT&T 以外のライセンス所有者にも利用可能になりました。これにより、広く配布および実装されました。4.3BSD-Reno では改良が行われ、その後 Networking Release 2 として、さらに 4.4BSD-Lite として一般に公開されました。
どちらも再送信タイムアウト (RTO) と重複 ACK をパケット損失イベントと見なしますが、Tahoe と Reno の動作は主に重複 ACK への反応方法が異なります。
- Tahoe: 重複したACKが3つ受信された場合（つまり、同じパケットを確認する4つのACKで、データにピギーバックされておらず、受信側のアドバタイズされたウィンドウを変更しない場合）、Tahoeは高速再送信を実行し、スロースタートしきい値を現在の輻輳ウィンドウの半分に設定し、輻輳ウィンドウを1 MSSに減らし、スロースタート状態にリセットします。[15]
- リノ：重複したACKを3つ受信した場合、リノは高速再送を実行し、輻輳ウィンドウを半分にすることでスロースタートフェーズをスキップし（タホのように1MSSに設定するのではなく）、ssthreshを新しい輻輳ウィンドウに等しく設定し、高速回復と呼ばれるフェーズに入ります。[16]
Tahoe と Reno の両方で、ACK がタイムアウト (RTO タイムアウト) するとスロー スタートが使用され、両方のアルゴリズムで輻輳ウィンドウが 1 MSS に削減されます。[引用が必要]
TCP ニューリノ
RFC 6582 ( RFC 3782 およびRFC 2582 の以前の定義を廃止)で定義されている TCP New Reno は、 TCP Reno の高速回復フェーズ中の再送信を改善します。
高速回復中は、送信ウィンドウをいっぱいに保つために、返される重複 ACK ごとに、輻輳ウィンドウの最後から新しい未送信パケットが送信されます。
Reno との違いは、New Reno では ssthresh をすぐに半分にしないため、複数のパケット損失が発生した場合にウィンドウが過度に縮小される可能性があることです。すべてのデータを確認するまで、高速リカバリを終了せず、ssthresh をリセットしません。
再送信後、新たに確認されたデータには次の 2 つのケースがあります。
- 完全な確認応答: ACK は送信されたすべての中間セグメントを確認し、ssthresh は変更できず、cwnd は ssthresh に設定できます。
- 部分的な確認応答: ACK はすべてのデータを確認するものではありません。これは別の損失が発生する可能性があることを意味します。許可されている場合は、最初の未確認セグメントを再送信します。
「回復」と呼ばれる変数を使用して、回復する必要があるデータの量を記録します。再送信タイムアウト後、送信された最大のシーケンス番号を回復変数に記録し、高速回復手順を終了します。このシーケンス番号が確認されると、TCP は輻輳回避状態に戻ります。
New Reno では、パケット損失がないにもかかわらず、パケットが 3 つ以上のパケット シーケンス番号で並べ替えられると問題が発生します。この場合、New Reno は誤って高速回復に入ります。並べ替えられたパケットが配信されると、重複した不要な再送信が直ちに送信されます。
新しいRenoは、低パケットエラー率ではSACKと同等の性能を発揮し、高エラー率ではRenoを大幅に上回ります。[17]
TCP ベガス
1990 年代半ばまで、TCP のタイムアウト設定と測定された往復遅延はすべて、送信バッファ内の最後の送信パケットのみに基づいていました。アリゾナ大学の研究者Larry PetersonとLawrence Brakmo は、送信バッファ内のすべてのパケットに対してタイムアウトが設定され、往復遅延が測定される TCP Vegas を導入しました。さらに、TCP Vegas は輻輳ウィンドウの加算的増加を使用します。さまざまな TCP CCAの比較研究では、TCP Vegas が最もスムーズで、TCP CUBIC がそれに続きました。[18]
TCP Vegasはピーターソンの研究室以外では広く導入されていませんでしたが、 DD-WRTファームウェアv24 SP2のデフォルトの輻輳制御方法として選択されました。[19]
TCP ハイブラ
TCP Hybla [20] [21]は、高遅延の地上または衛星無線リンクを使用するTCP接続のペナルティを排除することを目的としています。Hyblaの改善は、輻輳ウィンドウのダイナミクスの分析評価に基づいています。[22]
TCP BIC
バイナリ増加輻輳制御（BIC）は、ロングファットネットワーク（LFN）と呼ばれる高遅延の高速ネットワーク向けに最適化されたCCAを備えたTCP実装です。 [23] BICは、 Linuxカーネル2.6.8から2.6.18でデフォルトで使用されます。[引用が必要]
TCPキュービック
CUBIC は、BIC のより攻撃性が低く、より体系的な派生であり、ウィンドウは最後の輻輳イベントからの時間の 3 次関数であり、変曲点はイベント前のウィンドウに設定されます。CUBIC は、バージョン 2.6.19 以降のLinux カーネルでデフォルトで使用されます。
アジャイルSDTCP
Agile-SD は、実際の Linux カーネル用に設計された Linux ベースの CCA です。これは、アジリティ ファクター(AF) と呼ばれる新しいメカニズムを使用した損失ベースのアプローチを採用した受信側アルゴリズムです。特に適用されるバッファー サイズが小さい場合に、ローカル エリア ネットワークや光ファイバー ネットワークなどの高速および短距離ネットワーク (低帯域幅遅延積ネットワーク) での帯域幅使用率を高めます。[24] NS-2 シミュレータを使用して、Compound TCP (MS Windows のデフォルトの CCA) および CUBIC (Linux のデフォルト) とパフォーマンスを比較して評価されました。平均スループットの点で、全体のパフォーマンスが最大 55% 向上します。
TCP ウェストウッド+
Westwood+ は、TCP Reno の送信側のみの修正版で、有線および無線ネットワークの両方で TCP 輻輳制御のパフォーマンスを最適化します。TCP Westwood+ は、エンドツーエンドの帯域幅推定に基づいて、輻輳エピソード後、つまり 3 つの重複した確認応答またはタイムアウト後に輻輳ウィンドウとスロースタートしきい値を設定します。帯域幅は、確認応答パケットを返すレートを平均化することで推定されます。3 つの重複した ACK の後に輻輳ウィンドウを盲目的に半分にする TCP Reno とは対照的に、TCP Westwood+ は、輻輳が発生したときに使用可能な帯域幅の推定値を考慮して、スロースタートしきい値と輻輳ウィンドウを適応的に設定します。Reno および New Reno と比較すると、Westwood+ は無線リンクでのスループットを大幅に向上させ、有線ネットワークでの公平性を向上させます。[引用が必要]
複合TCP
Compound TCP は、公平性を損なうことなく LFN で良好なパフォーマンスを実現することを目的として、2 つの異なる輻輳ウィンドウを同時に維持するMicrosoftの TCP 実装です。Microsoft Windows VistaおよびWindows Server 2008以降の Windows バージョンで広く導入されており、古い Microsoft Windows バージョンやLinuxにも移植されています。
TCP 比例レート削減
TCP比例レート削減（PRR）[25]は、回復中に送信されるデータの精度を向上させるために設計されたアルゴリズムです。このアルゴリズムは、回復後のウィンドウサイズがスロースタートしきい値に可能な限り近くなるように保証します。Googleが実施したテストでは、 PRRにより平均レイテンシが3〜10％削減され、回復タイムアウトが5％削減されました。[26] PRRはバージョン3.2以降のLinuxカーネルで利用可能です。[27]
TCP ブロック リバース
ボトルネック帯域幅と往復伝播時間 (BBR) は、2016 年に Google で開発された CCA です。[28]ほとんどの CCA は、パケット損失を利用して輻輳と伝送速度の低下を検出するという点で損失ベースですが、TCP Vegas と同様に、BBR はモデルベースです。このアルゴリズムは、ネットワークが最新の送信データ パケットを配信した最大帯域幅と往復時間を使用して、ネットワークのモデルを構築します。パケット配信の累積的または選択的な確認応答ごとに、データ パケットの送信とそのパケットの確認応答の間の時間間隔で配信されたデータ量を記録するレート サンプルが生成されます。[29]
YouTubeで実装されたBBRv1では、ネットワークスループットが平均4%向上し、一部の国では最大14%向上しました。[30] BBRはLinux 4.9以降、Linux TCPで利用可能です。[31] QUICでも利用可能です。[32]
BBR バージョン 1 (BBRv1) の非 BBR ストリームに対する公平性は議論の的となっている。Google のプレゼンテーションでは BBRv1 が CUBIC とうまく共存できることが示されているが、[28] Geoff Huston や Hock、Bless、Zitterbart などの研究者は、BBRv1 が他のストリームに対して不公平であり、スケーラブルではないことを発見した。[33] Hock らはまた、Linux 4.9 の BBR 実装において「キューイング遅延の増加、不公平、大量のパケット損失などの深刻な固有の問題」を発見した。[34] Soheil Abbasloo ら (C2TCP の著者) は、BBRv1 がセルラー ネットワークなどの動的環境ではうまく機能しないことを示す。[11] [12]彼らはまた、BBR に不公平の問題があることも示している。たとえば、CUBICフロー（Linux、Android、MacOSのデフォルトのTCP実装）がネットワーク内でBBRフローと共存する場合、BBRフローはCUBICフローを支配し、リンク帯域幅全体をCUBICフローから取得することができます（ [11]の図16を参照）。
バージョン2は、CUBICなどの損失ベースの輻輳管理と並行して動作する場合の不公平性の問題に対処しようとしています。[35] BBRv2では、BBRv1で使用されるモデルが拡張され、パケット損失に関する情報と明示的輻輳通知（ECN）からの情報が含まれるようになりました。[36] BBRv2はBBRv1よりもスループットが低い場合がありますが、一般的にはグッドプットが優れていると考えられています。[引用が必要]
バージョン3（BBRv3）では、BBRv2の2つのバグ（帯域幅プローブの早期終了、帯域幅収束）が修正され、パフォーマンスチューニングが行われている。また、データセンター内部リンクに最適化されたBBR.Swiftと呼ばれる変種もあり、これはネットワークRTT（受信遅延を除く）を主な輻輳制御信号として使用する。[36]
C2TCP
セルラー制御遅延TCP（C2TCP）[11] [12]は、ネットワークデバイスの変更を必要とせずに、さまざまなアプリケーションのさまざまなQoS要件を満たすことができる柔軟なエンドツーエンドのTCPアプローチが不足していることから生まれました。C2TCPは、現在のLTEや将来の5Gセルラーネットワークなどの非常に動的な環境で、仮想現実、ビデオ会議、オンラインゲーム、車両通信システムなどのアプリケーションの超低遅延および高帯域幅の要件を満たすことを目的としています。C2TCPは、損失ベースTCP（Reno、NewReno、 CUBIC、BICなど）上のアドオンとして機能し、サーバー側にインストールするだけで、パケットの平均遅延をアプリケーションによって設定された目的の遅延に制限します。
NYUの研究者[37]は、C2TCPがさまざまな最先端のTCP方式の遅延および遅延変動性能を上回ることを示しました。たとえば、BBR、CUBIC、Westwoodと比較して、C2TCPはさまざまなセルラーネットワーク環境でパケットの平均遅延をそれぞれ約250%、900%、700%削減することを示しました。[11]
エラスティックTCP
Elastic-TCP は、クラウド コンピューティングをサポートするために、高 BDP ネットワークでの帯域幅利用率を高めるために 2019 年 2 月に提案されました。これは Linux カーネル用に設計された Linux ベースの CCA です。これは、ウィンドウ相関重み付け関数 (WWF) と呼ばれる新しいメカニズムを使用して、損失遅延ベースのアプローチを採用する受信側アルゴリズムです。人間による調整を必要とせずに、さまざまなネットワーク特性に対応できる高いレベルの弾力性を備えています。NS-2 シミュレーターとテストベッドを使用して、Compound TCP (MS Windows のデフォルトの CCA)、CUBIC (Linux のデフォルト)、TCP-BBR (Google が使用する Linux 4.9 のデフォルト) とパフォーマンスを比較して評価されました。Elastic-TCP は、平均スループット、損失率、遅延の点で全体的なパフォーマンスを大幅に向上させます。[38]
NATCP
Soheil Abbasloo らは、マルチアクセス エッジ コンピューティング(MEC) をターゲットとした、議論の多いTCP設計である NATCP (Network-Assisted TCP) [13]を提案しました。NATCP の重要なアイデアは、ネットワークの特性が事前にわかっていれば、TCP は異なる設計になっていただろうというものです。そのため、NATCP は、現在の MEC ベースのセルラー アーキテクチャで利用可能な機能とプロパティを使用して、TCP のパフォーマンスを最適なパフォーマンスに近づけます。NATCP は、ネットワークから近くにあるサーバーへの帯域外フィードバックを使用します。セルラー アクセス リンクの容量とネットワークの最小 RTT を含むネットワークからのフィードバックは、サーバーが送信速度を調整するようにガイドします。予備的な結果が示すように、NATCP は最先端の TCP スキームよりも優れています。[13] [39]
その他のTCP輻輳回避アルゴリズム
- 高速TCP
- 一般化されたFAST TCP [40]
- H-TCP
- データセンターTCP
- 高速TCP
- HSTCP-LP [41]
- TCP-イリノイ
- TCP-LP [41]
- TCPサック
- スケーラブルTCP
- TCPベノ[42]
- ウエストウッド
- エクセレントコーポレーション[43]
- イェアH-TCP [44]
- TCP-FIT [45]
- 正規化された時間間隔による輻輳回避（CANIT）[46]
- TCP/IPネットワークのための遺伝的アルゴリズムに基づく非線形ニューラルネットワーク輻輳制御[47]
- D-TCP [48]
- ネクスジェンD-TCP [49]
- コパ[50]
TCP New Reno は最も一般的に実装されたアルゴリズムであり[引用が必要]、 SACK サポートは非常に一般的であり[引用が必要]、Reno/New Reno の拡張です。その他のほとんどは、まだ評価が必要な競合提案です。2.6.8 以降、Linux カーネルはデフォルトの実装を New Reno からBICに切り替えました。デフォルトの実装は、2.6.19 バージョンで再び CUBIC に変更されました。バージョン 14.X 以降のFreeBSDでも、CUBIC がデフォルトのアルゴリズムとして使用されています。[51]以前のバージョンでは New Reno を使用していました。ただし、FreeBSD は他の選択肢をいくつかサポートしています。[52]
キューイング方式に関係なく、フローごとの帯域幅と遅延の積が増加すると、TCP は非効率になり、不安定になりやすくなります。インターネットが進化して非常に高帯域幅の光リンクが組み込まれるようになると、この問題はますます重要になります。
TCPインタラクティブ（iTCP）[53]は、アプリケーションがTCPイベントをサブスクライブし、それに応じて応答することを可能にし、TCP層の外部からTCPにさまざまな機能拡張を可能にします。ほとんどのTCP輻輳制御は内部的に動作します。iTCPはさらに、ソース生成レートを制御するなど、高度なアプリケーションが輻輳制御に直接参加できるようにします。
Zeta-TCPは、遅延と損失率の両方の尺度から輻輳を検出します。グッドプットを最大化するために、Zeta-TCPは輻輳の可能性に基づいてさまざまな輻輳ウィンドウバックオフ戦略を適用します。また、パケット損失を正確に検出し、再送信タイムアウトを回避し、着信（ダウンロード）トラフィックを加速および制御するための他の改善も備えています。[54]
ネットワーク認識による分類
CCAはネットワーク認識に関連して分類される可能性があり、これはこれらのアルゴリズムがネットワークの状態をどの程度認識しているかを意味します。これはブラックボックス、グレーボックス、グリーンボックスの3つの主要なカテゴリで構成されます。[55]
ブラック ボックス アルゴリズムは、輻輳制御の盲目的な方法を提供します。輻輳時に受信したバイナリ フィードバックのみに基づいて動作し、管理するネットワークの状態に関する知識を一切想定しません。
グレー ボックス アルゴリズムは、RTT の変化やパケット到着率などの時間ベースの測定を使用して、帯域幅、フロー競合、およびネットワーク状態に関するその他の知識の測定と推定を取得します。
グリーン ボックス アルゴリズムは、システムの実行中に任意の時点で各フローに割り当てるべき合計帯域幅の公平な割合を測定する、輻輳制御のバイモーダル メソッドを提供します。
ブラックボックス
- 高速TCP [56]
- BIC TCP (Binary Increase Congestion Control Protocol) は、ネットワークが完全に利用される時間を最大化するために、各輻輳イベントの後に、ウィンドウがイベント前のウィンドウと等しくなるまでソース レートを凹状に増加させます。その後、積極的にプローブを実行します。
- CUBIC TCP – BIC のより攻撃性が低く、より体系的な派生であり、ウィンドウは最後の輻輳イベントからの時間の 3 次関数であり、変曲点はイベント前のウィンドウに設定されます。
- AIMD-FC（高速収束を伴う加法的増加乗法的減少）、AIMDの改良版。[57]
- 二項メカニズム
- SIMD プロトコル
- ゲイムド
灰色のボックス
- TCP Vegas – キューイング遅延を推定し、フローごとに一定数のパケットがネットワーク内でキューイングされるようにウィンドウを直線的に増減します。Vegas は比例公平性を実装します。
- FAST TCP – Vegas と同じ均衡を実現しますが、線形増加ではなく比例制御を使用し、安定性を確保する目的で帯域幅が増加するにつれてゲインを意図的に縮小します。
- TCP BBR – キューイング遅延を推定しますが、指数関数的増加を使用します。公平性と遅延の減少のために、意図的に定期的に速度を落とします。
- TCP-Westwood (TCPW) – 損失が発生すると、ウィンドウは送信者の帯域幅遅延積（測定された最小のRTTに観測されたACK受信速度を乗じたもの）の推定値にリセットされます。[58]
- C2TCP [12] [11]
- TFRC [59]
- TCP-リアル
- TCP-ジャージー
緑のボックス
- バイモーダル メカニズム - バイモーダル輻輳回避および制御メカニズム。
- ルータによって実装されるシグナリング方式
- ネットワーク支援輻輳制御
- NATCP [13] – ネットワーク支援TCPは、ネットワークの最小RTTとセルラーアクセスリンクの容量を示す帯域外明示的フィードバックを使用します。
- 可変構造輻輳制御プロトコル (VCP) は、2 つの ECN ビットを使用して、ネットワークの輻輳状態を明示的にフィードバックします。エンド ホスト側のアルゴリズムも含まれています。[引用が必要]
次のアルゴリズムでは、TCP パケット構造にカスタム フィールドを追加する必要があります。
- 明示的制御プロトコル（XCP） - XCPパケットは、送信者の輻輳ウィンドウの増加または減少を示すフィードバックフィールドを含む輻輳ヘッダーを運びます。XCPルータは、効率性と公平性のためにフィードバック値を明示的に設定します。[60]
- MaxNet – フローのパス上のルータの最大輻輳レベルを伝送する単一のヘッダーフィールドを使用します。レートはこの最大輻輳の関数として設定され、最大最小公平性が実現されます。[61]
- JetMax は、MaxNet と同様に、最大輻輳信号にのみ応答しますが、他のオーバーヘッド フィールドも伝送します。
Linux の使用
- BIC は、Linux カーネル 2.6.8 から 2.6.18 までデフォルトで使用されます。(2004 年 8 月 – 2006 年 9 月)
- CUBICはLinuxカーネルバージョン2.6.19以降でデフォルトで使用されている。（2006年11月）[62]
- PRR は、バージョン 3.2 以降、損失回復を改善するために Linux カーネルに組み込まれています。(2012 年 1 月)
- BBRv1 はバージョン 4.9 以降、モデルベースの輻輳制御を可能にするために Linux カーネルに組み込まれています。(2016 年 12 月)
参照
- 伝送制御プロトコル §§ 輻輳制御と開発
- ネットワークの混雑 § 緩和策
- 低遅延バックグラウンドトランスポート(LEDBAT)
注記
- ^ 実際には、受信側はACKを遅延させる可能性があり、通常は受信するセグメント2つにつき1つのACKを送信する[2]
参考文献
- ^ ジェイコブソン＆カレルズ 1988.
- ^ ab W. Stevens (1997 年 1 月). TCP スロースタート、輻輳回避、高速再送信、および高速回復アルゴリズム。doi : 10.17487 /RFC2001 . RFC 2001。
- ^ ab M. Allman; S. Floyd; C. Partridge (2002 年 10 月). TCP の初期ウィンドウの増加。doi : 10.17487 /RFC3390 . RFC 3390。
- ^ 「シーケンス図による TCP 輻輳回避の説明」( PDF)。eventhelix.com 。
- ^ Chiu, Dah-Ming; Raj Jain (1989). 「コンピュータネットワークにおける輻輳回避のための増加および減少アルゴリズムの分析」.コンピュータネットワークとISDNシステム. 17 : 1–14. CiteSeerX 10.1.1.136.8108 . doi :10.1016/0169-7552(89)90019-6.
- ^ Allman, M.; Paxson, V. (2009 年 9 月) . TCP 輻輳制御。インターネット技術タスクフォース。sec. 3.1。doi : 10.17487 /RFC5681。RFC 5681。2021年3月 4 日に閲覧。
- ^ Blanton, Ethan; Paxson, Vern; Allman, Mark (2009 年 9 月)。「TCP 輻輳制御」。インターネット エンジニアリング タスク フォース。
{{cite journal}}:ジャーナルを引用するには|journal=(ヘルプ)が必要です - ^ Corbet, Jonathan. 「TCP 初期輻輳ウィンドウの拡大」 LWN . 2012 年10 月 10 日閲覧。
- ^ Nick O'Neill. 「サイトの動作が遅くなる原因は？ いいねボタンが原因かも」AllFacebook、2010年11月10日。2012年9月12日閲覧。
- ^ Fall, Kevin; Sally Floyd (1996 年 7 月). 「シミュレーションに基づく Tahoe、Reno、SACK TCP の比較」(PDF) . Computer Communications Review . 26 (3): 5–21. CiteSeerX 10.1.1.586.2403 . doi :10.1145/235160.235162. S2CID 7459148.
- ^ abcdef Abbasloo, S.; Xu, Y.; Chao, HJ (2019). 「C2TCP: 厳格な遅延要件を満たす柔軟なセルラーTCP」. IEEE Journal on Selected Areas in Communications . 37 (4): 918–932. arXiv : 1810.13241 . doi :10.1109/JSAC.2019.2898758. ISSN 0733-8716. S2CID 53107038.
- ^ abcd Abbasloo, S.; Li, T.; Xu, Y.; Chao, HJ (2018 年 5 月)。「Cellular Controlled Delay TCP (C2TCP)」。2018 IFIPネットワーキング カンファレンス (IFIP ネットワーキング) およびワークショップ。pp. 118–126。arXiv : 1807.02689。Bibcode : 2018arXiv180702689A。doi : 10.23919 /IFIPNetworking.2018.8696844。ISBN 978-3-903176-08-9. S2CID 49650788。
- ^ abcd Abbasloo et al. 2019.
- ^ Cardwell, Neal; Cheng, Yuchung; Gunn, C. Stephen; Yeganeh, Soheil Hassas; Jacobson, Van (2016). 「BBR: 輻輳ベースの輻輳制御」.キュー. 14 (5): 20–53. doi : 10.1145/3012426.3022184 .
- ^ 黒瀬・ロス 2008、284頁。
- ^ 黒瀬・ロス 2012、277頁。
- ^ VasanthiN., V.; SinghM., Ajith; Kumar, Romen; Hemalatha, M. (2011). 「ワイヤレス/有線ネットワーク上の TCP のパフォーマンスを向上させるためのプロトコルとアルゴリズムの評価」。Das, Vinu V; Thankachan, Nessy (編)。計算知能と情報技術。コンピュータと情報科学における通信。第 250 巻。Springer。pp. 693–697。doi :10.1007 / 978-3-642-25734-6_120。ISBN 978-3-642-25733-9。
- ^ 「TCP 輻輳制御アルゴリズムのパフォーマンス分析」(PDF) 。2012年3 月 26 日閲覧。
- ^ 「DD-WRT changelog」 。 2012年1月2日閲覧。
- ^ 「Hyblaホームページ」。2007年10月11日時点のオリジナルよりアーカイブ。2007年3月4日閲覧。
- ^ Caini, Carlo; Firrincieli, Rosario (2004). 「TCP Hybla: 異機種ネットワーク向けの TCP 拡張機能」. International Journal of Satellite Communications and Networking . 22 (5): 547–566. doi :10.1002/sat.799. ISSN 1542-0973. S2CID 2360535.
- ^ Caini, C.; Firrincieli, R.; Lacamera, D. (2009). 「衛星環境における TCP バリアントの比較パフォーマンス評価」。2009 IEEE 国際通信会議。pp. 1–5。doi : 10.1109 /ICC.2009.5198834。S2CID 8352762 。
- ^ V. , Jacobson; RT, Braden. 長時間遅延パスのTCP拡張。doi : 10.17487/ RFC1072。RFC 1072 。
- ^ Alrshah, MA; Othman, M.; Ali, B.; Hanapi, ZM (2015 年 9 月)。「Agile-SD: 高速および短距離ネットワークをサポートするための Linux ベースの TCP 輻輳制御アルゴリズム」。Journal of Network and Computer Applications。55 : 181–190。arXiv : 1601.05908。doi : 10.1016/j.jnca.2015.05.011。S2CID 2645016 。
- ^ Mathis, M.; Dukkipati, N.; Cheng, Y. (2013). TCP の比例レート削減。doi : 10.17487 / RFC6937。RFC 6937 。
- ^ コルベット、ジョナサン。「LPC: ネットの高速化」。2014年6月6日閲覧。
- ^ 「Linux 3.2 – Linux Kernel Newbies」。2014年6月6日閲覧。
- ^ ab 「BBR: 輻輳ベースの輻輳制御」 。 2017年8月25日閲覧。
- ^ Cheng, Yuchung; Cardwell, Neal; Yeganeh, Soheil Hassas; Jacobson, Van (2017 年 7 月 3 日)。「Delivery Rate Estimation」。インターネット エンジニアリング タスク フォース。2017年8 月 25 日閲覧。
{{cite journal}}:ジャーナルを引用するには|journal=(ヘルプ)が必要です - ^ 「TCP BBR 輻輳制御が GCP に導入され、インターネットがさらに高速化」 。2017年8 月 25 日閲覧。
- ^ 「BBR輻輳制御 [LWN.net]」。lwn.net。
- ^ 「BBR アップデート」。インターネット エンジニアリング タスク フォース。
- ^ 「TCP と BBR」(PDF) 。2018 年5 月 27 日閲覧。
- ^ 「BBR輻輳制御の実験的評価」(PDF) 。 2018年5月27日閲覧。
- ^ 「TCP BBRv2のパフォーマンス評価」 。 2021年1月12日閲覧。
- ^ ab Google TCP BBR チーム; Google QUIC BBR チーム (2023 年 7 月 26 日)。BBRv3: アルゴリズムのバグ修正とパブリック インターネット展開。IETF 117: サンフランシスコ。
- ^ 「Cellular Controlled Delay TCP (C2TCP)」. wp.nyu.edu . 2019年4月27日閲覧。
- ^ Alrshah, MA; Al-Maqri, MA; Othman, M. (2019 年 6 月). 「Elastic-TCP: 高 BDP ネットワークに適応する柔軟な輻輳制御アルゴリズム」. IEEE Systems Journal . 13 (2): 1336–1346. arXiv : 1904.13105 . Bibcode :2019ISysJ..13.1336A. doi : 10.1109/JSYST.2019.2896195 .
- ^ Abbasloo、Soheil (2019 年 6 月 3 日)、GitHub – Soheil-ab/natcp 、 2019 年8 月 5 日取得
- ^ Yuan, Cao; Tan, Liansheng; Andrew, Lachlan LH; Zhang, Wei; Zukerman, Moshe (2008 年 6 月 6 日). 「一般化された FAST TCP スキーム」. Computer Communications . 31 (14): 3242–3249. doi :10.1016/j.comcom.2008.05.028. hdl : 1959.3/44051 . S2CID 17988768.
- ^ ab "Rice Networks Group".
- ^ 「TCP Veno: ワイヤレス アクセス ネットワーク経由の伝送のための TCP 拡張機能」(PDF)。IEEE Journal on Selected Areas in Communication。
- ^ 「XCP @ ISI」。
- ^ 「高速 TPC」(PDF) . csc.lsu.edu .
- ^ “アーカイブコピー”. 2011年4月3日時点のオリジナルよりアーカイブ。 2011年3月5日閲覧。
{{cite web}}: CS1 maint: archived copy as title (link) - ^ Benaboud, H.; Berqia, A.; Mikou, N. (2002). 「TCP プロトコルにおける CANIT アルゴリズムの分析的研究」ACM SIGMETRICS パフォーマンス評価レビュー30 ( 3): 20. doi :10.1145/605521.605530. S2CID 6637174.
- ^ Rouhani, Modjtaba (2010)。「TCP/IP ネットワーク向け遺伝的アルゴリズムに基づく非線形ニューラル ネットワーク輻輳制御」。2010年第 2 回計算知能、通信システム、ネットワークに関する国際会議。pp. 1–6。doi :10.1109/CICSyN.2010.21。ISBN 978-1-4244-7837-8.S2CID 15126416 。
- ^ Kanagarathinam, Madhan Raj; Singh, Sukhdeep; Sandeep, Irlanki; Roy, Abhishek; Saxena, Navrati (2018 年 1 月)。「D-TCP: 次世代モバイル ネットワーク向け動的 TCP 輻輳制御アルゴリズム」。2018年15 回 IEEE 年次消費者通信およびネットワーク会議 (CCNC) 。pp . 1–6。doi :10.1109/CCNC.2018.8319185。ISBN 978-1-5386-4790-5. S2CID 3991163。
- ^ Kanagarathinam, Madhan Raj; Singh, Sukhdeep; Sandeep, Irlanki; Kim, Hanseok; Maheshwari, Mukesh Kumar; Hwang, Jaehyun; Roy, Abhishek; Saxena, Navrati (2020). 「NexGen D-TCP: 次世代の動的 TCP 輻輳制御アルゴリズム」. IEEE Access . 8 : 164482–164496. Bibcode :2020IEEEA...8p4482K. doi : 10.1109/ACCESS.2020.3022284 . ISSN 2169-3536. S2CID 221846931.
- ^ Arun, Venkat; Balakrishnan, Hari (2018). 「Copa: インターネットのための実用的な遅延ベースの輻輳制御」。第 15 回 USENIX ネットワーク システム設計および実装シンポジウム (NSDI 18) : 329–342。ISBN 978-1-939133-01-4。
- ^ 「tcp: CUBIC をデフォルトの輻輳制御メカニズムにする」。2022 年 9 月 13 日。
- ^ 「5 つの新しい TCP 輻輳制御アルゴリズム プロジェクトの概要」。2011 年 3 月 8 日。
- ^ 「iTCP – インタラクティブ トランスポート プロトコル – メディアネット ラボ、ケント州立大学」。
- ^ 「ホワイトペーパー: Zeta-TCP – インテリジェントで適応型の非対称 TCP アクセラレーション」(PDF) 。2019年12 月 6 日閲覧。
- ^ Lefteris Mamatas、Tobias Harks、Vassilis Tsaoussidis (2007 年 1 月)。「パケット ネットワークにおける輻輳制御へのアプローチ」(PDF)。Journal of Internet Engineering。1 ( 1)。2014 年 2 月 21日時点のオリジナル(PDF)からのアーカイブ。
- ^ 「HighSpeed TCP」. icir.org .
- ^ 「AIMD-FCホームページ」。neu.edu。2009年1月13日時点のオリジナルよりアーカイブ。2016年3月13日閲覧。
- ^ 「ネットワーク研究ラボへようこそ」. cs.ucla.edu .
- ^ 「ユニキャスト アプリケーションのための方程式ベースの輻輳制御」. icir.org。
- ^ Katabi, Dina; Handley, Mark; Rohrs, Charlie (2002)。「高帯域幅遅延積ネットワークの輻輳制御」。2002年コンピュータ通信のアプリケーション、テクノロジ、アーキテクチャ、プロトコルに関する会議の議事録。米国ニューヨーク州ニューヨーク: ACM プレス。p. 89。doi : 10.1145 / 633025.633035。ISBN 1-58113-570-X。
- ^ 「MaxNet -- Max-Min 公平で安定した明示的シグナリング輻輳制御」. netlab.caltech.edu .
- ^ 「TCP輻輳制御：システムアプローチ。Peterson、Brakmo、Davie」 。 2024年5月17日閲覧。
出典
- 黒瀬, ジェームズ; ロス, キース (2008).コンピュータ ネットワーキング: トップダウン アプローチ(第 4 版). Addison Wesley. ISBN 978-0-13-607967-5。
- 黒瀬, ジェームズ; ロス, キース (2012).コンピュータネットワーキング: トップダウンアプローチ(第 6 版). ピアソン. ISBN 978-0-13-285620-1。
- Abbasloo, Soheil; Xu, Yang; Chao, H. Jonathon; Shi, Hang; Kozat, Ulas C.; Ye, Yinghua (2019)。「モバイル エッジでのネットワーク支援 TCP による最適なパフォーマンスの実現」。第 2 回 USENIX ワークショップ「エッジ コンピューティングのホット トピック (HotEdge 19)」。ワシントン州レントン: USENIX 協会。
- Afanasyev, A.; N. Tilley; P. Reiher; L. Kleinrock (2010). 「TCP のホスト間輻輳制御」(PDF) . IEEE Communications Surveys and Tutorials . 12 (3): 304–342. CiteSeerX 10.1.1.228.3080 . doi :10.1109/SURV.2010.042710.00114. S2CID 8638824.
- Jacobson , Van ; Karels, Michael J. (1988 年 11 月)。「輻輳回避と制御」( PDF)。ACM SIGCOMM Computer Communication Review。18 ( 4): 314–329。doi :10.1145/52325.52356。
外部リンク
- パケットネットワークにおける輻輳制御へのアプローチ
- 輻輳制御に関する論文
- Allman, Mark; Paxson, Vern ; Stevens, W. Richard (1999 年 4 月)。「高速再送信/高速回復」。TCP 輻輳制御。インターネット エンジニアリング タスク フォース。sec. 3.2。doi : 10.17487/RFC2581。RFC 2581。2010年5月1 日に取得。
- TCP 輻輳処理と輻輳回避アルゴリズム – TCP/IP ガイド