Loss-based TCP (Cubic/Reno) only slows on a lost packet, so it keeps growing the window until a router buffer overflows. Big buffers let a lot of data pile up; the link is already full, so that data is pure waiting: d_q = q / C (queue size / link speed). Bigger buffer = more delay, not more speed = bufferbloat. CoDel watches each packet's sojourn time; if it stays above a target (5 ms) for an interval (100 ms) it drops packets early, TCP slows before the buffer fills, queues stay short.
BBR is model-based. It measures BtlBw (max delivery rate) and RTprop (min RTT) and computes BDP = BtlBw x RTprop - the data that fills the pipe with an empty queue. It paces sending at BtlBw and keeps about one BDP in flight: full pipe (max speed) with empty queue (min delay). It periodically probes for bandwidth and drains to re-measure RTprop.
TCP flaws: (1) head-of-line blocking - one ordered stream means one loss stalls everything behind it, even unrelated requests; (2) slow handshakes - TCP plus TLS takes several round-trips. QUIC runs over UDP with independent streams (a loss stalls only its stream), builds in TLS 1.3 and congestion control (1-RTT or 0-RTT), and survives network changes (connection migration). HTTP/3 is HTTP over QUIC.
100 Mbps, RTT 40 ms. BDP = 100,000,000 x 0.040 = 4,000,000 bits = 500,000 bytes. With a 2xBDP buffer: 1,000,000 bytes = 8,000,000 bits; queue delay = 8,000,000 / 100,000,000 = 0.080 s = 80 ms; peak RTT = 40 + 80 = 120 ms. BBR keeps about one BDP (500,000 B) in flight, so delay stays near 40 ms. Bonus: Cubic after loss cuts to 0.7 x 2 BDP = 1.4 BDP, leaving about 44 ms.