LTEやWiMaxのような損失の多いワイヤレスネットワーク用に特別に設計された他の輻輳制御アルゴリズムは何ですか？
TCPフローのセットアップ全体で最大のスループットと最小の遅延を得るために、さまざまな輻輳制御アルゴリズムを試しています。他の利用可能なアルゴリズムを提案してください。
ヴェノ、ウェストウッド、リノ、キュービック
その実装（またはカーネルモジュール）はインターネット上で無料で入手できます。また、TCP Linux（Fedora）とWindows7のTCPプロトコルスタックの両端で実行）でより高いスループットを取得する他の方法があるかどうかを提案します。
BBR :)。
パケット損失率が15％未満の場合、BBRはパスを完全に利用できます （link_bandwidth *（1-loss_rate）に到達）。この15％のしきい値は、基本的な制限ではなく、設計パラメーターです。
私はこれの正確な重要性を説明するのに苦労しています。これがEricDumazetです。
キュービックと比較すると、損失の多い環境では2〜4桁の違いがあります。
100ms rtt、および1％のパケット損失の例。キュービックはそこで非常に悪いパフォーマンスをします。
$ netperf -H 10.246.7.152 -l 30 -- -K cubic
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.246.7.152 () port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 40.00 3.27
$ netperf -H 10.246.7.152 -l 30 -- -K bbr
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.246.7.152 () port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 30.25 9150.01
サードパーティのテストにより、競合が発生した場合、現在のコードがボトルネックでフルバッファ（BDP）を想定しているという説明が明らかになりました。これは、さらなる改善の既知の目標です。条件が満たされない場合、それは損失率を押し上げます。そうすると、従来のTCPは基本的に飢えます。
1 BDPよりも多いバッファがある場合、BBRフローは協力して、過剰なバッファがいっぱいにならないようにします。したがって、要求に応じてキューイング遅延を制限する。従来のTCPは、バッファ全体をいっぱいにする傾向があります。両方が競合している場合、BBRは従来のTCPフローの動作を魔法のように修正することはできませんが、これがBBRを他の方法で傷つけることはないと思います。
上記の条件が満たされない場合、アプリケーションの遅延が発生します（失われたパケットを再送信する必要があります）。
https://groups.google.com/forum/#!forum/bbr-dev
執拗なTCPはあなたが得ることができる最も執拗なTCPでしょう。