BBR の帯域・RTT推定モデル

BBR が解こうとした問題

CUBIC や Reno などのロスベース輻輳制御は、パケットロスを輻輳の合図に使います。だが現代の回線では前提が崩れる。バッファが深いボトルネックではロス前にキューが溜まり遅延だけ膨らみ（bufferbloat）、浅いボトルネックでは輻輳でないランダムロスで速度が落ちます。

BBR（Bottleneck Bandwidth and Round-trip propagation time）はロスを信号にしません。代わりに経路の実力そのもの、ボトルネック帯域と伝搬遅延を直接推定し、それを満たすだけ送ってキューを作らずに帯域を埋めます。

2つの量を別々に測る

BBRが推定する量は次の2つで、同時には正確に測れないという制約が設計を決めています。

• BtlBw（Bottleneck Bandwidth）: 経路上で最も狭い区間の配送レート。各ACKから得る配送レート（delivered量 ÷ 経過時間）の、直近およそ 10RTTぶんの最大値を採用する。最大値を取るのは、キューが空でボトルネックを完全に使えた瞬間こそ真の帯域だから。
• RTprop（Round-trip propagation time）: キュー遅延を含まない純粋な往復伝搬遅延。観測RTTの、およそ 10秒窓の最小値を採用する。最小値を取るのは、キューが空のときのRTTだけが伝搬遅延に等しいから。

ここに本質的なジレンマがあります。帯域を測るにはキューを満たすほど送る必要があり、伝搬遅延を測るには逆に絞ってキューを空ける必要がある。片方を測ると他方が測れないため、BBRは両者を時間的に分離して交互に推定します。これが状態機械の動機です。

推定した2量から、送るべき量を決めます。

BDP        = BtlBw * RTprop          # 適正なin-flightの基準量
in-flight ≈ cwnd_gain * BDP          # cwnd_gainは約2（後述）
ペーシング速度 = pacing_gain * BtlBw # ACKを待たず時間軸で送出を整形

cwnd（ウィンドウ上限）は通常 2 * BDP 程度に置きます。係数2は、ACK返しの遅延やデバイスのバースト的なACK集約（aggregation）があっても帯域を100%使い切るための余裕です。

状態機械：Startup → Drain → ProbeBW → ProbeRTT

BBRは4つの状態を遷移しながら、上記2量を測り続けます。

• Startup: 接続開始直後。pacing_gain ≈ 2/ln2 ≈ 2.89 で指数的に増速し、帯域を素早く探る。配送レートが3RTT連続でほぼ頭打ちになったら、ボトルネックに達したと判断して次へ。
• Drain: Startupで作りすぎたキューを吐き出す。pacing_gain を逆数にしてin-flightをBDPまで落とす。
• ProbeBW: 定常状態。pacing_gain を [1.25, 0.75, 1, 1, 1, 1, 1, 1] の8段で巡回させる（各段はおよそRTprop長）。1.25でわずかに増速して空いた帯域を探り、もし帯域が増えていればBtlBwの最大値が更新される。続く0.75で、増速中に作ったキューを吐き出して遅延を戻す。残り6段の1.0で安定して流す。
• ProbeRTT: RTpropを測り直すための状態。約10秒間RTprop最小値が更新されないと突入し、in-flightを 4パケットまで絞って最低200ms維持する。キューが空くので、ここで観測した最小RTTを新しいRTpropとして採用する。

       startup_done            queue_drained
Startup ───────────▶ Drain ───────────────▶ ProbeBW ◀─┐
                                               │       │ RTprop更新
                                  RTprop未更新  │       │（ProbeRTT完了）
                                  約10秒経過    ▼       │
                                            ProbeRTT ──┘

ロスベース制御との違い

同じ「速く・公平に流す」目的でも、何を信号にするかが根本的に異なります。

高遅延で軽微なロスがある**長く太い管（BDPの大きい経路）**ほどBBRの優位が出ます。ロスベースはBDPが大きいほどウィンドウを大きく育てる必要があるのに、途中のロスで頻繁に縮むため帯域を埋めきれないからです。BDPの基礎は帯域・レイテンシ・スループットも参照。

公平性と注意点

初版BBRv1は万能ではありません。BtlBwを最大値で測るため、複数BBRフローが同居すると帯域配分が偏ることがあり、深いバッファでCUBICと競合するとロスを待つCUBIC側が不利になりがちです。これらを直すため、ロス率やECNも補助信号に取り込むBBRv2/v3が開発されています。

実務ではQUIC（HTTP/3）やLinuxサーバーの送信側で採用が進みます。前提となるTCP と UDP、品質制御の全体像QoSと合わせると位置づけが見えてきます。