問題タブ [congestion-control]

iperf3別のサーバー上の複数の送信者を使用して簡単な実験を実行し、TCP別のサーバー上の単一の受信者にトラフィックを送信しています。

iperf3Cwndは、この実験中に 0.1 秒ごとに輻輳ウィンドウ ( ) を報告します (キロバイト単位)。また、実験中のカーネル モジュールからの出力もログに記録しますtcp_probe。これは、(セグメントで) 変更されるたびに輻輳ウィンドウを示します。輻輳ウィンドウに 1500 (MTU サイズ)を掛けて、tcp_probe-reported輻輳ウィンドウをバイト単位で取得します。輻輳ウィンドウが一致すると予想していましたが、iperf3 によって報告された輻輳ウィンドウのサイズは、tcp_probe. この乗法係数によって修正されると、それらは完全に一致します。なぜこれが起こるのですか？どちらが正しいですか？

私が実行するコマンドは次のとおりです。

iperf3とtcp_probeの両方のソース コードを調べてみましたが、怪しいものは何もありませんでした。

「コンピュータ ネットワーキング: トップダウン アプローチ」という本を読んでいて、よくわからない質問に出くわしました。

私が読んだように、TCP Congestion Control には 3 つの状態があります。Slow Start、Congestion Avoidance、Fast Recovery です。Slow Start と Congestion Avoidance はよくわかりますが、Fast Recovery はかなりあいまいです。この本は、TCP がこのように動作すると主張しています: (cwnd= Congestion Window)
次のグラフを見てみましょう:

ご覧のとおり、ラウンド 16 で送信者は 42 セグメントを送信し、輻輳ウィンドウ サイズが半分 (+3) になったため、3 つの重複 ACK があったと推測できます。この質問に対する回答では、 ラウンド 16 から 22 までが輻輳回避状態にあると主張しています。しかし、高速リカバリではないのはなぜですか? つまり、3 つの重複 ACK の後、TCP は高速回復に入り、それ以降はすべての重複 ACK が輻輳ウィンドウを増加させるはずです。グラフにそれが表現されていないのはなぜですか？私が考えることができる唯一の合理的な説明は、このグラフでは 3 つの重複 ACK しかなく、それ以降に受信された ACK は重複ではなかったということです。

その場合でも、3 つ以上の重複した ACK があった場合、グラフはどのように見えるでしょうか? **

上のグラフに高速回復を表すものはありますか? そうじゃない/はい？

** 私は長い間、その質問に答えるのに苦労してきました。返信をいただければ幸いです。ありがとうございます。

更新ここに画像があります。ラウンドは、ウィンドウ内のすべてのセグメントが ACK されているときとして定義されていると思います。写真では、ラウンドは丸で示されています。 Fast Recovery 状態のときに cwnd が指数関数的に増加するのはなぜですか? （画像では、指数関数的ではなく便宜的に誤って書きました）

iperf10Gbit リンクを介して接続された 2 つのサーバー間で測定を実行しています。観察した最大ウィンドウ サイズをシステム構成パラメーターと関連付けようとしています。

特に、最大ウィンドウ サイズが 3 MiB であることを確認しました。ただし、システム ファイルに対応する値が見つかりません。

実行するsysctl -aと、次の値が得られます。

最初の値は、最大受信ウィンドウ サイズが 6 MiB であることを示しています。ただし、TCP は要求されたサイズの 2 倍を割り当てる傾向があるため、受信ウィンドウの最大サイズは、私が測定したとおり 3 MiB である必要があります。からman tcp:

TCP は、setsockopt(2) 呼び出しで要求されたバッファーのサイズの 2 倍を実際に割り当てるため、後続の getsockopt(2) 呼び出しは、setsockopt(2) 呼び出しで要求されたのと同じサイズのバッファーを返さないことに注意してください。TCP は管理目的と内部カーネル構造のために余分なスペースを使用し、/proc ファイルの値は実際の TCP ウィンドウと比較してより大きなサイズを反映しています。

ただし、2 番目の値 はnet.core.rmem_max、最大レシーバー ウィンドウ サイズが 208 KiB を超えることはできないことを示しています。によると、これはハードリミットであると想定されていますman tcp。

tcp_rmem max: 各 TCP ソケットが使用する受信バッファの最大サイズ。この値はglobalをオーバーライドしませんnet.core.rmem_max。これは、ソケットで SO_RCVBUF を使用して宣言された受信バッファーのサイズを制限するためには使用されません。

で指定されたものよりも大きな最大ウィンドウ サイズが表示されるのはnet.core.rmem_maxなぜですか?

注意: 帯域幅と遅延の積も計算しました。window_size = Bandwidth x RTTこれは約 3 MiB (10 Gbps @ 2 ミリ秒 RTT) であり、トラフィック キャプチャを検証しています。

Centos 7 で tcp 輻輳制御を変更しようとしています。

私はどのアルゴリズムをチェックしました：

htcp に変更したいのですが、利用可能かどうかを確認すると、次のようになります。

そのため、まず CUBIC も HTCP も見当たりませんでした。HTCP 輻輳制御を有効にする方法を教えてください。

輻輳制御はネットワーク現象であり、トランスポート層でこれが処理される理由と方法。ネットワーク内の中継装置（ルーター）間で輻輳が発生します。しかし、昨日私は論文を読んでいました (TCP のホスト間輻輳制御、Alexander Afanasyev、Neil Tilley、Peter Reiher、および Leonard Kleinrock) 。ここで、タイトルを見ることができるように、ホスト間輻輳制御. さらにお聞きしたいのですが、ネットワークに輻輳が発生した場合、それを制御するのはネットワーク層の役割ですが、トランスポート層が制御していることがわかります。? どうやって ？トランスポート層は、ネットワーク間で輻輳が発生したことをどのように認識しますか。?

MPTCPには、「Coupled」などの独自の輻輳制御があることを知っています。ただし、MPTCP は TCP 層にあります。TCPにはすでにオリジナルのものがあります。これらは重複して一緒に機能しますか、それとも MPTCP だけが独立して機能しますか?

together の場合、HTTP/2 の場合と同様に HOL-Blocking の問題が発生するようです。