問題タブ [congestion-control]

RFC 3286 に記載されているとおり:

「...エンドポイントは、TSN がバイト単位ではなくチャンク単位であるため、送受信されるバイトと送受信される TSN 間の変換を管理する必要があります」。

これは輻輳制御アルゴリズムにどのように影響しますか?

キャプチャされた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アルゴリズムの展開情報が不足していることです。このプロジェクトの目標は次のとおりです。

UDP について話しているときに、輻輳が数回発生するのを見たり聞いたりしました。どういう意味ですか？

Netkit を使用してさまざまな TCP アルゴリズムで遊んでいます。

c1とc2の2 台のマシンが、強制的に 200 ミリ秒の遅延を持つルーターによって接続されています。c1上のプログラムは、1ms ごとに 100 バイトのパケットをc2に送信しています(TCP_NODELAY がオンになっています)。Reno は両方のマシンで輻輳制御として使用されます。

tcpdump によると、最初の 2 つのパケットのみがすぐに送信され (200 バイト)、c1は送信を停止して ACK を待ちます。受信者のウィンドウは約 2MSS (MSS=1460) であるため、 c1がさらにパケットを送信するのを防ぐのは CWND だと思います。

Reno の仕様によると、最初の CWND は 1MSS です。私はそこに何かが欠けていますか?.. 1バイトのパケットを送信しても同じ画像が得られ、2つのパケットが送信され、送信者はACKを待ちます。初期の CWND サイズは、MSS ではなく、初期のセグメント サイズによって決定されるのでしょうか?

ip route show cacheのようなものを示しています

cache mtu 1500 rtt 361ms rttvar 360ms cwnd 5 advmss 1460 hoplimit 64

CWND=5MSSということなのかな？

現在、Linux のコマンド「sysctl」は、システム全体の輻輳制御アルゴリズムをグローバルに変更します。ただし、TCP ウィンドウ サイズやその他の同様のパラメータが変化する輻輳制御は、通常、TCP 接続ごとに行われます。だから私の質問は：

• TCP 接続ごとに使用されている輻輳制御アルゴリズムを変更する方法はありますか?

それとも、ここで些細なことを見逃していますか？もしそうなら、それは何ですか？

調べているトレースに少し問題があります。ウィンドウ サイズが各セグメント間で送信される ACK の量とともに増加している場合、接続がスロー スタートであり、ACk されたセグメントのサイズだけ増加することがわかっています。ただし、トレースの最初に、加算されない数値が表示されます (下のスクリーンショット)。私が知らないのは、計算が前のウィンドウ サイズと ACK の間に加算されないため、パケット 6 のウィンドウ サイズがどのように計算されたかです。誰でもこれに光を当てることができますか？

また、スロースタートが渋滞回避になるタイミングを見極める方法もわかりません。トレースで注意できることはありますか?

スロー スタートはパケット 13 までしか発生しないように見えるので、輻輳回避が引き継がれたと想定する必要がありますか?

http://img10.imageshack.us/f/tcptrace.jpg/

助けてくれてありがとう！ほんとうにありがとう

そこで、次のスクリプトを作成しました。

そして、それはほとんどの場合うまく機能します。ただし、ランダムな場合に、(アップロードされている画像のリストのランダムなポイントで) 「接続が強制的に閉じられました: 開いたままになると予想されていた接続がサーバーによって閉じられました」というエラーが発生します。これはある種の輻輳の問題であると考えており、Google でこの問題に対する多くの解決策を見つけることができませんでした。そのため、画像ファイルをアップロードするときにクライアント側からサーバーの輻輳を軽減する方法を誰かが知っているかどうか、または画像をアップロードするより効率的な方法があるかどうか、または SharePoint サイトから毎回ログアウトするような解決策があるかどうか疑問に思っていました15 枚の画像の場合、再度ログインすると機能しますか? 助けてくれてありがとう！

NewRenoの代わりにLEDBATを輻輳制御として使用するMacOSX [1]用の代替のオープンソースTCP実装を見つけました。

• 私はそのOSにあまり詳しくないので、そのソースファイルをビルドしてシステムにロードする方法を教えてください。

（たとえば、Linuxのように、簡単に構築してカーネルにモジュールとしてプラグインし、ランタイムをロードできる実装[2]があるかどうか、疑問に思っていました。

）。

[1] http://opensource.apple.com/source/xnu/xnu-1699.22.81/bsd/netinet/tcp_ledbat.c

[2] http://perso.telecom-paristech.fr/~valenti/pmwiki/pmwiki.php?n=Main.LEDBAT#howtokernel

ありがとうございました

Mint/Debian ボックスで CouchDB をかなり簡単にセットアップしました。私の Java Web アプリケーションは、CouchDB へのクエリでかなり長い遅延に悩まされていたので、その原因を探し始めました。

EDIT : クエリ パターンは、多数の小さなクエリと小さな JSON オブジェクト (上 300 バイト/下 1K バイトなど) です。

Wireshark のダンプは非常に優れており、ほとんどが 3 ～ 5 ミリ秒の要求と応答のターンアラウンドを示しています。JVM フレーム サンプリングでは、ソケット コード (Couch へのクライアント側のクエリ) が多少ビジーであることがわかりましたが、特に目立ったものはありませんでした。次に、ApacheBench と oops で同じことをプロファイリングしようとしました。現在、キープアライブは、非永続的なセットアップで安定した余分な 39 ミリ秒の遅延を導入していることがわかります。

誰もこれを説明する方法を知っていますか? 永続的な接続が TCP 層の輻輳ウィンドウを増加させ、TCP_WAIT や小さな要求/応答サイズなどのためにアイドル状態になっている可能性がありますか? このオプション (TCP_WAIT) は、ループバック tcp 接続に対してオンにする必要がありますか?

キープアライブで実行、リクエストあたり平均 40 ミリ秒

キープアライブはなく、出来上がり - ほとんどの場合、リクエストごとに 1 ミリ秒。

さて、キープアライブをオンにしましたが、http ヘッダーを介して接続を閉じるように求めています。また、リクエストごとに1ミリ秒程度です。

Alice と Bob の 2 つのピアが IP ネットワークを介して接続されているとします。Alice と Bob は、生成されてリアルタイムで消費される非可逆圧縮データのパケットを交換しています (VoIP またはビデオ チャット アプリケーションを考えてください)。このサービスは、利用可能なわずかな帯域幅に対処するように設計されていますが、低レイテンシーに依存しています。Alice と Bob は、適切な QoS プロファイルで接続をマークします。

Alice と Bob は、可変ビットレート圧縮を使用したいと考えており、それらの間の接続に使用できる残りの帯域幅をすべて消費したいと考えていますが、ネットワークの状態に応じて、消費されるビットレートを自発的に削減します。しかし、彼らは安定したリンクを維持したいと考えています。つまり、帯域幅が調整されるまでの輻輳と遅延によって引き起こされるデコードされたデータ ストリームの中断を回避したいと考えています。ただし、いくつかのパケットを失う可能性は十分にあります。

TL;DR: Alice と Bob は VoIP プロトコルをゼロから実装したいと考えており、帯域幅と輻輳制御に興味があります。

Alice と Bob が読むように提案する論文とリソースは何ですか? 主に帯域幅推定と輻輳制御の分野で。