7

キャプチャされたTCPセッションで使用されるTCP輻輳制御アルゴリズムを決定するためのプログラムが欲しいのですが。

参照されているウィキペディアの記事には次のように記載されています。

TCP New Renoは最も一般的に実装されているアルゴリズムであり、SACKサポートは非​​常に一般的であり、Reno /NewRenoの拡張機能です。他のほとんどは、まだ評価が必要な競合する提案です。2.6.8以降、Linuxカーネルはデフォルトの実装をrenoからBICに切り替えました。2.6.19バージョンでは、デフォルトの実装が再びCUBICに変更されました。

また：

複合TCPは、公平性を損なうことなくLFNで良好なパフォーマンスを達成することを目的として、2つの異なる輻輳ウィンドウを同時に維持するTCPのMicrosoft実装です。これは、MicrosoftWindowsVistaおよびWindowsServer2008で広く展開されており、Linuxだけでなく古いMicrosoftWindowsバージョンにも移植されています。

どのCCアルゴリズムが使用されているかを判断するためのいくつかの戦略は何でしょうか（セッションをキャプチャするサードパーティから）？

アップデート

このプロジェクトは、これを行うためのツールを構築しました。

インターネットは最近、同種の輻輳制御から異種の輻輳制御へと進化しています。数年前、インターネットトラフィックは主に標準のTCP AIMDアルゴリズムによって制御されていましたが、インターネットトラフィックは現在、AIMD、BIC、CUBIC、CTCP、HSTCP、HTCP、HYBLA、ILLINOIS、LPなどのさまざまなTCP輻輳制御アルゴリズムによって制御されています。 STCP、VEGAS、VENO、WESTWOOD +、およびYEAH。ただし、異種輻輳制御を使用したインターネットのパフォーマンスと安定性の調査に関する作業はほとんどありません。基本的な理由の1つは、さまざまなTCPアルゴリズムの展開情報が不足していることです。このプロジェクトの目標は次のとおりです。

1) develop tools for identifying the TCP algorithms in the Internet,
2) conduct large-scale TCP-algorithm measurements in the Internet.
4

1 に答える 1

4

ここで言及したよりも多くの輻輳制御アルゴリズムがあります。リストには、FAST、Scalable、HSTCP、HTCP、Bic、Cubic、Veno、Vegas が含まれます。

また、実際の実装でのバグ修正による小さなバリエーションもあり、異なる OS での実装も互いにわずかに異なる動作をすると思います。

しかし、接続の RTT を推定する必要がある場合は、1 番目と 2 番目のパケットが汚染されている可能性があるため、3 番目と 4 番目のパケットの間にかかった時間を調べることができます。ルートに沿ったARPおよびその他の検出アルゴリズムによって。

RTT の見積もりを取得した後、途中でそれを改善しようとすることができますが、どのようにそれを行うことができるか正確にはわかりません. ただし、プログラムの完全な仕様は必要ありません。アイデアだけが必要です:-)

RTT を把握したら、パケットを RTT ビンに入れ、各ビン内の飛行中のデータ パケットの数を数えてみることができます。このようにして、推定 cwnd (ビン内のパケット数) を時間に合わせて「プロット」し、そこでパターン マッチングを試すことができます。

別の方法は、トレースをたどって、さまざまな輻輳制御アルゴリズムを頭の中で「実行」し、任意の時点での決定が、行ったであろう決定と一致するかどうかを確認することです。ある程度の寛容さと正確さの間隔が必要になります。

これは間違いなく興味深く、やりがいのある仕事のように思えます!

于 2009-04-01T13:02:19.347 に答える