異なるモデルと混雑指標

TCPの混雑制御は経路容量を利用しながら混雑に対応するため送信動作を調整します。CUBICは混雑後のウィンドウ増加に時間ベースの三次関数を使い、RFC 9438が2023年にIETF Standards Track規格として仕様を更新しました。GoogleのBBR系はボトルネック帯域と最小RTTを推定して送信をモデル化します。「損失を無視する」「どのネットワークでも遅延や損失をなくす」と説明するのは正確ではありません。挙動はBBRの版、実装、損失・ECN処理、経路条件で変わります。

標準化の状態と版

RFC 9438はCUBICの仕様であり、複数のTCPスタックで採用されていると説明します。一方、ここで参照するBBR文書はIETF Internet-Draftで、RFCやStandards Track仕様と同じ位置付けではありません。草案の版がOSに収録されたコードと一致するとも限りません。BBRv1の研究結果をBBRv2やBBRv3の結果として扱わず、実際に製品・カーネル配布版・ビルドに含まれる制御器を確かめます。

Linuxで有効にする条件

Linuxカーネルに実装が含まれている必要があり、利用可能な方式はsysctl net.ipv4.tcp_available_congestion_controlで確認できます。BBR対応カーネルではnet.ipv4.tcp_congestion_control=bbrを設定できますが、適用範囲や既定値はディストリビューションとソケット設定によります。GoogleのBBR FAQは送信側のペーシングとfqキュー規律を使う実装経路を説明しています。方式名を変えるだけでエンドツーエンドの性能向上が保証されるわけではありません。他のOSは各TCPスタックの設定手順に従います。

専門家による測定結果

Benedikt Jaeger、Dominik Scholz、Daniel Raumer、Fabien Geyer、Georg Carleによる2019年の再現可能なエミュレーション研究は、評価した当時のBBR実装が他の制御器と競合する際に公平性の問題を示し得ると報告しました。CUBIC、Reno、Vegas、Illinoisとの相互作用やBBR同士の公平性を測っています。これは特定の版と設定の研究で、現在のすべてのBBRに対する結論ではありません。共存する制御器、RTT、ボトルネック、バッファ、損失条件を明示して再試験する根拠として読みます。

比較で測るもの

スループットだけで方式を選ばず、RTT遅延、キュー量、損失・再送、同時フロー間の公平性、異なるRTTのフロー間の結果を同じボトルネック条件で比較します。BBRの帯域探索は一時的なキューを作ることがあり、CUBICの遅延や公平性も実装と経路で変わります。ここでの専門家の見解は論文著者による再現可能な測定であり、現行OSの性能保証ではありません。

参考資料