問題タブ [congestion-control]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
1 に答える
2096 参照

linux - C++ コードから setsockopt() 呼び出しを使用して TCP 輻輳制御アルゴリズムを変更する方法

LinuxでC++コードからsetsockopt呼び出しを使用して、 TCP輻輳制御アルゴリズムを変更CubicRenoたり、その逆に変更したりすることは可能ですか? そうするサンプルコードを探しています。

0 投票する
1 に答える
305 参照

networking - 高速リカバリ中に TCP 輻輳ウィンドウが膨張するのはなぜですか?

TCP高速回復アルゴリズムは次のように記述されています(TCP図解vol.1より)。ステップ 1 で理解できないのは、CWD ウィンドウがセグメント サイズの 3 倍になるのはなぜですか?

  1. 3 番目の重複 ACK を受信したら、ssthresh を現在の輻輳ウィンドウ cwnd の半分に設定します。欠落しているセグメントを再送信します。 cwnd を ssthresh にセグメント サイズの 3 倍を加えた値に設定します。
  2. 別の複製 ACK が到着するたびに、cwnd をセグメント サイズだけインクリメントし、パケットを送信します (cwnd の新しい値で許可されている場合)。
  3. 新しいデータを確認する次の ACK が到着したら、cwnd を ssthresh に設定します。これは、ステップ 1 からの再送信の ACK である必要があります。再送信の 1 ラウンドトリップ時間後です。さらに、この ACK は、失われたパケットと最初の重複 ACK の受信との間に送信されたすべての中間セグメントを確認する必要があります。このステップは、パケットが失われたときの速度の半分に減速しているため、輻輳の回避です。
0 投票する
0 に答える
49 参照

congestion-control - BBRの2つの状態「レートバランス」と「フルパイプ」の読み方

以下は BBR の論文からのコピーです: https://queue.acm.org/detail.cfm?id=3022184

「レートバランス条件だけでは、キューが存在しないことを保証するものではなく、サイズを変更できないだけです (たとえば、接続が 10 パケットの初期ウィンドウを 5 パケットの BDP に送信することによって開始された場合、正確にボトルネックで実行されます)。そのため、超過分はボトルネックに消散できないスタンディング キューを形成します. 同様に、フル パイプ状態は、キューがないことを保証しません (たとえば、BDP/ で BDP を送信する接続)。 2 バーストでボトルネック使用率が最大になりますが、平均キューは BDP/4 です。」

私を混乱させたいくつかの点があります:

1、「レート バランス条件は、パケット到着レートが BtlBw に等しいことを意味します」:では、レート バランスだけではなく、フル パイプではキューがないことを保証できないのはなぜですか? どのようにレートバランスが完全なパイプよりも大きいバイトのみを生成するのですか?

2、「サイズが変えられないだけ」:「サイズ」ってどういう意味?</p>

3、BDP/4 がキューに入れられているのはなぜですか?