Bufferbloat, and why a fast line still stutters

A 900 Mbit/s speed test result and a video call that falls apart whenever somebody else uploads a file are both accurate readings of the same line. They measure different quantities. Throughput asks how much data crosses the link per second when nothing else is running. Call quality depends on how long each packet waits behind other packets while the link is already full. Bufferbloat.net names the cause plainly: link speed is not the problem, it is a router holding more data than necessary, and "This adds delay that can never be cured by faster transmission rates." Consumer speed tests overwhelmingly report the first number.

Where the queue actually forms

RFC 8289, the CoDel specification published January 2018, locates it precisely: "Packet queues form in buffers facing bottleneck links, i.e., where the line rate goes from high to low or where many links converge." A gigabit LAN port feeding a 40 Mbit/s uplink is that transition. So is the ISP line card feeding your downstream.

Queue depth also tells you nothing about how fast anyone is sending. The RFC works the example: a TCP connection with a 25 packet window through a path whose bandwidth delay product is 20 packets settles into "a 5-packet (+/-1) standing queue", and widening the window to 30 packets makes the queue 10 packets deep "with no change in sending rate". Hence: "Nothing can be inferred about the sending rate from the queue size, and any queue other than transient bursts only creates delays in the network."

A buffer that drains inside a round trip is doing its job. One that stays occupied is pure added latency, and a large buffer lets it stay occupied for a long time. Oversizing buffers looks like insurance against loss. It is how a 900 Mbit/s line acquires a quarter second of queuing delay.

Idle ping is the wrong number

The IETF draft that defines the responsiveness test, draft-ietf-ippm-responsiveness (version 09, 6 July 2026, authored at Apple and the University of Cincinnati), says why the usual figure misleads: most latency tests "report the round-trip time when the network is otherwise idle, which not a good predictor of how a network will behave when it is actively being used for normal data transfer". Its metric is RPM, "round-trips per minute", calculated by dividing 60 by the round trip time in seconds, deliberately chosen so higher is better.

The FCC's Thirteenth Measuring Broadband America fixed report was the first to publish latency under load, noting that "Latency, however, can increase significantly under conditions of heavy traffic stressing the network buffers." Its idle figures were unremarkable: "Measured idle latencies for DSL (between 23 ms to 34 ms) were slightly higher than those for cable (12 ms to 24 ms), and idle latencies were lowest for fiber ISPs (7 ms to 14 ms)." Under load, "the latency under downstream traffic load generally is significantly higher than idle latency, with a more pronounced difference for DSL subscribers".

Comcast published the cleanest controlled comparison. Two hardware variants of the same XB6 gateway shipped, one with upstream DOCSIS-PIE active queue management enabled and one without, across "over 26,000 tests run using random samples of RDK-B cable modems across the Comcast network in the United States between October 1 and December 31, 2020". The result: "when a device had AQM it consistently experienced between 15-30 milliseconds of latency under load", while "Those non-AQM devices experienced in many cases 250 milliseconds or higher latency under load." Same line rate, same plant, roughly a tenfold difference in the number that decides whether a call is usable.

How to measure the number that matters

Every useful test has the same shape: saturate the link, then measure round trip time while it is saturated. Bufferbloat.net's guidance: "If the test shows latency below 15-25 msec, it means that bufferbloat is under control", and its test page flags anything "above 50 msec, or a grade lower than "B"".

Cloudflare's AIM scoring, published 18 April 2023, awards points for the difference between loaded and unloaded latency: zero above 50 ms, 5 below 50 ms, 10 below 20 ms, 20 below 10 ms. More telling is which inputs feed which score. Streaming is "download bandwidth + unloaded latency + packet loss + (loaded latency - unloaded latency difference)". Gaming is "packet loss + unloaded latency + (loaded latency - unloaded latency difference)". Bandwidth is absent from the gaming formula, and from the real time communication one.

Run it wired before running it over Wi-Fi, or you cannot tell which of the two bottlenecks you measured.

fq_codel and CAKE

RFC 8290, published January 2018, specifies FQ-CoDel, "a powerful tool for fighting bufferbloat and reducing latency". It hashes packets into 1024 queues by default, runs CoDel independently on each with a target of 5 ms and an interval of 100 ms, and dequeues with a byte based deficit round robin. The scheduler keeps two lists, new queues and old queues, and a flow whose queue empties every round gets re-added as new: "This means it will effectively get priority over queues that do not empty out each round." That is the mechanism behind the abstract's claim that it "provides isolation for low-rate traffic such as DNS, web, and videoconferencing traffic". A voice call sends little enough to keep landing in the new list.

CAKE went into mainline with Linux 4.19, released 22 October 2018. Its man page describes it as combining "COBALT, which is an AQM algorithm combining Codel and BLUE, a shaper which operates in deficit mode, and a variant of DRR++ for flow isolation", plus 8 way set associative hashing and integrated overhead compensation. "Most people will only need to set the bandwidth parameter to get useful results."

The critical difference is that one can create a bottleneck and one cannot. The tc-fq_codel synopsis lists limit, flows, target, interval, quantum, ecn, ce_threshold and memory_limit, and no rate parameter of any kind. It manages a queue; it does not decide where the queue lives.

Why the shaper must sit below line rate

If your router forwards to the modem at gigabit Ethernet speed and the modem drains its uplink at 40 Mbit/s, the backlog accumulates inside the modem, and whatever qdisc your router runs is looking at an empty queue. Setting a shaper slightly under the real line rate makes your own box the slowest hop, moving the queue into the one place where you control the algorithm.

The tuning procedure is therefore empirical, not arithmetic. Measure link speed with the shaper off, turn it on, and then, in bufferbloat.net's words, "Keep running your speed test and adjusting the SQM speed settings until the latency remains low while achieving good speeds." OpenWrt's SQM guide starts you at about 90 percent of measured, because the configured rate is a gross rate including framing overhead the speed test never sees. CAKE addresses that directly with keywords for ATM, PTM and DOCSIS encapsulation, and with RTT presets: lan is 1 ms, metro 10 ms, regional 30 ms, internet 100 ms by default, oceanic 300 ms.

Downstream is the harder half. You are shaping traffic that has already crossed the bottleneck, so ingress shaping works only indirectly, by dropping or ECN marking early enough that senders slow down before the ISP buffer fills. Expect to surrender more headroom downstream than up.

What L4S changes, and what it does not

The three L4S documents all published January 2023: RFC 9330 for the architecture, RFC 9331 for the ECN protocol, RFC 9332 for the Dual-Queue Coupled AQM. RFC 9330 states the premise the previous fifteen years of AQM work had to route around: "the root cause of queuing delay is in the capacity-seeking congestion controllers of senders, not in the queue itself." Classic congestion control produces large sawteeth, so an AQM tuned for a shallow queue starves the link at the bottom of every tooth. Replace the sender's congestion control with a scalable one and that tradeoff goes away. RFC 9330 reports that with DCTCP and a Dual-Queue Coupled AQM on a DSL or Ethernet link, "queuing delay under heavy load is roughly 1-2 ms at the 99th percentile without losing link utilization", against "about 20-30 ms at the 99th percentile" for state of the art classic AQMs including FQ-CoDel and PIE. RFC 9331 gives the identifier: a sender "MUST set the ECN field in the IP header (v4 or v6) to the ECT(1) codepoint."

Deployment narrows the picture. RFC 9330 is explicit: "For any one L4S flow to provide benefit, it requires three (or sometimes two) parts to have been deployed: i) the congestion control at the sender; ii) the AQM at the bottleneck; and iii) older transports (namely TCP) need upgraded receiver feedback too."

All three are moving, slowly. Comcast started Low Latency DOCSIS field trials on 16 June 2023 "in collaboration with Apple, NVIDIA, and Valve", and launched on 29 January 2025 in "Atlanta, Chicago, Colorado Springs, Philadelphia, Rockville (Maryland) and San Francisco". Apple told developers at WWDC 2023 that "In iOS 17 and macOS Sonoma, L4S will be progressively rolled out to a random set of users", automatically for apps using HTTP/3 or QUIC through URLSession or Network framework. In their demonstration, "without L4S, packets experienced a round trip time of up to 45 milliseconds. But with L4S turned on, even the worst-case latency was cut by 50% and reduced to less than 25 milliseconds."

What L4S does not do is remove buffers you own. RFC 9330 notes that Wi-Fi, PON and cable all aggregate packets into bursts and buffer while building them, that radio links deliberately hold a standing queue to exploit sudden capacity increases, and that "L4S cannot remove the need for all these different forms of buffering." It expects an L4S AQM to be "needed where the Wi-Fi links in a home sometimes become the bottleneck". If your bottleneck is your own uplink queue or your access point, an L4S capable ISP changes nothing.

On the hardware you already have

Enable SQM if your router offers it, choose CAKE over fq_codel where both are listed, set download and upload to roughly 90 percent of measured, then tune down until loaded latency stops moving. If the firmware has neither, OpenWrt, pfSense, OPNsense and IPFire all expose one.

On a Linux box, check net.core.default_qdisc first. The kernel documentation still records its value as "Default: pfifo_fast", a plain FIFO with no AQM, and distributions vary on whether they override it. Setting it to fq_codel affects only that machine's own egress, which helps a busy server and does nothing for the router two hops away.

Then re-measure, wired and over Wi-Fi separately. RFC 7567, BCP 197, published July 2015, said the operative thing a decade ago: "Network devices SHOULD implement some AQM mechanism to manage queue lengths, reduce end-to-end latency, and avoid lock-out phenomena within the Internet." Most consumer gateways still ship without one, which is why the fix is usually yours to install rather than yours to buy.