高帯域幅接続用に（非常に）大きなinitcwndを設定することの欠点は何ですか？

Linux（3.5カーネル）でTCPパラメータを実験しています。基本的にこの接続に関して：

サーバー：データセンター内のギガビットアップリンク。別のデータセンターからテストした場合、実際の帯域幅（アップリンクの共有による）は約70 MB /秒です。

クライアント：200メガビットファイバーに接続されたギガビットローカルLAN。テストファイルを取得すると、実際には20 MB /秒に達します。

待ち時間：約50ミリ秒の往復。

リモートサーバーは、10〜100 MBの範囲のファイルのファイルサーバーとして使用されます。10のinitcwndを使用すると、これらのファイルの転送時間はTCPスロースタートの影響を大きく受け、10秒の読み込みに3.5秒かかります（最高速度：3.3 MB /秒に達します）。最高速度に達する前に終了します。私の目標は、これらのファイルの最小読み込み時間を調整することです（したがって、生のスループットが最高でも往復遅延が最低でもないので、ファイルを読み込むのにかかる実際の時間を短縮する場合は、両方を犠牲にしてもかまいません）。

そのため、他の接続や他への影響の可能性を無視して、理想的なinitcwndがどうあるべきかを決定するために簡単な計算を試みました。帯域幅遅延積は、200メガビット/秒* 50ミリ秒= 10メガビットまたは1.310.720バイトです。initcwndがMSSの単位で設定されていることを考慮し、MSSが約1400バイトであると仮定すると、1.310.720 / 1400 = 936の設定が必要になります。

この値はデフォルト（Linuxでは10 * MSS、Windowsでは64kb）とは非常に異なるため、このように設定することはお勧めできません。このように構成することの予想される欠点は何ですか？例えば：

• 同じネットワークの他のユーザーに影響しますか？
• 他の接続で許容できない輻輳が発生する可能性はありますか？
• パス上のどこかにルーターバッファーをフラッドしますか？
• 少量のパケット損失の影響を増やしますか？

このように構成することの予想される欠点は何ですか？例えば：

Will it affect other users of the same network?

initcwndを変更すると、以下に影響します。

• 設定が変更されたサーバーのユーザー
• それらのユーザーがルートと一致する場合、設定の変更が構成されます。

Could it create unacceptable congestion for other connections?

承知しました。

Flood router-buffers somewhere on the path?

無関係ではありませんが、ルーターでない限り、私はあなたにより近い問題に焦点を当てます。

Increase the impact of small amounts of packet-loss?

もちろん、これは可能です。

その結果、意図的であっても意図的でなくても、これによりパケット損失のコストが増加します。サーバーは、3ウェイハンドシェイク（かなりの量のデータを低投資（データ量）で投入）を実行できる人なら、DOSに比べてシンプルです。

また、バースト内の最初のパケットの1つが失われるため、これらのパケットの束を再送信する必要がある可能性も高くなります。

私はあなたが何を求めているのか完全には理解していないと思うので、ここに応答の試みがあります：

まず第一に、あなたがしようとしていることは、受信側ではなく送信側でのみ意味があります。つまり、受信側ではなくファイルサーバーを変更する必要があります。それがあなたがやっていることだと仮定します：

initcwndを（たとえば）10に変更すると、10個のパケットがすぐになくなります。それらすべてがターゲットに到達すると、スロースタート（指数cwndの増加）のために、最初のRTTではるかに大きなウィンドウになる可能性があります。ただし、パケットが失われると、cwndは半分になり、10パケットでバーストしているため、かなりの量の再送信が発生し、思ったよりも多くの問題が発生する可能性があります。

サーバー側で輻輳制御アルゴリズムを変更するよりも、より攻撃的なことを試みて、他のインターネットユーザーに対して何らかの方法で「失礼」にしたい場合は、異なるアルゴリズムはcwndを異なる方法で処理します。サーバー側のソフトウェアが接続ごとに変更しない限り、これはすべてのユーザーに影響することに注意してください（これは非常に疑わしいです）。ここでの利点は、initcwndがあまり役割を果たさない場合でも、パケット損失の後でもアルゴリズムが有効になることです。

/ proc / sys / net / ipv4 / tcp_congestion_controlは、輻輳制御アルゴリズムを変更する場所です。

そのような小さなRTT（50ms）のFWIWと中または大規模ファイルの場合、initcwndは平均速度にあまり影響を与えません。パケット損失がない場合（つまり、太いパイプ）、cwndはすべてのRTTで2倍になります。太いパイプでRTT = 50msを使用すると、最初の1秒間に20のRTTに適合します。つまり、initcwnd = 2を使用すると、1秒後にcwnd = 2 * 2 ^ 20になります。扱う ;-）