WRED (Weighted Random Early Detection)

Queuing mechanisms like LLQ are about managing the front of our queues. RED (Random Early Detection) is about managing the tail of our queue.

Queuing mechanisms like LLQ are about managing the front of our queues. RED (Random Early Detection) is about managing the tail of our queue. When a queue is full, there is no room for any more packets and the router drops all packets. This is called tail drop. Data traffic is usually bursty so when

When a queue is full, there is no room for any more packets and the router drops all packets. This is called tail drop.

output queue full tail drop

Data traffic is usually bursty so when tail drop occurs, the router probably drops multiple packets. Tail drop is bad, especially for TCP traffic.

The TCP window size increases automatically but when TCP segments are dropped, it reduces back to one segment. The window size then grows exponentially until it reaches half the window size of what it was when the congestion occurred. The TCP window size then grows linearly. This process is called slow start and explained in detail in the TCP window size scaling lesson.

The problem with this behavior of TCP is that you probably don’t have just one TCP connection but multiple TCP connections. When the queue is full and tail drop occurs, everything is discarded and all TCP connections use slow start. We call this TCP global synchronization and it looks like this:

TCP Global Synchronization

To increase overall throughput, we can use a technique called RED (Random Early Detection). Instead of waiting for tail drop to happen, we monitor the queue depth. When the queue starts to fill up, we discard some random packets with the goal of slowing down TCP. The “weighted” part of WRED is that WRED monitors the average queue depth. When the queue starts to fill, it will only drop a few random packets. When the queue length increases, it becomes more aggressive and drops even more random packets until it hits a certain limit. When this limit is reached, all packets are dropped.

Here’s how to visualize this:

Wred Average Queue Depth

This graph has an X and Y axis:

  • Average queue depth: this is the length of our queue and for now, let’s say this represents the number of packets in the queue.
  • Discard probability: the chance in % that WRED drops our packets.

What do the different numbers mean? WRED uses a traffic profile for the packet drop probability based on the following three items:

  • Minimum threshold: 20 packets
  • Maximum threshold: 45 packets
  • MPD (Mark Probability Denominator): 25%

These values can be configured of course.

Here’s how it works:

  • When the average queue depth is below the minimum threshold (20), WRED doesn’t drop any packets at all.
  • When the average queue depth is above the minimum threshold (20), WRED starts to drop a small number of random packets.
  • When the average queue depth increases even further, WRED drops a larger % of random packets until we reach the maximum threshold (45).
  • When the average queue depth reaches the maximum threshold (45), WRED drops all packets.
  • The MPD (25%) is the number of packets that WRED drops when we hit the maximum threshold (45).
The default option for these thresholds is the number of packets but you can also use the number of bytes or even milliseconds/microseconds for these thresholds. The number of packets is the most common option.

We can summarize this in a table:

Average queue depth Action WRED action name
average queue depth < minimum threshold No packets are dropped. No drop
average queue depth > minimum threshold AND average queue depth < maximum threshold Percentage of packets is dropped. This percentage increases to a maximum (MPD) until we reach the maximum threshold. Random drop
Average queue depth > maximum threshold All packets are dropped. This is the same as tail drop. Full drop

Dropping all packets when we hit an artificial maximum threshold might sound weird. How is that any better than “regular” tail drop?

Some packets are more important than others so instead of dropping completely random packets, we use different traffic profiles for different packets. We can discard packets based on criteria like the CoS, IP Precedence, DSCP, and some other options.

Here is a quick example of two traffic profiles:

Wred Two Traffic Profiles

Above, we have two different traffic profiles. One for packets marked with IP precedence 3 and another one for IP precedence 5:

  • IP Precedence 3:
    • minimum threshold: 20 packets
    • maximum threshold: 45 packets
    • MPD: 25%
  • IP Precedence 5:
    • minimum threshold: 30 packets
    • maximum threshold: 60 packets
    • MPD: 20%

We drop IP precedence 3 packets earlier (minimum threshold 20 packets) and more often (MPD 25%) than IP precedence 5 packets.

Instead of IP precedence, we can also use DSCP. WRED then sets a minimum threshold based on the drop probability that we have seen in the IP precedence and DSCP values lesson:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 660 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

505 Sign Ups in the last 30 days

100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Forum Replies

  1. Hi Hamood,

    Glad to hear it was useful!


  2. Abhishek,
    I would recommend you check out Rene’s lesson on QoS Classification. In this lesson, you will discover that there are all kinds of tools at your disposal to be able to identify, classify, and mark traffic for QoS treatment throughout your network. It is rarely the case, for the reasons you brought up, that a simplistic approach of using just IP addresses is used.

    As for your second question, you are essentially asking about what QoS is meant to do as a whole (so there isn’t a quick, easy answer). The key to getting QoS working properly relies on th

    ... Continue reading in our forum

  3. The text below has also to be corrected.

    _> The first 3 bits are used to define the class and the next 3 bits are used to define the drop probability. Here are all the possible values that we can use:_

    Only 2 bits are used for drop probability, the 6th bit is ignored.

  4. Hello Maodo

    According to RFC2474 it speaks about the DS field:

       Implementors should note that the DSCP field is six bits wide.  DS-
       compliant nodes MUST select PHBs by matching against the entire 6-bit
       DSCP field, e.g., by treating the value of the field as a table index
       which is used to select a particular packet handling mechanism which
       has been implemented in that device.  The value of the CU field MUST
       be ignored by PHB selection.  

    It says that the entire 6-bit field must be used. The bits in question are bits 0 to 5 (a total of six bits

    ... Continue reading in our forum

  5. Hello Muhammad

    The rest of the lesson deals with Per Hop Behaviour. Essentially, this just refers to the way or the behaviour with which each router (per hop) will deal with a packet when it receives it based on the code point values found within the DS field. So when we talk about PHB it really means how the router will handle the particular packet compared to all the rest it receives whenever there is congestion.

    The default PHB has a DSCP value of zero or 000000. Such packets are treated as best effort, meaning, first come first serve. No special treatme

    ... Continue reading in our forum

37 more replies! Ask a question or join the discussion by visiting our Community Forum