問題タブ [congestion-control]

TCP Reno、HSTCP、STCP、または高速 TCP? それとも、現在人気のあるカーネルでアルゴリズムを変更できますか?

Mininet を使用して、2 つのホストと 1 つのスイッチで構成されるネットワークをエミュレートしようとしています。一方のホストは送信側であり、iperf ツールを使用してもう一方のホスト (受信側) に継続的にパケットを送信します。

H1--------------------------------スイッチ-------------------- ------H2

-------100Mbps|0.125ms-----------100Mbps|0.125ms------

ホストとスイッチ間のリンクの帯域幅は 100Mbps、遅延は 0.125ms です。

送信される各パケットのサイズは 1.5KB で、スイッチには 400 パケットのバッファがあります。

各リンクの遅延は 0.125 ミリ秒であるため、H1、H2 間の RTT は 4*0.125=0.5 ミリ秒です。

CWND (輻輳ウィンドウ) は、送信者が 1 回の RTT で送信するパケットの数であるため、スループットは次のように計算されます: スループット = CWND/RTT。

MAX(througput) < 帯域幅であるため、CWND < RTT*帯域幅=0.5*10^(-3)*100*10^6=50000b~6KB = 4 パケット

しかし、tcp_probe ツールを使用して CWND を監視すると、驚いたことに、常に 200KB (~120 パケット) を超える CWND が表示され、予想よりもはるかに大きくなります。

バッファでも 400 パケットですが、そんなに大きな CWND を持つことはできません。

私のためにそれを説明してください、私は本当にこの問題で立ち往生しています。ありがとうございました！

多くの送信者が受信者にパケットを送信する状況について話していると仮定します。
多くの場合、送信者は、送信レートを制限するスライディング ウィンドウを使用して輻輳を制御します。

我々は持っています：

ネットワーク (ルーター、スイッチ) からの明示的または暗黙的なフィードバック情報を使用して、送信者はcwnd送信レートを制御します。

通常、rwndは常に送信者のみが気にする十分な大きさですcwnd。しかし、rwndを制限するために を使用すると、snd_cwnd輻輳制御がより効率的になります。

rwnd受信者が受信できるパケット (またはバイト) の数です。私が懸念しているのは、送信者の能力です。

質問:
1. 受信側は、パケットを送信しているフローの数をどうやって知るのでしょうか?
2. 受信者が送信者の snd_cwnd を知っているということはありますか?

ホストが他のホストと結合して、1 つのホストにパケットを送信するとします。すべてのホストは、ECN マーキングをサポートするスイッチに接続します。

参加するのがネットワークの輻輳時であり、スイッチがすべての受信パケットをマークする場合。

ただし、このホストはスロー スタート フェーズでのみ開始され、最初のパケットを送信すると、ECN マークが付けられます。

では、このホストはまだスロー スタート中ですか、それとも輻輳回避フェーズに移行していますか?

以下の tcpdump ログは、私が最近実行したテストからコピーされたものです。最初はすべてが非常にスムーズに進みました。その後、クライアント側が最終的にルーターを圧倒し、多くのパケット [# - 6176] がドロップされます (それらの ACK は表示されません)。次いで、６１７７で、ｒｔｏタイマーがタイムアウトしたために再送信がトリガーされる。

だからここに質問があります：

1. 再送があった場合、送信側輻輳ウィンドウ(snd_cwnd)はどうなりますか? OS は Linux カーネル 3.4.42 です。言われているように、再送信があると snd_cwnd は 1 に減ります。この場合、パケット 6179、6180 を送信できるのはなぜですか?
2. 6179、6180 が ACK を取得しなかったのはなぜですか? 代わりに、6178 は ACK を取得できます。つまり、パケットが通過できることを意味します。

現在TCPで輻輳回避技術として使われているAdditive Increase Multiplicative Decrease法を研究しています。帯域幅 R の共通リンクを共有する K 個の TCP セッションがある場合、この手法はすべてのセッションの公平性を保証すると言われています。つまり、各セッションのスループットは R/K になります。

ここで、この公平性を数学的に証明したいと思います (各セッションのスループットの初期値に関係なく、最終的にはすべて R/K になるという結論に達します)。

ありがとう ！

AIMD Additive Increase Multiplicative Decrease CA アルゴリズムは、損失が検出されると輻輳ウィンドウのサイズを半分にします。しかし、「直感」以外に、2 で割ることが (たとえば別の数値ではなく)最も効率的な方法であることを示唆する実験的/統計的または理論的な証拠はありますか? これを裏付ける、またはこの主張を調査している出版物または雑誌の論文を教えてもらえますか?

私が理解しようとしている質問は次のとおりです。

この問題では、TCP スロースタート フェーズによって導入される遅延を考慮します。クライアントと Web サーバーがレート R の 1 つのリンクで直接接続されているとします。クライアントが、サイズが 15S に正確に等しいオブジェクトを取得したいとします。ここで、S は最大セグメント サイズ (MSS) です。クライアントとサーバー間のラウンドトリップ時間を RTT (一定であると仮定) で表します。プロトコル ヘッダーを無視して、オブジェクトを取得する時間を決定します (TCP 接続の確立を含む)。

1. 4S/R > S/R + RTT > 2S/R
2. 8S/R > S/R + RTT > 4S/R
3. S/R > RTT

私はすでに解決策を持っています（教科書の問題です）が、どうやって答えにたどり着いたのかわかりません。

1. RTT + RTT + S/R + RTT + S/R + RTT + 12S/R = 4 · RTT + 14 · S/R
2. RTT+RTT+S/R+RTT+S/R+RTT+S/R+RTT+8S/R=5・RTT+11・S/R
3. RTT + RTT + S/R + RTT + 14S/R = 3 · RTT + 15 · S/R

そして、ここに答えと一緒に行くイメージがあります:

私にとってどのような意味がありますか: 各シナリオは、RTT 時間が一定量のセグメントを送信するのにかかる時間よりも多いまたは少ないシナリオです。したがって、最初の場合、RTT ごとに 3S/R から S/R 秒かかります。そこから、スロースタートがどのように動作しているのかわかりません。確認応答されたすべてのパケットのウィンドウ サイズが大きくなるだけだと思いました。しかし、たとえば #1 の解決策では、2 つのパケットのみが送信されて ACK が返されたように見えますが、ウィンドウ サイズは 12S に跳ね上がりますか? ここで何が欠けていますか？