Congestion-control research and its evaluation dependencies

Why it matters

"Is BBR better than CUBIC?" has no unconditional answer, and the question tests whether you know why. A strong answer names the design differences, the tradeoffs and the conditions under which each published result holds, and proposes an experiment that would settle a specific claim.

Core ideas

Families by signal.

• Loss-based (Reno, CUBIC): increase until loss, then back off. Robust and widely deployed; tends to fill buffers (high delay with deep buffers) and to underuse paths with random loss or shallow buffers. CUBIC's growth depends on time since the last loss rather than on RTT, which improves scaling and RTT fairness relative to Reno.
• Delay-based (Vegas and later designs such as Copa, or Swift in data centers): back off when RTT rises above the base RTT. Can keep queues short, but loses throughput against loss-based competitors that keep filling the buffer (some designs detect this and switch to a more aggressive mode), and is sensitive to noisy delay measurements.
• Model-based (BBR): estimate bottleneck bandwidth (a windowed maximum of delivery rate) and propagation RTT (a windowed minimum), pace at the estimated rate and cap inflight near a multiple of the estimated BDP, with periodic probing for more bandwidth and for a lower RTT.
• Explicit signals (DCTCP, L4S-style schemes): react to ECN marks set by the network, which requires network support.
• Learning- or utility-based designs optimize an objective online or from training, and inherit the question of how far beyond their training conditions they generalize.

Tradeoffs. No algorithm simultaneously maximizes throughput, minimizes delay and loss, shares fairly with itself and with incumbents, and stays robust to noisy signals. Each design picks a point, and the evaluation shows where.

What changes the conclusion.

• RTT of each flow and RTT differences between competitors.
• Bottleneck rate and location (access link, Wi-Fi, cellular scheduler, data-center switch) and whether the bottleneck moves.
• Buffer depth relative to the BDP and the queue policy: drop-tail versus AQM (RED, CoDel, FQ-CoDel), shared versus per-flow queues, traffic policers.
• Loss model: random non-congestion loss, bursty loss, or overflow loss only.
• Cross traffic: number of flows, their algorithms and start times, short versus long flows, application-limited traffic.
• Implementation and version: kernel versus user space, pacing and offload support, parameter settings, and BBRv1 versus later versions, which also use the packet loss rate to address the retransmission and fairness problems reported for v1.

For example, the BBR article itself reports that loss-based competitors take more than their share when buffers exceed several BDPs, while controlled studies later found BBRv1 taking more than its share in shallow buffers, with heavy retransmissions in some settings. Two papers that omit buffer depth or version cannot be compared.

Common misconceptions

• "One algorithm is best." Rankings flip across buffer sizes, loss models and competitors.
• "BBR ignores loss." BBRv1 largely did; later versions bound inflight data when loss exceeds a threshold. Always state the version.
• "Fair to itself means fair to others." Convergence among flows of one algorithm says little about coexistence with CUBIC.
• "Delay-based means low latency in practice." Against loss-based competitors, delay-based flows back off while the queue stays full.
• "Emulator results transfer directly." Emulators omit cellular schedulers, ACK aggregation and policers unless you model them.

How to approach it

For any claim, write the condition table first: bandwidth, RTTs, buffer, queue policy, loss, cross traffic, implementation and version. Then design the smallest experiment that could falsify the claim. Read the BBR article with its guide, then one independent evaluation, and compare their condition tables.