## Random Early Detection RED

Random Early Detection (RED) reduces the congestion in queues by dropping packets so that some of the TCP connections temporarily send fewer packets into the network. Instead of waiting until a queue fills, causing a large number of tail drops, RED purposefully drops a percentage of packets before a queue fills. This action attempts to make the computers sending the traffic reduce the offered load that is sent into the network.

The name "Random Early Detection" itself describes the overall operation of the algorithm. RED randomly picks the packets that are dropped after the decision to drop some packets has been made. RED detects queue congestion early, before the queue actually fills, thereby avoiding tail drops and synchronization. In short, RED discards some randomly picked packets early, before congestion gets really bad and the queue fills.

NOTE IOS supports two RED-based tools: Weighted RED (WRED) and Flow-Based WRED (FRED). RED itself is not supported in IOS.

RED logic contains two main parts. RED must first detect when congestion occurs; in other words, RED must choose under what conditions it should discard packets. When RED decides to discard packets, it must decide how many to discard.

First, RED measures the average queue depth of the queue in question. RED calculates the average depth, and then decides whether congestion is occurring based on the average depth. RED uses the average depth, and not the actual queue depth, because the actual queue depth will most likely change much more quickly than the average depth. Because RED wants to avoid the effects of synchronization, it needs to act in a balanced fashion, not a jerky, sporadic fashion. Figure 6-5 shows a graph of the actual queue depth for a particular queue, compared with the average queue depth.

As seen in the graph, the calculated average queue depth changes more slowly than does the actual queue depth. RED uses the following algorithm when calculating the average queue depth:

New average = (Old_average * (1 - 2-n)) + (Current_Q_depth * 2-n)

For you test takers out there, do not worry about memorizing the formula, but focus on the idea. WRED uses this algorithm, with a default for n of 9. This makes the equation read as follows:

New average = (Old_average * .998) + (Current_Q_depth * .002)

Figure 6-5 Graph of Actual Queue Depth Versus Average Queue Depth

Figure 6-5 Graph of Actual Queue Depth Versus Average Queue Depth

In other words, the current queue depth only accounts for .2 percent of the new average each time it is calculated. Therefore, the average changes slowly, which helps RED prevent over-reaction to changes in the queue depth. When configuring WRED and FRED, you can change the value of n in this formula by setting the exponential weighting constant parameter. By making the exponential weighting constant smaller, you make the average change more quickly; by making it larger, the average changes more slowly.

RED decides whether to discard packets by comparing the average queue depth to two thresholds, called the minimum threshold and maximum threshold. Table 6-2 describes the overall logic of when RED discards packets, as illustrated in Figure 6-6.

Table 6-2 Three Categories of When RED Will Discard Packets and How Many

 Average Queue Depth Versus Thresholds Action Average < minimum threshold No packets dropped. Minimum threshold < average depth < maximum threshold A percentage of packets dropped. Drop percentage increases from 0 to a maximum percent as the average depth moves from the minimum threshold to the maximum. Average depth > maximum threshold All new packets discarded similar to tail dropping.

As seen in Table 6-2 and Figure 6-6, RED does not discard packets when the average queue depth falls below the minimum threshold. When the average depth rises above the maximum threshold, RED discards all packets. In between the two thresholds, however, RED discards a percentage of packets, with the percentage growing linearly as the average queue depth grows. The core concept behind RED becomes more obvious if you notice that the maximum percentage of packets discarded is still much less than discarding all packets. Once again, RED wants to discard some packets, but not all packets. As congestion increases, RED discards a higher percentage of packets. Eventually, the congestion can increase to the point that RED discards all packets.

Figure 6-6 RED Discarding Logic Using Average Depth, Minimum Threshold, and Maximum Threshold

You can set the maximum percentage of packets discarded by WRED by setting the mark probability denominator (MPD) setting in IOS. IOS calculates the maximum percentage using the formula 1/MPD. For instance, an MPD of 10 yields a calculated value of 1/10, meaning the maximum discard rate is 10 percent.

Table 6-3 summarizes some of the key terms related to RED.

Table 6-3 RED Terminology

Table 6-3 summarizes some of the key terms related to RED.

Table 6-3 RED Terminology

 Term Meaning Actual queue depth The actual number of packets in a queue at a particular point in time. Average queue depth Calculated measurement based on the actual queue depth and the previous average. Designed to adjust slowly to the rapid changes of the actual queue depth. Minimum threshold Compares this setting to the average queue depth to decide whether packets should be discarded. No packets are discarded if the average queue depth falls below this minimum threshold. Maximum threshold Compares this setting to the average queue depth to decide whether packets should be discarded. All packets are discarded if the average queue depth falls above this maximum threshold.
 Term Meaning Mark probability denominator Used to calculate the maximum percentage of packets discarded when the average queue depth falls between the minimum and maximum thresholds. Exponential weighting constant Used to calculate the rate at which the average queue depth changes as compared with the current queue depth. The larger the number, the slower the change in the average queue depth.

The next two sections in this chapter cover WRED and FRED, including their respective configurations, as well as comparing RED, WRED, and FRED.

Weighted RED (WRED)

WRED behaves almost identically to RED, as described in the preceding section of this chapter. It calculates the average queue depth, and decides whether to discard packets, and what percentage of packets to discard, based on all the same variables as RED. The only real difference between the two is that WRED weights its behavior based on the IP precedence or IP differentiated services code point (DSCP) values of packets.

The other major concept that needs to be covered, before diving into WRED configuration, relates to where WRED can be enabled, and how it interoperates with queuing tools. Interestingly, although WRED can be enabled on an interface, it cannot be concurrently enabled along with any other queuing tool! When using Modular QoS command-line interface (MQC) to configure queuing, however, WRED can be used for individual class queues.

The following sections cover the following:

• How WRED weights packets

• When WRED can be enabled

• When WRED can be enabled to work with other queuing tools

• WRED configuration