TCP輻輳制御

伝送制御プロトコル（TCP）は、 AIMD（加算的増加／乗算的減少）方式の様々な側面を含む輻輳制御アルゴリズムに加え、スロースタート[1]や輻輳ウィンドウ（CWND）などの他の方式を用いて輻輳回避を実現します。TCP輻輳回避アルゴリズムは、インターネットにおける輻輳制御の基本的な基盤です。 [2] [3] [4]エンドツーエンドの原則に基づき、輻輳制御は主にインターネットホストの機能であり、ネットワーク自体の機能ではありません。インターネットに接続するコンピュータのオペレーティングシステムのプロトコルスタックには、このアルゴリズムの様々なバリエーションとバージョンが実装されています。

輻輳によるパケットの崩壊を回避するため、TCPは多面的な輻輳制御戦略を採用しています。TCPは各接続ごとにCWND（輻輳ウィンドウ）を保持し、エンドツーエンドで転送中の未確認パケットの総数を制限します。これは、TCPのフロー制御に用いられるスライディングウィンドウに似ています。

加算的増加/乗算的減少

加法的増加/乗法的減少（AIMD）アルゴリズムは、閉ループ制御アルゴリズムです。AIMDは、輻輳発生時に輻輳ウィンドウの線形増加と指数関数的減少を組み合わせます。AIMD輻輳制御を使用する複数のフローは、最終的に競合リンクを均等に使用するように収束します。[5]

これは、輻輳回避状態についてRFC  5681で説明されているアルゴリズムです。[6]

輻輳ウィンドウ

TCPにおいて、輻輳ウィンドウ（CWND）は、一度に送信できるバイト数を決定する要素の一つです。輻輳ウィンドウは送信側によって管理され、送信側と受信側間のリンクが過剰なトラフィックによって過負荷になるのを防ぐ手段です。これは、受信側の過負荷を防ぐために送信側が管理するスライディングウィンドウとは混同しないように注意する必要があります。輻輳ウィンドウは、リンク上の輻輳の程度を推定することで計算されます。

接続が確立されると、各ホストで独立して管理される輻輳ウィンドウは、その接続で許可される最大セグメントサイズ（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は輻輳回避アルゴリズムに切り替えます。CWNDはRTTごとに最大1MSS増加します。一般的な計算式では、新しい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はデフォルトで累積確認応答を使用するため、中間のパケットに確認応答する必要はありません。

アルゴリズム

RenoとTahoeという名前はBSD UNIXオペレーティングシステムのリリース名であり、少なくとも1996年のKevin FallとSally Floydの論文では輻輳制御アルゴリズム（CCA）を指すために使用されていました。[10] [検証失敗]

以下は、次の特性に従って分類できる 1 つの例です。

  1. ネットワークから受け取ったフィードバックの種類と量
  2. 現在のインターネット上での段階的な展開可能性
  3. 改善を目指すパフォーマンスの側面：高帯域幅遅延積ネットワーク（B）、損失リンク（L）、公平性（F）、短いフローの優位性（S）、可変レートリンク（V）、収束速度（C）
  4. 使用される公平性の基準

いくつかのよく知られた輻輳回避メカニズムは、この方式によって次のように分類されます。

変異体フィードバック必要な変更利点公平性
（新）リノ損失——遅れ
ラスベガス遅れ送信者損失が少ない比例
高速損失送信者高帯域幅
ビック損失送信者高帯域幅
キュービック損失送信者高帯域幅
C2TCP [11] [12]紛失/遅延送信者超低遅延と高帯域幅
NATCP [13]マルチビット信号送信者ほぼ最適なパフォーマンス
エラスティックTCP紛失/遅延送信者高帯域幅/短距離および長距離
アジャイルTCP損失送信者高帯域幅/短距離
H-TCP損失送信者高帯域幅
速い遅れ送信者高帯域幅比例
複合TCP紛失/遅延送信者高帯域幅比例
ウェストウッド紛失/遅延送信者損失のあるリンク
ジャージー紛失/遅延送信者損失のあるリンク
BBR [14]遅れ送信者BLVC、バッファブロート
クランプマルチビット信号受信機、ルーター変動レートリンク最大最小
TFRC損失送信者、受信者再送信なし最小遅延
XCPマルチビット信号送信者、受信者、ルーターBLFC最大最小
VCP2ビット信号送信者、受信者、ルーターBLF比例
マックスネットマルチビット信号送信者、受信者、ルーターBLFSC最大最小
ジェットマックスマルチビット信号送信者、受信者、ルーター高帯域幅最大最小
赤損失ルーター遅延の削減
プラハ[15]シングルビット信号送信者、受信者、ルーター低遅延、低損失、スケーラブルなスループット（L4S [16]）
ECNシングルビット信号送信者、受信者、ルーター損失の削減

TCP タホとリノ

TCP TahoeアルゴリズムとRenoアルゴリズムは、それぞれが初めて登場した4.3BSDオペレーティングシステムのバージョンまたはフレーバーにちなんで、遡及的に命名されました（これらのバージョンは、タホ湖とネバダ州リノ市にちなんで名付けられました）。Tahoeアルゴリズムは、CCI Power 6/32 "Tahoe"ミニコンピュータをサポートするために作成された4.3BSD-Tahoeで初めて登場し、後に4.3BSD Networking Release 1の一部としてAT&T以外のライセンスにも利用可能になりました。これにより、広く普及し、実装されました。4.3BSD-Renoには改良が加えられ、その後Networking Release 2、そして4.4BSD-Liteとして一般に公開されました。

どちらも再送信タイムアウト (RTO) と重複 ACK をパケット損失イベントと見なしますが、Tahoe と Reno の動作は主に重複 ACK への反応方法が異なります。

  • タホ：重複したACKを3つ受信した場合（つまり、同じパケットを確認する4つのACKで、データにピギーバックされておらず、受信側のアドバタイズされたウィンドウを変更しない場合）、タホは高速再送信を実行し、スロースタートしきい値を現在の輻輳ウィンドウの半分に設定し、輻輳ウィンドウを1 MSSに減らし、スロースタート状態にリセットします。[17]
  • リノ：重複したACKを3つ受信した場合、リノは高速再送を実行し、輻輳ウィンドウを半分にすることでスロースタートフェーズをスキップし（タホのように1MSSに設定する代わりに）、ssthreshを新しい輻輳ウィンドウに等しく設定し、高速回復と呼ばれるフェーズに入ります。[18]

Tahoe と Reno の両方で、ACK がタイムアウト (RTO タイムアウト) するとスロー スタートが使用され、両方のアルゴリズムで輻輳ウィンドウが 1 MSS に削減されます。[引用が必要]

TCP ニューリノ

RFC 6582 ( RFC  3782 およびRFC 2582 の以前の定義を廃止)で定義された TCP New Reno は 、TCP Reno の高速回復フェーズ中の再送信を改善します。

高速回復中は、送信ウィンドウをいっぱいに保つために、返される重複 ACK ごとに、輻輳ウィンドウの最後から新しい未送信パケットが送信されます。

Renoとの違いは、New Renoではssthreshを即座に半分にしない点です。これにより、複数のパケットロスが発生した場合にウィンドウが過度に縮小される可能性があります。New Renoは、すべてのデータを確認するまで高速リカバリを終了せず、ssthreshをリセットしません。

再送後、新たに確認されたデータには次の 2 つのケースがあります。

  • 完全な確認応答: ACKは送信されたすべての中間セグメントを確認し、ssthreshは変更できませんが、cwndはssthreshに設定できます。
  • 部分的な確認応答：ACKはすべてのデータを確認するものではありません。これは、別の損失が発生する可能性があることを意味します。許可されている場合は、最初の未確認セグメントを再送信してください。

回復が必要なデータ量を記録するため、 recoverと呼ばれる変数を使用します。再送タイムアウト後、送信されたシーケンス番号の最大値がrecover変数に記録され、高速回復手順が終了します。このシーケンス番号が確認されると、TCPは輻輳回避状態に戻ります。

New Renoでは、パケットロスがないにもかかわらず、パケットシーケンス番号が3つ以上入れ替わった場合に問題が発生します。この場合、New Renoは誤って高速リカバリモードに入ります。入れ替わったパケットが配信されると、重複した不要な再送が直ちに発生します。

新しいRenoは、低いパケットエラー率ではSACKと同等の性能を発揮し、高いエラー率ではRenoを大幅に上回ります。[19]

TCP ベガス

1990年代半ばまで、TCPのタイムアウト設定と往復遅延の測定は、送信バッファ内の最後の送信パケットのみに基づいていました。アリゾナ大学の研究者ラリー・ピーターソンとローレンス・ブラクモは、送信バッファ内のすべてのパケットに対してタイムアウトが設定され、往復遅延が測定されるTCP Vegasを導入しました。さらに、TCP Vegasは輻輳ウィンドウを加算的に増加させます。2012年に行われた様々なTCP CCAの比較研究では、TCP Vegasが最もスムーズで、次いでTCP CUBICが続きました。[20]

TCP Vegasはピーターソンの研究室以外では広く導入されていませんでしたが、 DD-WRTファームウェアv24 SP2のデフォルトの輻輳制御方法として選択されました。 [21]

TCP ハイブラ

TCP Hybla [22] [23]は、高遅延の地上または衛星無線リンクを使用するTCP接続に対するペナルティを排除することを目的としています。Hyblaの改良は、輻輳ウィンドウのダイナミクスの解析的評価に基づいています。[24]

TCP BIC

バイナリ増加輻輳制御（BIC）は、ロングファットネットワーク（LFN）と呼ばれる高遅延の高速ネットワーク向けに最適化されたCCAを備えたTCP実装です。[25] BICはLinuxカーネル2.6.8から2.6.18でデフォルトで使用されています。[要出典]

TCPキュービック

CUBICはBICのより緩やかで体系的な派生モデルであり、ウィンドウは最後の輻輳イベントからの時間の3次関数となり、変曲点はイベント前のウィンドウに設定されます。CUBICは、Linuxカーネルバージョン2.6.19以降でデフォルトで使用されます。

アジャイルSD TCP

Agile-SDは、Linuxカーネル向けに設計されたLinuxベースのCCAです。受信側アルゴリズムで、アジリティファクタ（AF）と呼ばれる新しいメカニズムを用いた損失ベースのアプローチを採用し、特に適用されるバッファサイズが小さい場合に、ローカルエリアネットワークや光ファイバーネットワークなどの高速・短距離ネットワーク（低帯域幅遅延積ネットワーク）での帯域幅利用率を向上させます。[26] NS-2シミュレータを使用して、Compound TCP（MS WindowsのデフォルトCCA）およびCUBIC（LinuxのデフォルトCCA）と性能を比較評価しました。平均スループットにおいて、全体的な性能が最大55%向上します。

TCP ウェストウッド+

Westwood+ は、TCP Reno の送信側のみの修正版であり、有線ネットワークと無線ネットワークの両方で TCP 輻輳制御のパフォーマンスを最適化します。TCP Westwood+ は、エンドツーエンドの帯域幅推定に基づいて、輻輳エピソード後、つまり 3 回の重複 ACK またはタイムアウト後に輻輳ウィンドウとスロースタートしきい値を設定します。帯域幅は、確認応答パケットを返すレートを平均化することで推定されます。3 回の重複 ACK 後に輻輳ウィンドウを盲目的に半分にする TCP Reno とは対照的に、TCP Westwood+ は、輻輳が発生した時点で利用可能な帯域幅の推定値を考慮して、スロースタートしきい値と輻輳ウィンドウを適応的に設定します。Reno および New Reno と比較して、Westwood+ は無線リンクでのスループットを大幅に向上させ、有線ネットワークでの公平性を改善します。[要出典]

複合TCP

Compound TCPは、 2つの異なる輻輳ウィンドウを同時に維持するMicrosoftのTCP実装であり、LFNにおいて公平性を損なうことなく良好なパフォーマンスを実現することを目的としています。Microsoft Windows VistaおよびWindows Server 2008以降のWindowsバージョンで広く導入されており、以前のMicrosoft WindowsバージョンやLinuxにも移植されています。

TCP 比例レート削減

TCP比例レート削減（PRR）[27]は、リカバリ時に送信するデータの精度を向上させるために設計されたアルゴリズムです。このアルゴリズムは、リカバリ後のウィンドウサイズがスロースタートしきい値に可能な限り近づくようにします。Googleが実施したテストでは、 PRRにより平均レイテンシが3～10%削減され、リカバリタイムアウトは5%削減されました。[28] PRRはLinuxカーネルバージョン3.2以降で利用可能です。[29]

TCP BBR

ボトルネック帯域幅と往復伝播時間（BBR）は、2016年にGoogleで開発されたCCAです。[30]ほとんどのCCAは、輻輳と伝送速度の低下を検出するためにパケット損失に依存するロスベースですが、BBRはTCP Vegasと同様にモデルベースです。このアルゴリズムは、ネットワークが最新の送信データパケットを配信した際の最大帯域幅とラウンドトリップ時間を使用して、ネットワークモデルを構築します。パケット配信の累積的または選択的な確認応答ごとに、データパケットの送信からそのパケットの確認応答までの時間間隔にわたって配信されたデータ量を記録するレートサンプルが生成されます。[31]

YouTubeで実装されたBBRv1では、ネットワークスループットが平均4%向上し、一部の国では最大14%向上しました。[32] BBRはLinux 4.9以降、Linux TCPで利用可能です。[33] QUICでも利用可能です。[34]

BBRバージョン1（BBRv1）の非BBRストリームに対する公平性については議論の余地がある。GoogleのプレゼンテーションではBBRv1がCUBICと共存可能であることが示されているが、[30] Geoff HustonやHock、Bless、Zitterbartといった研究者は、BBRv1が他のストリームに対して不公平であり、スケーラブルではないと指摘している。[35] Hockらはまた、Linux 4.9のBBR実装において、「キューイング遅延の増加、不公平性、大量のパケット損失など、深刻な固有の問題」を発見した。[36] Soheil Abbaslooら（C2TCPの著者）は、BBRv1がセルラーネットワークのような動的環境では良好なパフォーマンスを発揮しないことを示す。[11] [12]彼らはまた、BBRに不公平性の問題があることも示している。例えば、CUBICフロー（Linux、Android、MacOSのデフォルトのTCP実装）がネットワーク内でBBRフローと共存する場合、BBRフローはCUBICフローを支配し、リンク帯域幅全体を取得することができます（[11]の図16を参照）。

バージョン2は、CUBICなどの損失ベースの輻輳管理と並行して動作する場合の不公平性の問題に対処しようとします。[37] BBRv2では、BBRv1で使用されるモデルが拡張され、パケット損失に関する情報と明示的輻輳通知（ECN）からの情報が含まれるようになりました。[38] BBRv2はBBRv1よりもスループットが低い場合がありますが、一般的にグッドプットが優れていると考えられています。[引用が必要] Windows 11バージョン24H2およびWindows Server 2025はBBRv2をサポートしていましたが、デフォルトでは有効になっていない可能性があります。

バージョン3（BBRv3）は、BBRv2の2つのバグ（帯域幅プロービングの早期終了、帯域幅収束）を修正し、パフォーマンスチューニングを実施しています。また、データセンター内リンク向けに最適化されたBBR.Swiftと呼ばれる亜種も存在します。これは、ネットワークRTT（受信遅延を除く）を主要な輻輳制御信号として使用します。[38]

C2TCP

セルラー制御遅延TCP（C2TCP）[11] [12]は、ネットワークデバイスの変更を必要とせずにさまざまなアプリケーションのさまざまなQoS要件を満たすことができる柔軟なエンドツーエンドのTCPアプローチが不足していることがきっかけで生まれました。C2TCPは、現在のLTEや将来の5Gセルラーネットワークなどの非常に動的な環境で、バーチャルリアリティ、ビデオ会議、オンラインゲーム、車両通信システムなどのアプリケーションの超低遅延および高帯域幅の要件を満たすことを目的としています。C2TCPはロスベースTCP（Reno、NewReno、CUBIC、BICなど）上のアドオンとして機能し、サーバー側にインストールするだけで、パケットの平均遅延をアプリケーションによって設定された望ましい遅延に制限します。

NYUの研究者[39]は、C2TCPが様々な最先端のTCP方式の遅延性能および遅延変動性能を上回ることを示しました。例えば、C2TCPは、様々なセルラーネットワーク環境において、BBR、CUBIC、Westwoodと比較して、パケットの平均遅延をそれぞれ約250%、900%、700%削減することを示しました。[11]

エラスティックTCP

Elastic-TCPは、クラウドコンピューティングをサポートする高BDPネットワークにおける帯域幅利用率を向上させるために、2019年2月に提案されました。これはLinuxカーネル向けに設計されたLinuxベースのCCAです。ウィンドウ相関重み付け関数（WWF）と呼ばれる新しいメカニズムを用いた、損失遅延ベースのアプローチを採用した受信側アルゴリズムです。人間による調整を必要とせずに、さまざまなネットワーク特性に対応できる高い弾力性を備えています。NS-2シミュレータとテストベッドを用いて、Compound TCP（MS WindowsのデフォルトCCA）、CUBIC（LinuxのデフォルトCCA）、TCP-BBR（Googleが使用するLinux 4.9のデフォルトCCA）と性能比較評価されました。Elastic-TCPは、平均スループット、損失率、遅延の点で全体的な性能を大幅に向上させます。[40]

NATCP

Soheil AbbaslooらはNATCP（Network-Assisted TCP）[13]を提案した。これは、マルチアクセスエッジコンピューティング（MEC）をターゲットとした、議論を呼ぶTCP設計である[誰によると？ ]。NATCPの核となる考え方は、ネットワークの特性が事前に分かっていれば、TCPは異なる設計になっていたであろうというものである。そのため、NATCPは、現在のMECベースのセルラーアーキテクチャで利用可能な機能と特性を活用し、TCPの性能を最適な性能に近づける。NATCPは、ネットワークから近隣のサーバーへの帯域外フィードバックを利用する。ネットワークからのフィードバックには、セルラーアクセスリンクの容量やネットワークの最小RTTなどが含まれており、サーバーは送信レートを調整するよう誘導される。予備的な結果では、NATCPは最先端のTCP方式よりも優れた性能を示している[13] [41] 。

その他のTCP輻輳回避アルゴリズム

TCP New Renoが最も広く実装されたアルゴリズムでした[要出典]。SACKのサポートは非​​常に一般的であり[要出典]、Reno/New Renoの拡張です。その他のほとんどは競合する提案であり、まだ評価が必要です。Linuxカーネル2.6.8以降、デフォルト実装がNew RenoからBICに変更されました。デフォルト実装は2.6.19バージョンで再びCUBICに変更されました。FreeBSDバージョン14.X以降でもCUBICがデフォルトアルゴリズムとして使用されています[53] 。以前のバージョンではNew Renoが使用されていました。しかし、 FreeBSDは他にも多くの選択肢をサポートしています[54] 。

フローあたりの帯域幅と遅延の積が増加すると、キューイング方式に関わらず、TCPは非効率になり、不安定になりやすくなります。これは、インターネットが超高帯域幅の光リンクを組み込むように進化するにつれて、ますます重要になります。

TCPインタラクティブ（iTCP）[55]は、アプリケーションがTCPイベントをサブスクライブし、それに応じて応答することを可能にし、TCP層の外部からTCPに様々な機能拡張を可能にします。ほとんどのTCP輻輳制御はTCP内部で動作します。iTCPはさらに、高度なアプリケーションが輻輳制御に直接参加し、ソース生成レートを制御することを可能にします。

Zeta-TCPは、遅延と損失率の両方の指標から輻輳を検出します。グッドプットを最大化するために、Zeta-TCPは輻輳の可能性に基づいて異なる輻輳ウィンドウバックオフ戦略を適用します。また、パケット損失を正確に検出し、再送タイムアウトを回避し、着信（ダウンロード）トラフィックを高速化および制御するための改良も施されています。[56]

ネットワーク認識による分類

CCAはネットワーク認識、つまりこれらのアルゴリズムがネットワークの状態をどの程度認識しているかという観点から分類することができます。これは、ブラックボックス、グレーボックス、グリーンボックスの3つの主要なカテゴリに分類されます。[57]

ブラックボックスアルゴリズムは、輻輳制御において盲目的な手法を提供します。輻輳発生時に受信したバイナリフィードバックのみに基づいて動作し、管理対象のネットワークの状態に関する知識は一切前提としません。

グレー ボックス アルゴリズムは、RTT の変化やパケット到着率などの時間ベースの測定を使用して、帯域幅、フロー競合、およびネットワーク状態に関するその他の知識の測定と推定を取得します。

グリーン ボックス アルゴリズムは、システムの実行中に任意の時点で各フローに割り当てるべき合計帯域幅の公平な割合を測定する、輻輳制御のバイモーダル メソッドを提供します。

ブラックボックス

  • 高速TCP [58]
  • BIC TCP（Binary Increase Congestion Control Protocol）は、輻輳イベントが発生するたびに、送信元レートを凹状に増加させ、ウィンドウサイズがイベント発生前の値と等しくなるまで増加させます。これにより、ネットワークが完全に利用される時間を最大化します。その後は、積極的にプローブを実行します。
  • CUBIC TCP – BIC のより攻撃性が低く、より体系的な派生であり、ウィンドウは最後の輻輳イベント以降の時間の 3 次関数であり、変曲点はイベント前のウィンドウに設定されます。
  • AIMD-FC（高速収束を伴う加法増加乗法減少）、AIMDの改良版。[59]
  • 二項メカニズム
  • SIMDプロトコル
  • ゲイムド

灰色のボックス

  • TCP Vegas – キューイング遅延を推定し、フローごとに一定数のパケットがネットワークにキューイングされるようにウィンドウを線形に増減します。Vegasは比例公平性を実装します。
  • FAST TCP – Vegas と同じ均衡を実現しますが、線形増加ではなく比例制御を使用し、安定性を確保する目的で帯域幅が増加するとゲインを意図的に縮小します。
  • TCP BBR – キューイング遅延を推定しますが、指数関数的な増加を使用します。公平性と遅延の低減のため、意図的に定期的に速度を低下させます。
  • TCP-Westwood（TCPW） – 損失が発生すると、ウィンドウは送信者の帯域幅遅延積（測定された最小のRTTに観測されたACK受信速度を乗じたもの）の推定値にリセットされます。[60]
  • C2TCP [12] [11]
  • TFRC [61]
  • TCP-リアル
  • TCP-ジャージー

緑のボックス

  • バイモーダル メカニズム – バイモーダル輻輳回避および制御メカニズム。
  • ルータによって実装されるシグナリング方式
    • ランダム早期検出(RED) は、ルーターのキュー サイズに比例してパケットをランダムにドロップし、一部のフローの乗法的減少を引き起こします。
    • 明示的輻輳通知（ECN）
  • ネットワーク支援輻輳制御
    • NATCP [13] – ネットワーク支援TCPは、ネットワークの最小RTTとセルラーアクセスリンクの容量を示す帯域外明示的フィードバックを使用します。
    • 可変構造輻輳制御プロトコル（VCP）は、2つのECNビットを用いてネットワークの輻輳状態を明示的にフィードバックします。エンドホスト側のアルゴリズムも含まれています。[要出典]

次のアルゴリズムでは、TCP パケット構造にカスタム フィールドを追加する必要があります。

  • 明示的制御プロトコル（XCP） – XCPパケットは、送信側の輻輳ウィンドウの増減を示すフィードバックフィールドを含む輻輳ヘッダーを伝送します。XCPルータは、効率性と公平性を確保するために、フィードバック値を明示的に設定します。[62]
  • MaxNet – フローのパス上のルータの最大輻輳レベルを単一のヘッダーフィールドで伝送する。レートはこの最大輻輳レベルに応じて設定され、結果として最大最小公平性が実現される。[63]
  • JetMax は、MaxNet と同様に、最大輻輳信号にのみ応答しますが、他のオーバーヘッド フィールドも伝送します。

Linuxの使用

  • BICはLinuxカーネル2.6.8から2.6.18までデフォルトで使用されます。（2004年8月～2006年9月）
  • CUBICはLinuxカーネルバージョン2.6.19以降でデフォルトで使用されています。（2006年11月）[64]
  • PRR は、バージョン 3.2 以降、損失回復を改善するために Linux カーネルに組み込まれています。(2012 年 1 月)
  • BBRv1はLinuxカーネル4.9以降に組み込まれ、モデルベースの輻輳制御を可能にしています。（2016年12月）[65]

参照

注記

  1. ^ 実際には、受信側がACKを遅らせる場合があり、通常は受信するセグメント2つにつき1つのACKを送信する[2]

参考文献

  1. ^ ジェイコブソン＆カレルズ 1988.
  2. ^ ab W. Stevens (1997年1月). TCPスロースタート、輻輳回避、高速再送、高速回復アルゴリズム. doi : 10.17487/RFC2001 . RFC 2001.
  3. ^ ab M. Allman; S. Floyd; C. Partridge (2002年10月). TCPの初期ウィンドウの拡大. doi : 10.17487/RFC3390 . RFC 3390.
  4. ^ 「TCP輻輳回避をシーケンス図で説明する」(PDF) . eventhelix.com . 2010年11月22日時点のオリジナル(PDF)からアーカイブ。 2010年11月26日閲覧。
  5. ^ Chiu, Dah-Ming; Raj Jain (1989). 「コンピュータネットワークにおける輻輳回避のための増加アルゴリズムと減少アルゴリズムの分析」.コンピュータネットワークとISDNシステム. 17 : 1– 14. CiteSeerX 10.1.1.136.8108 . doi :10.1016/0169-7552(89)90019-6. 
  6. ^ Allman, M.; Paxson, V. (2009年9月). TCP輻輳制御.インターネット技術タスクフォース. sec. 3.1. doi : 10.17487/RFC5681 . RFC 5681. 2021年3月4日閲覧。
  7. ^ Blanton, Ethan; Paxson, Vern; Allman, Mark (2009年9月). 「TCP輻輳制御」. インターネット技術タスクフォース. {{cite journal}}:ジャーナルを引用するには|journal=（ヘルプ）が必要です
  8. ^ Corbet, Jonathan (2011年2月9日). 「TCP初期輻輳ウィンドウの拡大」. LWN . 2012年10月10日閲覧。
  9. ^ ニック・オニール、「サイトの動作が遅くなる原因は？ いいねボタンかも」AllFacebook、2010年11月10日。2012年9月12日閲覧。
  10. ^ Fall, Kevin; Sally Floyd (1996年7月). 「シミュレーションに基づくTahoe、Reno、SACK TCPの比較」(PDF) . ACM SIGCOMM Computer Communication Review . 26 (3): 5– 21. CiteSeerX 10.1.1.586.2403 . doi :10.1145/235160.235162. S2CID  7459148. 
  11. ^ abcdef Abbasloo, S.; Xu, Y.; Chao, HJ (2019). 「C2TCP: 厳格な遅延要件を満たす柔軟なセルラーTCP」. IEEE Journal on Selected Areas in Communications . 37 (4): 918– 932. arXiv : 1810.13241 . Bibcode :2019IJSAC..37..918A. doi :10.1109/JSAC.2019.2898758. ISSN  0733-8716. S2CID  53107038.
  12. ^ abcd Abbasloo, S.; Li, T.; Xu, Y.; Chao, HJ (2018年5月). 「Cellular Controlled Delay TCP (C2TCP)」. 2018 IFIP Networking Conference (IFIP Networking) and Workshops . pp.  118– 126. arXiv : 1807.02689 . Bibcode :2018arXiv180702689A. doi :10.23919/IFIPNetworking.2018.8696844. ISBN 978-3-903176-08-9. S2CID  49650788。
  13. ^ abcd Abbasloo et al. 2019.
  14. ^ Cardwell, Neal; Cheng, Yuchung; Gunn, C. Stephen; Yeganeh, Soheil Hassas; Jacobson, Van (2016). 「BBR: 輻輳ベースの輻輳制御」. ACM Queue . 14 (5): 20– 53. doi : 10.1145/3012426.3022184 .
  15. ^ シェッパー、Koen De;ティルマンズ、オリヴィエ。ボブ、ブリスコー。ゴエル、ヴィディ（2024年7月24日）。 「プラハの渋滞制御」。datatracker.ietf.org。
  16. ^ 「L4S – 低遅延、低損失、スケーラブルなスループット」www.nokia.com。
  17. ^ 黒瀬・ロス 2008年、284頁。
  18. ^ 黒瀬・ロス 2012年、277頁。
  19. ^ 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。
  20. ^ 「TCP輻輳制御アルゴリズムのパフォーマンス分析」(PDF) . 2012年3月26日閲覧。
  21. ^ 「DD-WRT changelog」 . 2012年1月2日閲覧。
  22. ^ “Hyblaホームページ”. 2007年10月11日時点のオリジナルよりアーカイブ。2007年3月4日閲覧。
  23. ^ 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.
  24. ^ Caini, C.; Firrincieli, R.; Lacamera, D. (2009). 「衛星環境におけるTCPバリアントの比較性能評価」. 2009 IEEE International Conference on Communications . pp.  1– 5. doi :10.1109/ICC.2009.5198834. S2CID  8352762.
  25. ^ V., Jacobson; RT, Braden. 長時間遅延パスのためのTCP拡張. doi : 10.17487/RFC1072 . RFC 1072.
  26. ^ 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.
  27. ^ Mathis, M.; Dukkipati, N.; Cheng, Y. (2013). TCPの比例レート削減. doi : 10.17487/RFC6937 . RFC 6937.
  28. ^ Corbet, Jonathan (2011年9月13日). 「LPC: ネットの高速化」 . 2014年6月6日閲覧。
  29. ^ 「Linux 3.2 – Linux Kernel Newbies」 . 2014年6月6日閲覧。
  30. ^ ab 「BBR: 輻輳ベースの輻輳制御」 。 2017年8月25日閲覧。
  31. ^ Cheng, Yuchung; Cardwell, Neal; Yeganeh, Soheil Hassas; Jacobson, Van (2017年7月3日). 「Delivery Rate Estimation」. Internet Engineering Task Force . 2017年8月25日閲覧。 {{cite journal}}:ジャーナルを引用するには|journal=（ヘルプ）が必要です
  32. ^ 「TCP BBR輻輳制御がGCPに登場 – インターネットがさらに高速化」 。 2017年8月25日閲覧。
  33. ^ Corbet, Jonathan (2016年9月21日). 「BBR輻輳制御 [LWN.net]」. lwn.net .
  34. ^ 「BBRアップデート」。インターネットエンジニアリングタスクフォース。
  35. ^ 「TCPとBBR」（PDF） . 2018年5月27日閲覧。
  36. ^ 「BBR輻輳制御の実験的評価」(PDF) 。 2018年5月27日時点のオリジナル(PDF)からアーカイブ。2018年5月27日閲覧。
  37. ^ 「TCP BBRv2のパフォーマンス評価」 。 2021年1月12日閲覧。
  38. ^ ab Google TCP BBRチーム; Google QUIC BBRチーム（2023年7月26日）。BBRv3：アルゴリズムのバグ修正とパブリックインターネットへの展開。IETF 117：サンフランシスコ。
  39. ^ 「Cellular Controlled Delay TCP (C2TCP)」. wp.nyu.edu . 2019年4月27日閲覧。
  40. ^ 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 .
  41. ^ Abbasloo、Soheil (2019 年 6 月 3 日)、GitHub – Soheil-ab/natcp 、 2019 年8 月 5 日取得
  42. ^ 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.
  43. ^ ab "Rice Networks Group".
  44. ^ 「TCP Veno: 無線アクセスネットワーク経由の伝送におけるTCPの強化」(PDF)。IEEE Journal on Selected Areas in Communication。
  45. ^ 「XCP @ ISI」。
  46. ^ 「高速TPC」（PDF） . csc.lsu.edu .
  47. ^ “TCP-Fit”. 2011年4月3日時点のオリジナルよりアーカイブ。2011年3月5日閲覧。
  48. ^ Benaboud, H.; Berqia, A.; Mikou, N. (2002). 「TCPプロトコルにおけるCANITアルゴリズムの解析的研究」ACM SIGMETRICSパフォーマンス評価レビュー30 ( 3): 20. doi :10.1145/605521.605530. S2CID  6637174.
  49. ^ Rouhani, Modjtaba (2010). 「TCP/IPネットワークにおける遺伝的アルゴリズムに基づく非線形ニューラルネットワーク輻輳制御」. 2010年第2回計算知能、通信システム、ネットワークに関する国際会議. pp.  1– 6. doi :10.1109/CICSyN.2010.21. ISBN 978-1-4244-7837-8. S2CID  15126416。
  50. ^ 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。
  51. ^ 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.
  52. ^ Arun, Venkat; Balakrishnan, Hari (2018). 「Copa: インターネットのための実用的な遅延ベース輻輳制御」.第15回USENIXネットワークシステム設計・実装シンポジウム (NSDI 18) : 329– 342. ISBN 978-1-939133-01-4。
  53. ^ 「tcp: CUBICをデフォルトの輻輳制御メカニズムにする」。2022年9月13日。
  54. ^ 「5つの新しいTCP輻輳制御アルゴリズムプロジェクトの概要」2011年3月8日。
  55. ^ 「iTCP – インタラクティブ トランスポート プロトコル – メディアネット ラボ、ケント州立大学」。
  56. ^ 「ホワイトペーパー：Zeta-TCP – インテリジェントで適応型の非対称TCPアクセラレーション」（PDF） . 2019年12月6日閲覧。
  57. ^ Lefteris Mamatas、Tobias Harks、Vassilis Tsaoussidis (2007年1月). 「パケットネットワークにおける輻輳制御へのアプローチ」(PDF) . Journal of Internet Engineering . 1 (1). 2014年2月21日時点のオリジナル(PDF)からのアーカイブ。
  58. ^ 「高速TCP」. icir.org .
  59. ^ 「AIMD-FCホームページ」neu.edu . 2009年1月13日時点のオリジナルよりアーカイブ。2016年3月13日閲覧。
  60. ^ 「ネットワークリサーチラボへようこそ」. cs.ucla.edu .
  61. ^ 「ユニキャストアプリケーションのための方程式ベースの輻輳制御」icir.org。
  62. ^ Katabi, Dina; Handley, Mark; Rohrs, Charlie (2002). 「高帯域幅遅延積ネットワークにおける輻輳制御」. 2002年コンピュータ通信のアプリケーション、テクノロジー、アーキテクチャ、プロトコルに関する会議議事録. ニューヨーク州ニューヨーク: ACM Press. p. 89. doi : 10.1145/633025.633035 . ISBN 1-58113-570-X。
  63. ^ 「MaxNet -- Max-Min Fair、安定した明示的シグナリング輻輳制御」。netlab.caltech.edu。
  64. ^ 「TCP輻輳制御：システムアプローチ。Peterson、Brakmo、Davie」 。 2024年5月17日閲覧。
  65. ^ Bunny.net Academy. (nd).輻輳制御とは何か、そしてLinux TCPではどのように機能するのか？ 2025年5月2日取得、[1](https://bunny.net/academy/network/what-are-congestion-controls-and-how-do-they-work-in-linux-tcp/#:~:text=TCP's%20congestion%20control%20is%20used,and%20congestion%20window%20(CWND))

出典

  • 黒瀬, ジェームズ; ロス, キース (2008). 『コンピュータネットワーキング：トップダウンアプローチ』（第4版）. アディソン・ウェスリー. 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輻輳制御. Internet Engineering Task Force . sec. 3.2. doi : 10.17487/RFC2581 . RFC 2581. 2010年5月1日閲覧.
  • TCP輻輳処理と輻輳回避アルゴリズム – TCP/IPガイド
Retrieved from "https://en.wikipedia.org/w/index.php?title=TCP_congestion_control&oldid=1322880764"