Bufferbloat & Active Queue Management: RED vs CoDel

Why Bigger Buffers Made Latency Worse

A router's output queue exists to absorb short bursts, moments where packets arrive faster than the outgoing link can transmit them, smoothing traffic instead of dropping every burst immediately. The naive policy, called tail-drop, simply queues every arriving packet until the buffer is completely full, then drops any further arrivals until space frees up. This works fine for genuinely brief bursts, but for a sustained bulk flow, a large file download for instance, the sending TCP connection will keep increasing its transmission rate as long as it detects no packet loss, and if the buffer is large enough, packets can queue for a very long time before the buffer actually fills and a drop finally occurs. During all that time, the queue is sitting nearly full of that bulk flow's packets, and because a FIFO queue serves packets strictly in arrival order, every other packet sharing that link, including latency-sensitive traffic like a voice call or an interactive game, is stuck waiting behind potentially hundreds of milliseconds or even seconds worth of queued bulk data. This is the essence of bufferbloat: the buffer is doing exactly what it was built to do, avoid dropping packets, but in doing so it silently converts a fast, low-latency link into one with terrible latency for everyone, precisely because oversized buffers delay the loss signal that TCP relies on to know it should slow down. The problem became widespread specifically because cheap memory made it easy for manufacturers to add large buffers to home routers, cable modems, and switches without appreciating this consequence, and the term bufferbloat itself was popularized around 2010 by researcher Jim Gettys, who diagnosed exactly this dynamic on his own home network.

Random Early Detection: Dropping Before Full

Random Early Detection, or RED, proposed by Sally Floyd and Van Jacobson in 1993, was the first widely deployed answer to this class of problem, though it predates the bufferbloat term itself and was originally motivated by router congestion collapse concerns rather than latency specifically. RED continuously tracks the average queue occupancy and, rather than waiting for the buffer to become completely full, begins probabilistically dropping packets once that average exceeds a configured minimum threshold, with the drop probability increasing linearly as occupancy climbs toward a maximum threshold, beyond which it drops everything the way tail-drop would. The probabilistic, early nature of these drops is the key idea: by dropping a small fraction of packets from various flows before the queue is full, RED gives TCP senders an early congestion signal, causing them to back off before the queue has a chance to grow to its maximum, latency-destroying size, and randomizing which packets get dropped avoids the synchronized behavior where every flow backs off simultaneously and then ramps up simultaneously again. In practice, however, RED proved notoriously difficult to configure correctly: its thresholds and drop probability curve need tuning relative to the specific link's bandwidth, typical round-trip times, and traffic mix, and poorly tuned RED could either fail to prevent bufferbloat, if thresholds were set too high, or hurt throughput unnecessarily, if set too low or too aggressively, which significantly limited its real-world adoption despite two decades of academic refinement and variants.

CoDel: Managing Delay Directly

CoDel, short for Controlled Delay and developed by Kathleen Nichols and Van Jacobson around 2012, took a fundamentally different approach that sidesteps RED's tuning difficulty. Rather than tracking queue occupancy in bytes or packets and requiring administrators to guess appropriate thresholds for a particular link, CoDel directly measures how long each packet actually sits in the queue, its sojourn time, and compares that against a fixed, small target delay, 5 milliseconds by default. If the minimum sojourn time observed over a rolling interval stays above this target for longer than a set interval, 100 milliseconds by default, CoDel begins dropping packets, and if the condition persists, it drops more frequently, following a schedule based on the square root of the count of consecutive drop-triggering intervals, specifically designed to converge quickly on a dropping rate that keeps queueing delay near the target without needing any link-speed-specific tuning at all. This delay-based approach is elegant because sojourn time is a nearly universal signal: a millisecond of queueing delay means roughly the same thing for user experience whether the underlying link is a slow home connection or a fast data center interconnect, unlike a fixed number of queued bytes, which represents wildly different delay depending on link speed. Critically, CoDel is also careful to distinguish a persistently full queue, evidence of genuine sustained congestion that needs correcting, from a queue that briefly fills during a legitimate burst and then drains, only intervening in the former case, which lets it preserve full throughput for well-behaved traffic while still aggressively controlling latency, achieving what RED's designers had wanted but struggled to tune correctly.

The Throughput-Latency Tradeoff, Visualized

Every AQM scheme navigates the same fundamental tension: drop or mark packets too aggressively and you sacrifice throughput unnecessarily, forcing TCP senders to back off even when the link could actually sustain more traffic; drop too little or too late and you get bufferbloat, near the full nominal throughput but with queueing delay that makes the connection feel sluggish for anything latency-sensitive. Tail-drop with a large buffer sits at one extreme, maximizing eventual throughput for bulk transfers at the cost of potentially enormous latency for everyone sharing the link. A well-tuned AQM scheme aims to sit much closer to the sweet spot, keeping queueing delay low and bounded while still allowing the link to run at close to full utilization, since a well-designed AQM only needs to drop a small percentage of packets to keep TCP's congestion window appropriately sized. This simulation makes the difference visible by feeding the same bursty traffic pattern, mixing a sustained bulk flow with occasional latency-sensitive small packets, through router buffers running each of the three policies, and plotting queueing latency over time for each. Under tail-drop, you should see latency climb steadily as the bulk flow fills the buffer and stay high until a drop finally occurs. Under RED, drops happen earlier and delay stays somewhat more bounded, though possibly with more variance depending on threshold tuning. Under CoDel, delay should hover close to its small target value throughout, demonstrating directly why this class of algorithm matters far beyond an academic curiosity, it is the difference between a video call that stutters and one that does not, running on the exact same physical link.

From Research to Real Networks

Bufferbloat and its AQM remedies moved from academic papers to real-world deployment over roughly the 2010s, driven in large part by measurement work showing that consumer routers, cable modems, and even cellular networks routinely exhibited queueing delays of hundreds of milliseconds to multiple seconds under load, dwarfing the underlying propagation delay of the link itself. CoDel and its refinement FQ-CoDel, which combines Controlled Delay with per-flow fair queuing so that one greedy flow cannot monopolize the queue and starve others even before AQM kicks in, are now widely implemented in the Linux kernel's traffic control subsystem and shipped as the default or recommended queueing discipline in many consumer and open-source router firmware projects, including OpenWrt. The IETF eventually standardized CoDel and PIE, another delay-based AQM developed independently at Cisco with similar goals, as recommended approaches for combating bufferbloat on the modern internet. Beyond wired routers, the same fundamental principle, measure and bound actual queueing delay rather than just queue occupancy, has influenced buffer management in cellular base stations, Wi-Fi access points, and even software network stacks handling virtualized traffic in data centers, wherever a shared, bursty resource creates the same latent risk that a well-intentioned buffer, sized to prevent packet loss, ends up silently costing users the responsiveness they actually care about far more than they care about raw throughput.

Frequently asked questions

Try it live

Everything above runs in your browser — open Bufferbloat & Active Queue Management: RED vs CoDel and change the parameters while it is running. Nothing is installed, nothing is uploaded, the whole model lives in one tab.