TCPフロー設定で最大スループットと最小待ち時間を得るために、さまざまな輻輳制御アルゴリズムを試しています。次のほかに利用可能な他のアルゴリズムを提案してください。
ビーノ、ウエストウッド、リノ、キューブ
実装（またはカーネルモジュール）はインターネット上で無料で利用できます。そして、より高いスループットを得るために、さまざまな点でLinux（Fedora）とWindows 7 TCPスタックの間でTCPを実行する別の方法があることを提案してください。
ベストアンサー1
ブラックボックス：）。
パケット損失率が15％未満の場合、BBRはパスを完全に活用できます。(link_bandwidth*(1 - loss_rate) に達する)。この15％しきい値は、デフォルトの制限ではなく設計パラメータです。
これが何を意味するのかを正確に説明しようとしています。私はエリックデュマセットです：
キュービックと比較すると、損失のある環境では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は、2つが競合するときにレガシーTCPストリームの動作を魔法のように修正することはできませんが、これは他の方法でBBRに害を及ぼさないと思います。
上記の条件が満たされない場合は、アプリケーションの待ち時間に影響します（失われたパケットを再送信する必要があります）。
https://groups.google.com/forum/#!forum/bbr-dev