WRED and Congestion Avoidance: Dropping Packets on Purpose

The obvious way to handle a full queue is to drop whatever arrives once the queue is full. It is called tail drop, it is the default, and it causes a subtle, damaging problem that gets worse exactly when the network is busiest. Weighted Random Early Detection is the counterintuitive fix: start dropping packets before the queue is full, deliberately and at random. Understanding why that is better than waiting is the whole point of this article.

It extends the QoS cluster guide and builds on the queueing policy from LLQ and CBWFQ.

The Problem: Tail Drop and Global Synchronization

Here is the failure mode WRED exists to solve, and it is more interesting than it first sounds. When a queue fills and tail drop kicks in, it drops packets from many TCP flows at once, because they all happen to be sending when the queue overflows. Every one of those TCP senders sees loss, and every one of them backs off simultaneously (TCP's congestion response). The link suddenly empties. Then all those senders ramp back up together, refill the queue, overflow it again, and all back off again, in lockstep.

This is TCP global synchronization, and it produces a sawtooth: the link oscillates between overfull and underused, never settling at efficient steady-state utilisation. You get the worst of both worlds, congestion loss and wasted capacity, and it is entirely an artifact of dropping everyone at the same instant.

How WRED Works

WRED watches the average queue depth and drops probabilistically based on how full the queue is getting. Three parameters per traffic class define the behaviour:

Between the minimum and maximum thresholds, the drop probability rises smoothly from zero to the mark probability as the queue fills. So a lightly-loaded queue drops nothing, a filling queue drops a few random packets (nudging a few flows to slow down), and only a genuinely overwhelmed queue tail-drops. The randomness is the key: by dropping from different flows at different times rather than all at once, WRED breaks the synchronization.

The "Weighted" Part: DSCP-Aware Dropping

The W in WRED is what makes it useful for QoS. Plain RED drops all traffic in a queue equally. Weighted RED uses different thresholds per DSCP value, so more-important traffic gets more aggressive thresholds (dropped later) and less-important traffic gets dropped earlier. This means that as a queue fills, WRED sheds the low-priority traffic first, protecting the high-priority traffic in the same class.

Configured with one line inside the class:

R1(config-pmap-c)#  random-detect dscp-based

And the resulting drop profile is visible in the policy output. Here is the BULK-DATA class from the lab, showing WRED active with per-DSCP thresholds:

R1#show policy-map interface Ethernet0/2 | begin BULK-DATA
    Class-map: BULK-DATA (match-all)
      6767 packets, 10222250 bytes
      Match:  dscp af11 (10)
      bandwidth 40% (4000 kbps)
        Exp-weight-constant: 9 (1/512)
        Mean queue depth: 0 packets
        dscp       Transmitted      Random drop   Tail drop   Minimum   Maximum   Mark
                   pkts/bytes       pkts/bytes    pkts/bytes  thresh    thresh    prob
        af11       6767/10222250    0/0           0/0         32        40        1/10

Read the profile: AF11 traffic starts being randomly dropped at a queue depth of 32 packets (minimum threshold), reaches its peak drop rate of 1/10 at 40 packets (maximum threshold), and tail-drops above that. The Exp-weight-constant (1/512) controls how the average queue depth is calculated, smoothing out momentary spikes so WRED reacts to sustained congestion, not transient bursts.

An honest platform note

Notice Random drop 0/0 and Mean queue depth: 0 packets in that capture, despite the link being genuinely congested during the test. This is a limitation of the virtual IOL platform: its software queue does not build the sustained depth that a hardware queue does under load, so the average queue depth never climbed past the minimum threshold to trigger random drops. The drops during congestion happened at the link-conditioning stage instead (visible as TCP retransmissions in the LLQ article). The WRED profile is correctly installed and shown; the random-drop mechanism needs a real hardware queue building depth to fire, which is exactly what happens on production routers. No fabricated drop counters are shown here.

ECN: Marking Instead of Dropping

WRED has a modern refinement worth knowing: Explicit Congestion Notification. Instead of dropping a packet to signal congestion, ECN marks it (sets a bit in the IP header) and lets it through. An ECN-aware TCP sender sees the mark and slows down without ever losing the packet, so you get the congestion signal without the retransmission.

R1(config-pmap-c)#  random-detect dscp-based
R1(config-pmap-c)#  random-detect ecn

ECN is strictly better than dropping when both endpoints support it (most modern stacks do): the flow slows down, nothing is lost, no retransmit. It is the same early-warning idea as WRED, delivered by a mark rather than a drop. The catch is that both endpoints and the path must honour it, so it is deployed where you control the stack.

When to Use WRED (and When Not To)

• Use WRED on TCP-heavy queues. Its whole benefit is managing TCP's congestion response and avoiding global synchronization. On bulk-data and default classes full of TCP flows, it improves steady-state utilisation.
• Never use WRED on a voice/priority queue. Voice is UDP; it does not respond to drops by slowing down (there is no retransmit and no backoff), so dropping voice packets early just degrades the call for no benefit. The LLQ priority class should tail-drop (or better, be policed so it never fills). This is why the lab's EF class has no WRED.
• It only helps under sustained congestion. On a link that rarely fills, WRED does nothing. Its value is on links that regularly run hot.

FAQ

Why drop packets before the queue is full?

To avoid TCP global synchronization. Tail drop drops many flows at once, making them all back off together and causing a sawtooth of over-full then under-used. WRED drops a few random packets early, nudging a few flows to slow down and keeping utilisation smooth.

What does "weighted" mean in WRED?

Different drop thresholds per DSCP value, so lower-priority traffic in a queue is dropped earlier than higher-priority traffic. WRED sheds the less important traffic first as the queue fills.

Should I put WRED on my voice queue?

No. Voice is UDP and does not respond to early drops by slowing down, so WRED just harms call quality. Use WRED on TCP queues (bulk, default); let the priority queue tail-drop or rely on its policer.

What is ECN?

Explicit Congestion Notification: instead of dropping a packet to signal congestion, mark it and let it through. An ECN-aware sender slows down without a retransmission. Better than dropping when both ends support it.

Why were the WRED drop counters zero in the lab?

The virtual IOL software queue did not build sustained depth under load, so the average queue depth never crossed the minimum threshold. The profile is installed correctly; the random-drop mechanism fires on hardware queues that build real depth. The congestion drops in the test happened at the link conditioner.

Key Takeaways

• Tail drop causes TCP global synchronization: dropping many flows at once makes them all back off together, producing a sawtooth of over-full then under-used.
• WRED drops a few random packets before the queue is full, nudging individual flows to slow down early and keeping utilisation smooth.
• Three parameters: minimum threshold (start dropping), maximum threshold (peak drop rate, then tail-drop), mark probability (the peak rate).
• Weighted = per-DSCP thresholds, so WRED sheds lower-priority traffic first. Configured with random-detect dscp-based.
• ECN marks instead of drops, signalling congestion without loss when both ends support it.
• Use WRED on TCP queues; never on voice (UDP does not back off). Honest note: the virtual queue did not build depth to trigger random drops, though the profile is correctly installed.

Next: Hierarchical QoS and shaping, or the QoS cluster guide.