Explicit Congestion Notification | Dropping Tools

Traditionally, the only way to inform sending hosts that there was congestion on the network and that the hosts should slow their transmission rates was by dropping TCP packets.

RFC 3168, however, defined a new and more efficient way that the network could communicate congestion to sending hosts, namely the “The Addition of Explicit Congestion Notification (ECN) to IP.” By marking the final two bits of the ToS byte of the IP header, devices can communicate to each other and to endpoints that they are experiencing congestion. These two bits have been defined as follows:

• ECN-capable Transport (ECT) bit: This bit indicates whether the device and the transport protocol supports ECN.
• Congestion Experienced (CE) bit: This bit (in conjunction with the ECT bit) indicates whether congestion was experienced en route.

Figure 1 shows the location of the ECN bits in the TOS byte of an IP packet header.

 
Figure 1: IP ToS byte ECN bits

During periods of congestion, WRED/DSCP-based WRED drops packets when the average queue length exceeds a specific threshold value. ECN is an extension to WRED, such that ECN marks packets, instead of dropping them, to communicate the existence of congestion when the average queue length exceeds a specific threshold value. Routers configured with the WRED ECN feature use this marking as a signal to application endpoints that the network is congested. This way, TCP transmission rates can be adjusted by the application endpoints without dropping packets, (or at least with dropping far fewer packets).

WRED ECN is enabled with the ecn keyword with the random-detect command. WRED ECN can be enabled by itself or in conjunction with WRED or DSCP-based WRED (as shown in Example 1).

Example 1: DSCP-Based WRED ECN Policy Example

---

Router(config)# policy-map WRED-ECN
Router(config-pmap)# class class-default
Router(config-pmap-c)# fair-queue
Router(config-pmap-c)# random-detect dscp-based
Router(config-pmap-c)# random-detect ecn

DSCP-Based WRED | Dropping Tools

As previously discussed, IP Precedence marking has been made obsolete by Differentiated Services, and as such, tools based on IPP, such as WRED, need to be modified accordingly. To achieve DiffServ compliance, the WRED algorithm can be optionally modified to operate based on the Assured Forwarding (AF) drop-preference values (as defined in RFC 2597) to influence its drop probability as queues fill. Such operation is referred to as DSCP-based WRED. Remember, the second digit of an AF codepoint indicates drop preference and can range from 1 (lowest drop preference) to 3 (highest drop preference). For example, if DSCP-based WRED is enabled on a queue servicing AF class 2 traffic, AF23 would be statistically dropped more often than AF22, which, in turn, would be statistically dropped more often than AF21. Figure 1 illustrates a simplified example of DSCP-based WRED for AF class 2.

 
Figure 1: DSCP-based WRED operation for AF class 2

DSCP-based WRED can be enabled on a CBWFQ—with or without a FQ pre-sorter—with the dscp-based keyword in conjunction with the random-detect command, as demonstrated in Example 1.

Example 1: Enabling DSCP-Based WRED on a CBWFQ

---

Router(config)# policy-map DSCP-WRED
Router(config-pmap)# class TCP
Router(config-pmap-c)# bandwidth percent 30
Router(config-pmap-c)# random-detect dscp-based
Router(config-pmap-c)# class UDP
Router(config-pmap-c)# bandwidth percent 20
Router(config-pmap-c)# class class-default
Router(config-pmap-c)# fair-queue
Router(config-pmap-c)# random-detect dscp-based

---

Additionally, DSCP-based WRED thresholds and mark probability denominators are tunable on a per-codepoint basis using the dscp keyword in conjunction with the random-detect command. In Example 2, the minimum threshold is set to begin dropping AF11-marked packets at 5 (meaning as soon as the queue depth reaches 5 packets, WRED randomly begins dropping AF11 packets). The maximum threshold for AF11 (at which all AF11-marked packets drop) is set to 20 packets. And the mark probability denominator is set to 8 (meaning that between these thresholds, up to 1 in 8 packets that are marked with AF11 drop).

Example 2: Tuned DSCP-Based WRED Example

---

Router(config)# policy-map TUNED-DSCP-WRED
Router(config-pmap)# class AF1
Router(config-pmap-c)# bandwidth percent 10
Router(config-pmap-c)# random-detect dscp-based
Router(config-pmap-c)# random-detect dscp af11 5 20 8

Weighted-RED (WRED) | Dropping Tools

WRED

WRED is an enhancement to RED that enables a degree of influence over the randomness of the selection of packets to be dropped. WRED factors the weight of the packet into the drop selection process; in Cisco IOS routers, the weight is based on the IP Precedence (IPP) value of the packet, whereas in Cisco Catalyst switches, the weight might be the CoS value of the packet (which is termed CoS-based WRED). To simplify the discussion, IP Precedence-based WRED is discussed, but the principles apply equally to CoS-based WRED.

Within the WRED algorithm, a minimum threshold for a given IPP value determines the queue depth at which packets of a given IPP value will begin to be randomly dropped. Themaximum threshold determines the queue depth at which all packets of a given IPP value will be dropped. These thresholds are configurable, as is the Mark Probability Denominator (MPD), which determines how aggressively the packets of a given IPP value will be dropped. (For example, a mark probability denominator value of 10 indicates that up to 1 in 10 packets of a certain precedence value will be randomly dropped.)

By default, WRED drops packets with lower IPP values sooner than packets with higher IPP values. Figure 1 provides a simplified illustration of WRED operation.

 
Figure 1: Weighted RED operation

WRED is enabled on a per-class basis with the random-detect command, as demonstrated in Example 1. As previously noted, WRED is dependent on queuing; therefore, before WRED can be enabled on a class of traffic, a CBWFQ queuing option, with or without a FQ pre-sorter, needs to be applied to the class. (WRED is not appropriate on the LLQ, which is intended for latency and drop-sensitive traffic.)

Example 1: Enabling WRED on a Per-Class Basis

---

Router(config)# policy-map WRED
Router(config-pmap)# class TCP
Router(config-pmap-c)# bandwidth percent 30
Router(config-pmap-c)# random-detect
Router(config-pmap-c)# class UDP
Router(config-pmap-c)# bandwidth percent 20
Router(config-pmap-c)# class class-default
Router(config-pmap-c)# fair-queue
Router(config-pmap-c)# random-detect

Dropping Tools | Network Quality of Service

Although generally dropping policies is not applicable for TelePresence flows, these do play an important part in the overall QoS policy design on TelePresence networks. Dropping tools are complementary to (and dependent on) queuing tools; specifically, queuing algorithms manage the front of a queue (that is, how a packet exits a queue), whereas congestion avoidance mechanisms manage the tail of a queue (that is, how a packet enters a queue).

Dropping tools, sometimes called congestion avoidance mechanisms, are designed to optimize TCP-based traffic. TCP has built-in flow control mechanisms that operate by increasing the transmission rates of traffic flows until packet loss occurs. At this point, TCP abruptly squelches the transmission rate and gradually begins to ramp the transmission rates higher again. Incidentally, this behavior makes a strong case against the statement that “QoS isn’t necessary; just throw more bandwidth at it.” Because if left unchecked, lengthy TCP sessions (as are typical with bulk data and scavenger applications) will consume any and all available bandwidth, simply due to the nature of TCP windowing.

When no congestion avoidance algorithms are enabled on an interface, the interface is said to tail drop. That is, after the queuing buffers have filled, all other packets are dropped as they arrive.

In a constricted channel, such as in a WAN or VPN, all the TCP connections eventually synchronize with each other as they compete for the channel. Without congestion avoidance mechanisms, they all ramp up together, lose packets together, and then back off together. This behavior is referred to as global synchronization. In effect, waves of TCP traffic flow through the network nodes, with packets overflowing the buffers at each wave peak and lulls in traffic between the waves.

Figure 1 illustrates TCP global synchronization behavior attributable to tail-dropping and the suboptimal effect this behavior has on bandwidth utilization.

 
Figure 1: TCP global synchronization

Random Early Detect (RED) counters the effects of TCP global synchronization by randomly dropping packets before the queues fill to capacity.

Instead of waiting for queuing buffers to fill before dropping packets, RED causes the router to monitor the buffer depth and perform early discards (drops) on random packets when the defined queue threshold has been exceed.

RED drops occur within the operational bounds of TCP retry timers, which slow the transmission rates of the sessions but prevent these from slow-starting. Thus RED optimizes network throughput of TCP sessions.

Because UDP does not have any retry logic, congestion avoidance techniques such as RED (and variants) do not optimize UDP-based traffic.

Note

Cisco IOS Software does not (directly) support Random Early Detect (RED), only Weighted-RED (WRED), discussed in the next section. However, if all packets assigned to a WRED-enabled queue have the same IP Precedence or DSCP markings, the effective policy is simply RED.