問題タブ [congestion-control]

私はネットワーク試験のために修正していますが、次の答えがわかりません:

すべての ACK の後、最大セグメント サイズは 1 ずつ増えますか、それとも 2 倍になりますか? 倍増した場合、2KB^5 = 32KB であるため、答えは 50ms で、5 回のトリップの後、MSS は 32KB になり、10ms のラウンドトリップ時間により、10x5 = 50ms になりますか?

TCP スロー スタートは、インターネットが「輻輳の崩壊」を経験し始めたときに発生しました。Van Jacobson と Michael Karels の論文からの逸話的な例は次のとおりです。

輻輳の問題は、高速リンクから低速リンクへの移行と、このボトルネックでのバッファでのパケットのビルドアップ/ドロップによって引き起こされると説明されることがよくあります。
私が理解しようとしているのは、完全なバッファーにつながるリンクの高速部分で余分なアクティビティ/再送信を単に引き起こすのではなく、そのような蓄積がエンドツーエンドのスループットの低下を引き起こす方法です。例として、次のネットワークを考えてみましょう。

A と D はエンドポイント、B と C は高速ネットワークから低速ネットワークへの移行時のパケット バッファです。たとえば、A/B と C/D 間のリンクは 10Mbps で、B/C 間のリンクは 56Kbps です。ここで、A が大きな（理論的には無限としましょう）Dへのメッセージ、私が理解しようとしているのは、接続の途中で低速のリンク速度に適応するのではなく、TCP接続をデータで叩いた場合、通過するのに時間がかかる理由です. 私は、B は、A によってバッファがどれだけ大量に叩かれているかに関係なく、またバッファがいっぱいになったために破棄しなければならないパケットの数に関係なく、56Kbps の固定レートでバッファが消耗するものであると想定しています。したがって、A が常に B のバッファーをフル (場合によってはオーバーフル) に保ち、B が常に最大レートの 56Kbps で送信している場合、代わりにスロースタートを使用することで、スループットはどのように向上しますか?

私が考えられる唯一のことは、D が既に受信した同じパケットが、輻輳の下で低速の B/C リンクを介して再送信される必要があり、これが新しいパケットをブロックしているということでした。しかし、D は通常、受信したすべてのパケットに ACK を送信していないので、再送信されるパケットのほとんどは、B のバッファーでドロップされたために D によって正当に受信されなかったものである必要があります。

TCP 接続の現在の TCP 輻輳ウィンドウを取得するコマンドまたはスクリプトはありますか。したがって、ネットワーク インターフェイス (例: eth0) を介して tcp で何らかの通信が行われているとします。tcp の輻輳ウィンドウを動的に (定期的に) 取得する方法はありますか? (Linux プラットフォームで)

LAN 経由でセンサー データを提供する Linux を実行している組み込みデバイスがありますが、WAN は提供しません。場合によっては、 http://en.wikipedia.org/wiki/Long_fat_networkの一端に存在することがあります。

私が継承したアーキテクチャは TCP を使用していますが、UDP を介したリアルタイム ビデオに相当するものを追加したいと考えています。ドロップされたパケットや順序は気にしません。ドロップしたときはクライアント側で知りたいだけで、送信が速すぎる場合はサーバー側で知りたいだけです。再放送は絶対にしたくない。

他に見るべき場所はありますか？私の最初のベンチマークでは、UDT は現在遅すぎます。シーケンス番号を持つ単純な UDP クライアント/サーバーは、この組み込みシステムで最大 80 Mbit/s を維持できますが、調整されていない UDT は約 30 Mbit/s で実行されます。その SOCK_DGRAM インターフェイスを使用すると、UDT は、通常 16 Mbit/s で実行されるポイントまで積極的にフォールバックするように見えます。この種のアプリケーション用に UDT の CCC の調整に成功した人はいますか? 私が見た最高のスループットは、UDT のサンプル アプリケーションで 35 Mbit/s です。

RTPにスキップする必要がありますか? http://en.wikipedia.org/wiki/Real-time_Transport_Protocol

TCP 輻輳回避メカニズムを理解しようとしていますが、理解できないことが 1 つあります。TCP 輻輳回避はフローごとですか、それともリンクごとですか?

言い換えると、2 つのルーター A と B があり、A が B に 2 つの TCP フローを送信しています。一方の TCP フローが輻輳を検出すると、もう一方のフローのウィンドウ サイズも減少しますか?

もちろん、これが発生した場合、他のフローはしばらくして輻輳を検出しますが、2 番目のフローは独自に輻輳を検出するまで「待機」しますか? それはかなり効果がないでしょう...

どうもありがとう

株式市場のテクニカル分析の分野では、長方形の価格混雑レベルの概念があります。つまり、価格が上下することは、以前の高値と安値のレベルをしばらくの間破ることはなく、長方形の形を形成します。例：http ：//cf.ydcdn.net/1.0.0.25/images/invest/congestion%20area.jpg 。

編集：私にはもっと明確に：株式と外国為替市場は「インパルス」と「修正」と呼ばれる一連の動きによって作られています。最初の動きは現在の株式のトレンドの方向にあり、もう1つは反対の方向にあります。株価がトレンドの方向に動いているとき、インパルスの動きは常に次の補正よりも大きくなりますが、補正がインパルスと同じサイズになることがあります。したがって、たとえば、前向きな傾向のある株式では、衝動の動きが価格$10,00から$15,00に移動し、修正が表示された後、価格が$12,00に下がりました。新しい衝動が現れたとき、以前の高い値（$ 15,00）を渡す代わりに、それは正確にかがみ、その後、価格を以前の低い価格（$ 12,00）に正確に下げる新しい修正が続きました。したがって、株価のグラフに2本の平行な水平線を引くことができます。1本は15,00ドルの価格で、もう1本は12,00ドルで、価格が内部で「混雑」しているチャネルを形成します。そして、極端な側面に2つの垂直バーを描画すると、長方形ができます。1つは上部のバーが高レベルにあり、もう1つは低レベルにあります。

リストコンテナ内のローソク足データでそのようなパターンを検出できるアルゴリズムをC++/ Qtで作成しようとしています（Qt-> QListを使用）が、現在、誰かがすでにそのようなことをした人について知っているかどうかを調べるために調査を行っていますコードなので、そのようなアルゴリズムを開発するのに多くの労力と時間を節約できます。

だから私の最初の質問は次のようになります：誰かがそのような数字を検出できるオープンソースコードを知っていますか？-明らかに、正確にこの状態である必要はありませんが、同様のタスクを実行するコードがあり、調整を行うだけでよい場合は、それで問題ありません。

一方、とにかくそのようなアルゴリズムを作成するにはどうすればよいですか？ハイスポットは、ハイレベルとローレベルを検出することであり、これらのレベルがいつ「壊れている」かを制御して図の終わりを検出するだけではないことは明らかですが、どうすれば効率的な方法でそれを行うことができますか？今日、私ができる最善のことは、時間をパラメーターとして使用して高低レベルを検出することです（たとえば、「4つのキャンドルの最高価格」、これは非常に高価なコードを使用します。

私の研究では、TCPの輻輳制御ウィンドウサイズを手動で制御したいと思います。

テストネットワークでセグメント/ACK損失が発生したときに、ウィンドウが縮小されないように明示的に停止したいと思います。

これは可能ですか？

私はPython、Netem、Scapyを使用してこれを行う方法を検討してきました。私はWindowsとLinux（ubuntu 12）の両方にアクセスできます。

Linux には、TCP の輻輳制御アルゴリズム (cubic、new-reno、veno、vegas など) 用のロード可能なモジュールが多数あることがわかりました。しかし、私を混乱させるモジュールが 2 つあります。1 つは「HTCP」で、もう 1 つは「高速」です。HTCPは高速TCPの略じゃないの？では、ここでの「HTCP」モジュールと「高速」モジュールの違いは何ですか? 違いを指摘してくれてありがとう。

スロー スタート フェーズ中の TCP 送信者の輻輳ウィンドウの増加率について質問があります。従来、cwnd のサイズは RTT ごとに指数関数的に増加します。たとえば、最初の cwnd 値が 1 の場合、2->4->8->16->.... と増加します。

私の場合、送信者は Linux カーネル 3.5 を使用しているため、最初の cwnd は 10 です。遅延 ACK なしで cwnd が 10->20->40->... と増加すると予想しました (受信側でオフにしました)。しかし、受信者が HTTP 経由で送信者から大きなサイズ (1MB 以上) のオブジェクトをダウンロードすると、cwnd は 10 -> 12 -> 19 -> 29 -> ... と増加します。このシーケンスが理解できません。

RTT を 100 ミリ秒に設定すると、リンク帯域幅は十分に高くなります。セッション中の損失はありません。受信者が 1 回の RTT 内に受信したパケットの数を数えることで、送信者の cwnd を推定しました。

誰かがこの振る舞いについて考えを持っていますか? ありがとう。