Understanding TCP BBR Congestion Control and Bufferbloat

TCP BBR Overview – BBR is a congestion‑control algorithm introduced by Google in 2016 and shipped in Linux kernel 4.9. Unlike traditional loss‑based algorithms, BBR actively probes the network using a model of bottleneck bandwidth (BtlBw) and minimum RTT (RTprop).

Bufferbloat – Bufferbloat occurs when excessive buffering in routers or switches causes high latency, jitter, and reduced throughput. Large buffers fill up, leading to long queues even on high‑speed links, which harms interactive applications such as VoIP, gaming, and web browsing.

Problems with Loss‑Based Algorithms – Loss‑based congestion control (e.g., Reno, CUBIC) interprets packet loss as congestion, which was appropriate for early networks but now leads to bufferbloat on modern high‑bandwidth paths. When buffers are large, loss‑based algorithms keep them full, increasing RTT; when buffers are small, they misinterpret loss and unnecessarily reduce throughput.

BBR Principles – BBR seeks the operating point where BtlBw is maximized and RTprop is minimized, avoiding bufferbloat. It does this through distinct phases:

Startup – Quickly ramps up pacing rate using a high gain (2/ln(2)).

ProbeRTT – Periodically reduces inflight to a small target (4 packets) for at least 200 ms to measure the true minimum RTT.

ProbeBW – Cycles through a gain array to discover and utilize available bandwidth while draining excess queues.

Key terms used throughout:

RTprop – Minimum round‑trip propagation time.

BtlBw – Bottleneck bandwidth.

BDP = BtlBw × RTprop – The amount of data that can fill the pipe without buffering.

BtlBufSize – Total buffering capacity of intermediate routers.

Relevant Code Snippets

/* We use a high_gain value of 2/ln(2) because it's the smallest pacing gain
 * that will allow a smoothly increasing pacing rate that will double each RTT
 * and send the same number of packets per RTT that an un‑paced, slow‑start
 * Reno or CUBIC flow would:
 */
static const int bbr_high_gain = BBR_UNIT * 2885 / 1000 + 1;

/* Initialize pacing rate to: high_gain * init_cwnd / RTT. */
static void bbr_init_pacing_rate_from_rtt(struct sock *sk) {
    struct tcp_sock *tp = tcp_sk(sk);
    struct bbr *bbr = inet_csk_ca(sk);
    u64 bw;
    u32 rtt_us;
    if (tp->srtt_us) {
        rtt_us = max(tp->srtt_us >> 3, 1U);
        bbr->has_seen_rtt = 1;
    } else {
        rtt_us = USEC_PER_MSEC; /* use nominal default RTT */
    }
    bw = (u64)tp->snd_cwnd * BW_UNIT;
    do_div(bw, rtt_us);
    sk->sk_pacing_rate = bbr_bw_to_pacing_rate(sk, bw, bbr_high_gain);
}

static void bbr_update_bw(struct sock *sk, const struct rate_sample *rs) {
    struct tcp_sock *tp = tcp_sk(sk);
    struct bbr *bbr = inet_csk_ca(sk);
    u64 bw;
    bbr->round_start = 0;
    if (rs->delivered < 0 || rs->interval_us <= 0)
        return; /* Not a valid observation */
    if (!before(rs->prior_delivered, bbr->next_rtt_delivered)) {
        bbr->next_rtt_delivered = tp->delivered;
        bbr->rtt_cnt++;
        bbr->round_start = 1;
        bbr->packet_conservation = 0;
    }
    bbr_lt_bw_sampling(sk, rs);
    bw = div64_long((u64)rs->delivered * BW_UNIT, rs->interval_us);
    if (!rs->is_app_limited || bw >= bbr_max_bw(sk)) {
        minmax_running_max(&bbr->bw, bbr_bw_rtts, bbr->rtt_cnt, bw);
    }
}

Advantages of BBR

Performs well on long‑fat pipes where RTT is large.

Minimizes bufferbloat by keeping queues small.

Aggressively probes for unused bandwidth.

Provides stable throughput during the ProbeBW steady state, beneficial for video streaming.

Disadvantages of BBR

Slow to react to bandwidth reductions because it only senses changes during the ProbeBW gain cycle.

ProbeRTT reduces sending rate sharply, which can cause noticeable stalls for latency‑sensitive applications.

Sensitive to RTT jitter, especially on wireless links with variable delays.

Conclusion – Selecting a congestion‑control algorithm depends on the specific workload and network environment. BBR offers high throughput and low latency on stable, high‑bandwidth paths but may require tuning or alternative algorithms for highly variable or latency‑critical scenarios.