In late 2011 Jim Gettys published a trace of his own home connection while it pushed 20 GB of data to MIT. The link was delivering exactly what he had paid for; his caption on the goodput plot notes a steady 2 Mbps, “showing that I was getting all the bandwidth I expected.” On the same path, over the same seconds, the round-trip time had gone from under 10 milliseconds to more than 1.2 seconds.
That is bufferbloat explained as a measurement problem rather than a plumbing one. Throughput and latency are two different readings, and a saturated link with a large enough buffer in front of it maximises the first while destroying the second. The number on the dashboard stays green. The video call falls apart anyway.
A Queue Is Just Latency You Have Not Been Shown Yet
A buffer sits in front of a link so packets arriving while it is busy have somewhere to wait instead of being discarded. In moderation that is essential. The moderate amount is the bandwidth-delay product — bottleneck bandwidth times round-trip time — roughly one flight of packets, which is what stops a burst being thrown away wholesale.
Gettys measured what his buffer actually held. In Bufferbloat: Dark Buffers in the Internet (ACM Queue, Volume 9, issue 11, 29 November 2011), written with Kathleen Nichols, he records “500 KB in flight over a 10-ms path. My uplink bandwidth was 2 Mbps, so the true BDP was 2.5 KB.” Two hundred times the sizing rule, and they attribute the delay straight to it: “The one-second RTT is consistent with emptying a 500-KB buffer at 2 Mbps.” Everything queued behind that half-megabyte — a DNS lookup, a keystroke, an audio frame — waits out the whole drain.
That is the inversion at the heart of the problem: memory in front of a link does not remove congestion, it converts congestion from loss — visible and instantaneous — into delay, which is invisible to anything counting bytes per second. The most-read advice on this site is that a bandwidth figure does not tell you how a connection will feel. Bufferbloat is where that figure is not merely incomplete but actively reassuring while the link is unusable.
Loss Was Never the Congestion Signal. It Was a Proxy for One.
TCP’s congestion control has no congestion sensor. It has an inference: a lost packet means the network is overloaded, so slow down. That inference is why the internet survived the mid-1980s collapses — Van Jacobson and Michael J. Karels built the operational fix in 1988, and the lineage from there to CUBIC belongs to another article. What the inference assumed is what matters here.
The BBR authors state the assumption and its expiry date plainly. In BBR: Congestion-Based Congestion Control (ACM Queue, Volume 14, issue 5; the page is dated 1 December 2016 while the current IETF draft’s bibliography cites October 2016 — two documents that should know, disagreeing), they write that interpreting packet loss as congestion “was true at the time but was because of technology limitations, not first principles.” When memory was expensive a router’s buffer was about one bandwidth-delay product, so “the buffer is full” and “a packet was dropped” happened at almost the same instant. Loss was a fast, honest proxy for a full pipe.
Then memory got cheap. The same paper: “Subsequent memory price decreases resulted in buffers orders of magnitude larger than ISP link BDPs, and the resulting bufferbloat yielded RTTs of seconds instead of milliseconds.” Gettys and Nichols put it as an indictment: “Large buffers have been inserted all over the Internet without sufficient thought or testing. They damage or defeat the fundamental congestion-avoidance algorithms of the Internet’s most common transport protocol.”
The sender is not misbehaving. It is doing exactly what it was designed to do — grow the window until something drops — against a network that has stopped dropping. The damage is not linear, either. Gettys and Nichols note that “TCP’s reaction time is quadratic to the amount of overbuffering. A link that is 10 times overbuffered not only imposes 10 times the latency, but also takes 100 times as long to react to the congestion.” Their verdict on the interactive traffic sharing that link: it “loses completely to any long-lived flow that has saturated your link.”
The Instrument Was Destroying the Thing It Measured
The most useful paragraph in the 2011 paper is not about buffers; it explains why nobody caught this for a decade. Gettys describes chasing intermittent slowness at home, calling his ISP, blaming the cable — then realising why the fault vanished whenever he went looking: “in order to debug the network, I was stopping the work that was inducing the problem.”
An idle-line speed test has the same defect built in. It measures capacity by saturating the link, then reports a latency figure taken when nothing else is running. The IETF’s own responsiveness work is unusually candid about the consequences. Responsiveness under Working Conditions — an Internet-Draft, draft-ietf-ippm-responsiveness-09, dated 6 July 2026 and expiring 7 January 2027, by Christoph Paasch, Randall Meyer, Stuart Cheshire and Will Hawkins — records that loaded round-trip times “have generally been so much worse than the idle round-trip time (often by a factor of 100 or more) that it seemed almost impolite to draw attention to them,” and that “by measuring and reporting throughput and idle round-trip time, we have motivated vendors and operators to focus on those aspects of performance.”
That is a measurement failure with a procurement consequence. What gets reported gets optimised, and a metric blind to queuing delay produces equipment that is never penalised for having too much of it.
| Instrument | What it actually reports | Can it see bufferbloat? |
|---|---|---|
| Throughput test on an otherwise idle line | Peak goodput, up and/or down | No — a bloated link scores full marks |
ping while the line is idle | Propagation + processing delay | No — the queue is empty when you look |
ping sustained during a saturating transfer | Propagation + queuing delay | Yes — this is the whole measurement |
| Loaded-latency / “responsiveness” test | Working-conditions RTT, both directions | Yes, and it loads up and down together |
| Router interface counters (bytes, drops) | Volume and discard totals | Partially — drops appear only once the buffer overflows |
Measuring Latency Under Load, and Reading the Answer
The minimum viable test needs two terminals and no new software. In one, saturate the link for at least thirty seconds; a large upload is usually harsher, because residential uplinks are slower and their buffers are sized in bytes rather than milliseconds. In the other, run a continuous ping to a stable nearby host. Record the idle RTT first — the interesting figure is the difference.
Under a well-managed queue the loaded RTT rises by single- or low-double-digit milliseconds. Under a bloated one it climbs for seconds and then plateaus; Gettys’ plateau was 1.2 seconds, with three-second spikes where the buffer finally overflowed and dropped en masse. A plateau that scales with transfer rate is the signature: you are watching a queue drain at link speed.
The responsiveness draft expresses the same measurement as RPM — round-trips per minute — which is 60,000 divided by the loaded RTT in milliseconds, chosen so higher is better and the numbers land in a range people read intuitively. Apple’s networkQuality tool, named in the draft, implements it and runs upload and download concurrently on purpose, because a test that does them one at a time measures a condition households never experience. The draft’s own bands:
| Band | RPM | Equivalent loaded RTT |
|---|---|---|
| Poor | below 300 | worse than 200 ms |
| Fair | 300 – 1,000 | 200 – 60 ms |
| Good | 1,000 – 6,000 | 60 – 10 ms |
| Excellent | above 6,000 | better than 10 ms |
⚠️ These bands come from a draft, not a standard: draft-ietf-ippm-responsiveness-09 is Intended Status Standards Track but is not an RFC as of 8 September 2026. Cite it as a draft, with the revision.
One warning about where the queue is. The worst buffer Gettys owned was not in his router: over a weak 1 Mbps Wi-Fi link the bottleneck moved into his laptop, and the paper notes that a network interface’s 256-packet ring buffer “can add three seconds of delay” at that rate. The underlying arithmetic is small enough to keep in your head: “A single packet of 1,500 bytes is 12 ms of latency at 1 Mbps.” Test wired and wireless separately, or you will bill your own machine’s queue to your ISP.
Why the Repair Belongs at the Queue and Not in Your Sender
You cannot fully fix this from the endpoint, because you do not own the buffer. The fix is active queue management: dropping or marking packets before the buffer fills, so the congestion signal arrives while it is still actionable. RED, developed by Van Jacobson with Sally Floyd in 1993, was the first serious attempt, and RFC 8289 is candid about why decades of AQM advocacy did not stick: “Efforts to deploy AQM have been frustrated by difficult configuration and negative impact on network utilization.” The same RFC dates the underlying complaint — the “persistently full buffer” problem “has been discussed in the IETF community since the early 80s,” citing Nagle’s RFC 896.
CoDel was designed around that failure. RFC 8289 (Nichols, Jacobson, McGregor and Iyengar, January 2018, Experimental) describes “an estimator, a setpoint, and a control loop” that “requires no configuration in normal Internet deployments” — no-knobs is the deployment argument, not a modesty note. RFC 8290 (FQ-CoDel, January 2018, Experimental) adds per-flow queuing so a bulk transfer cannot build a queue in front of everything else; it “provides isolation for low-rate traffic such as DNS, web, and videoconferencing traffic.” Jim Gettys is a co-author, seven years after the diagnosis. That RFC also records the algorithm “is included in the mainline Linux kernel as the fq_codel queueing discipline” and had “already been turned on by default in a number of Linux distributions” as of January 2018. The L4S series — RFC 9330, RFC 9331 and RFC 9332, all January 2023 — pairs a dual-queue AQM with an ECN signal, so a sender can be told to slow down without losing a packet at all.
The endpoint is not powerless, only secondary. BBR declines the loss inference outright: it builds a model of the path from measured bottleneck bandwidth and round-trip propagation time and paces to their product, rather than filling whatever buffer it finds. ⚠️ Dated, because this moves: as of 8 September 2026 BBR is still not an RFC. The active document is draft-ietf-ccwg-bbr, revision -06, dated 6 July 2026 and expiring 7 January 2027, whose abstract “specifies version 3 of the BBR algorithm, BBRv3.” Whether BBRv3 shares a bottleneck fairly with a CUBIC flow is a live question with a version number attached; treat any unversioned claim about BBR fairness as underspecified.
| Where it sits | Mechanism | Status, dated 8 Sept 2026 |
|---|---|---|
| The queue | FQ-CoDel per-flow AQM | RFC 8290, Experimental (Jan 2018); mainline Linux fq_codel |
| The queue | CoDel delay-target AQM | RFC 8289, Experimental (Jan 2018) |
| Queue + sender | L4S dual-queue AQM with ECN marking | RFC 9330 | 9331 | 9332 (Jan 2023) |
| The sender | BBR model-based congestion control | Not an RFC — draft-ietf-ccwg-bbr-06, 6 Jul 2026 |
| The sender | Loss-based control (CUBIC and relatives) | Standardised — and the thing bufferbloat defeats |
None of it is new or unavailable, which is the uncomfortable part. The 2026 responsiveness draft says so in its opening: solutions “have been standardized and implemented, and are, to some extent, deployed. Nevertheless, poor network responsiveness, resulting from bufferbloat and other causes, continues to affect many services and the people who use them.” Fifteen years after the diagnosis the gap is not knowledge — it is that the measurement almost everyone runs still cannot see the fault.
This hub’s cornerstone argues that TCP/IP won its protocol war partly because it asked nothing of the network and pushed the intelligence to the endpoints. Bufferbloat is the invoice for that bargain arriving late. The sender is the only party making a congestion decision, and the middle of the network quietly disabled its instrument.
❓ Frequently Asked Questions
Is bufferbloat the same thing as network congestion? No, and conflating them sends people to the wrong fix. Congestion is demand exceeding capacity. Bufferbloat is what an oversized buffer does to the signal — it absorbs the overflow, delays the loss notification by seconds, and lets the sender keep ramping. Gettys and Nichols say long delays from bufferbloat are “frequently attributed incorrectly to network congestion, and this misinterpretation of the problem leads to the wrong solutions being proposed.”
Why does my speed test show full speed when calls still stutter? Because the throughput test is designed to saturate the link — exactly the condition that fills the buffer. It reports the capacity it achieved, not the queuing delay it caused. Any test reporting round-trip time only while the line is idle is structurally blind to this.
Does more bandwidth fix bufferbloat? Rarely, and never reliably. Queuing delay is buffer size divided by drain rate, so a faster link does drain a fixed buffer more quickly — but buffers are sized in bytes rather than milliseconds, they exist at several points on a path, and the bottleneck is frequently your own Wi-Fi or uplink rather than the tier you are upgrading.
Where is the bottleneck buffer likely to be? On a home connection, usually upstream — the modem or router queue in front of a slow uplink. It can equally be the Wi-Fi link, or your own machine’s driver ring buffer when the radio rate collapses. Test wired and wireless, upload and download, separately before assigning blame.
Can I do anything about it myself? Yes, for the part of the path you own. Enabling FQ-CoDel or a CAKE-style shaper on the router fronting your slow link — and setting the shaper slightly below the true line rate, so the managed queue rather than the modem’s queue becomes the bottleneck — is the standard remedy, and the one FQ-CoDel’s per-flow isolation was written for. It cannot help with a bloated queue elsewhere on the path.
Why does BBR matter if the problem is in the network? Because it is the one widely deployed sender that stops relying on the broken signal. Rather than growing a window until a drop appears, it estimates bottleneck bandwidth and round-trip propagation time and paces to their product, so it never fills an oversized buffer on the way to finding the limit. That does not repair a queue shared with loss-based senders, and BBRv3’s fairness against CUBIC remains open — but it is the endpoint-side half of the answer.
📚 Recommended Resources
Disclosure: some links below are Amazon affiliate links. If you buy through them, I earn a small commission — at no extra cost to you — which helps keep this site running.
Start with the free primary material. On this subject it genuinely beats the books. Gettys and Nichols’ Bufferbloat: Dark Buffers in the Internet (ACM Queue, 29 November 2011) is the whole diagnosis in one sitting, including the packet traces. RFC 8289 (CoDel) and RFC 8290 (FQ-CoDel) are short, plain text, and free, and their introductions explain the deployment problem better than any summary. RFC 3168 covers ECN; the L4S architecture covers what came after it. For the measurement side, read draft-ietf-ippm-responsiveness — it is a working document rather than a standard, so check the revision, but it is the clearest argument in print for why an idle-line latency figure is the wrong instrument.
- TCP/IP Illustrated, Volume 1: The Protocols (2nd Edition) by Kevin R. Fall and W. Richard Stevens (Addison-Wesley) — the reference for what is actually on the wire when you run the loaded-
pingtest in this article. Its value here is not the congestion-control chapter but the habit it builds: reading a capture and reasoning about what the sender believed at each moment. Once you can see a window growing against a queue rather than against a link, the plateau in your own trace stops being mysterious.
- High Performance Browser Networking by Ilya Grigorik (O’Reilly) — the best available treatment of latency as the limiting factor for anything interactive, and the one to read if you came here because a page or a call feels slow rather than because a graph looked wrong. It is explicit that bandwidth is largely a solved problem while round-trip time is not, and it works through the consequences for real applications. The full text is also published free at
hpbn.co, so read it before you buy it.
- Systems Performance: Enterprise and the Cloud (2nd Edition) by Brendan Gregg (Pearson) — included for the methodology rather than the networking chapters. The core lesson of this article is a measurement lesson: the instrument was destroying the thing it measured, and nobody noticed for a decade. Gregg’s insistence on stating the question first, and on distinguishing utilisation from saturation, is the general form of that mistake and the discipline that avoids it.
✅ Pro tip: run your loaded-latency test twice — once over Ethernet, once over Wi-Fi at a weak signal — before you blame anyone. If only the wireless run shows a multi-second plateau, the bloated buffer is inside your own machine or access point, and no amount of arguing with an ISP will move it.