低遅延10GbE-> 1GbEネットワークのTCP輻輳制御？

スイッチへの10GbE接続を備えたサーバーと、それぞれ同じスイッチへの1GbE接続を備えた10個のクライアントがあります。

各クライアントでnuttcpを並行して実行すると、10のTCPストリームのデータをワイヤスピードに近い速度で同時にサーバーにプッシュできます（つまり、10のクライアントすべてからわずか100メガバイト/秒）。

ただし、方向を逆にしてサーバーからクライアントにデータを送信すると（つまり、各クライアントに1つのTCPストリームが10回）、TCP再送信が急増し、パフォーマンスが1秒あたり30、20、または10メガバイトにまで低下しますクライアントごと。このトラフィックパターンは、私が関心を持っている特定のアプリケーションの代表であるため、これらの数値を上げたいと思います。

同様のサーバーへの10GbE接続で同じ実験を実行することにより、サーバーが10GbEリンクを飽和できることを確認しました。ポートにエラーがないことを確認しました。

最後に、受信者のTCPウィンドウサイズを強制的にクランプ（制限）すると、帯域幅を多少高くすることができます（30〜40メガバイト/秒）。そして、非常に低くクランプすると、再送信をゼロにできます（帯域幅はばかげて低くなります）。

したがって、スイッチのバッファをオーバーランさせており、輻輳によるパケット損失が発生していると確信しています。ただし、TCPの輻輳制御はこれをうまく処理し、最終的にワイヤ速度の50％を超える値で安定するはずであると考えました。

したがって、私の最初の質問は非常に単純です：どのTCP輻輳制御アルゴリズムが私の状況に最適でしょうか？たくさんありますが、ほとんどは損失の多いネットワーク、高帯域幅、高遅延のネットワーク、またはワイヤレスネットワークをターゲットにしているようです。いずれも私の状況には当てはまりません。

2番目の質問：他に試すことができるものはありますか？

1. パケットがドロップしてもウィンドウサイズが大幅に縮小されないアルゴリズムが必要になります。ウィンドウサイズの急激な低下が原因で、TCPトラフィックのスループットが突然低下します。

2. スイッチとサーバーがフロー制御をサポートしている場合は、フロー制御を有効にしてみてください。これがどれだけうまく機能するかは、ほぼ完全にスイッチのシリコンとファームウェアに依存します。基本的に、スイッチはクライアントに接続されているポートの出力輻輳を検出し、パケットの送信元を判別し、入力ポートからフロー制御フレームを送信します（つまり、サーバーに戻します）。サーバーがフロー制御フレームを理解している場合、送信速度が低下します。すべてがうまく機能すれば、スイッチの出力バッファで発生するパケットドロップが実質的にゼロになり、最適なスループットが得られます。