Network Congestion Avoidance: WRED the Sophisticated Choice
My last article, on Simple Strategies to Eliminate Network Congestion Headaches, was an introduction to network congestion avoidance, where I covered queuing, queuing mechanisms, and dropping schemes. Today’s article focuses exclusively on Weighted Random Early Detection (WRED), which is a sophisticated network congestion avoidance mechanism.
Weighted Random Early Detection is able to prioritize different traffic flows so that important dataflows get better QoS services. In this article I’ll explain WREDs operation and introduce you to the benefits of this mechanism.
Network Congestion Avoidance Capabilities
The idea behind WRED invention was to take full advantage of TCPs congestion control mechanism by eliminating buffer tail drops. Without congestion avoidance implementation, TCP synchronization may occur. This takes place when an interfaces output queue is full causing newly arriving packets to be dropped. As a consequence, all active TCP flows go into TCP slow start resulting in bandwidth underutilization.
Imagine the impact on expedited traffic flows. This could lead to customer dissatisfaction and Service Level Agreement (SLA) violation.
WRED prevents exhaustion of buffers capacity by applying different dropping weights to different traffic flows; hence dropping packets based on QoS differentiation prior to congestion existence. WRED is an evolution of RED, so let’s first take a look at how RED operates.
Random Early Detection (RED) Basics
RED uses a packet drop profile to handle packet discarding. This profile defines a set of dropping probabilities according to the level of queue occupancy. A minimum and a maximum threshold are defined as shown in the diagram below.
If the queue occupancy lies beneath the minimum threshold, then packet drop does not occur (0% drop probability). If the queue occupancy is somewhere between minimum and maximum thresholds then packets are dropped according to the configured drop probability (exponentially increases as queue depth increases). When the queue occupancy crosses maximum threshold, then all new packets attempting to enter the queue are discarded (100% drop probability).
Weighted Random Early Detection (WRED)
WRED is an extension to RED. It allows configuring different drop profiles to different traffic flows hence providing different QoS for different types of traffic. WRED is able to distinguish traffic flows by examining IP precedence value (TOS field in IP header) or in case of differentiated service enabled flow, the DSCP.
Configuring Precedence-Based WRED
In IP header, precedence is defined using 3 bits (decimal values 0 to 7). Lowest priority traffic is assigned precedence value 0 whereas highest priority traffic is assigned precedence value 7. For each precedence value, different minimum and possibly different maximum threshold values may be configured. To configure precedence-based WRED on an interface the following command is used:
Router(config-if)# random-detect precedence [0..7] [min-thresh] [max-thresh] [mark-prob-denom]
Min-thresh:Is the minimum threshold in number of packets (from 1 to 4096)
Max-thresh: Is the maximum threshold in number of packets (from 1 to 4096)
Mark-prob-denom: Is the denominator that indicates the fraction of packets to be dropped when the average queue occupancy reaches max-thresh ( from 1 to 65536; default value is 10 which means 1 out of every 10 packets is dropped when queue reaches max-thresh).
In order to get the whole picture of this kind of configuration, let’s take a look at an example:
The schematic diagram below provides a graphical representation of the queue occupancy based on the above example configuration. It can be seen that packets with higher precedence value experience higher throughput than low precedence packets. (Click on graphic to enlarge)
Configuring Class-Based Precedence WRED
QoS policies are configured and traffic flows are classified based on IP precedence bits into different priority classes where each class is assigned with different WRED drop profiles. Moreover, bandwidth guarantees are configured per each traffic class.
For example Critical class traffic is guaranteed 30% of the queues bandwidth, Bulk class traffic is guaranteed 20% and the rest of the traffic (non contract traffic) is following the fair-queue discipline with the default WRED parameters. The latter are based on the output buffering capacity and transmission speed.
A sample configuration is presented below:
Configuring Class-Based DSCP WRED
Traffic classification is performed using DSCP codepoints or DSCP-based classes. Available options are presented below:
Let’s use an example to clarify how things operate:
It can be seen from the example provided that 30% of the queues bandwidth is reserved and is always available for the Critical class.
Packets marked with af23 are not dropped until queue depth reaches 60 packets. Packets marked with af22 have no chance of being discarded when the queue depth is less than 65 packets and finally packets marked with a DSCP of af21 are not supposed to be discarded until the queue depth reaches 70 packets. When the queue depth is exactly 100 packets, the probability of discarding packets of each DSCP is 5 %( 1/20).
- WRED can provide differentiated performance treatment for different traffic classes.
- IP precedence value and DSCP are used to prioritize traffic and WRED dropping probability is computed in relation to these fields for an ultimate purpose: better QoS level for higher-priority traffic.
- WRED mechanism is based on selective packet dropping at an early stage prior to congestion which could lead to complete packet dropping and global TCP synchronization.
- WRED is normally used at the core routers and has the ability to operate differently on incoming and outgoing queues of an interface.
- WRED serves the TCP-based traffic better than UDP-based traffic such as voice. UDP-based traffic does not respond to dropped packets, because UDP has no congestion avoidance mechanism like TCP. Moreover, dropping UDP packets is undesirable; for example, when voice is transported, because it would result in voice quality degradation.