Flow-Based WRED (FRED)

Flow-Based WRED (FRED) 457

Keep in mind that FRED specifically wants to defeat the UDP flows that consume too many queue entries. FRED still drops some packets from UDP flows when congestion occurs, based on normal WRED logic. For UDP flows, FRED simply decides which flows are taking too much of the queue, classifies these flows as nonadaptive, and discards packets in those flows more aggressively. For other UDP flows that FRED believes are not sending too many packets (fragile flows) FRED discards their packets less frequently.

NOTE UDP does not adapt to packet loss, so by definition, all UDP flows are nonadaptive. However, FRED uses the term “nonadaptive” to categorize those flows that are currently using too much of the queue.

The key to understanding how FRED works is to understand how FRED determines whether a particular UDP flow is fragile or nonadaptive. A couple of simple examples make the logic much more obvious. First, suppose FRED is enabled on a router’s S0/0 interface, and the interface FIFO output queue has 40 queue entries maximum. At a particular point in time, 10 flows exist, called Flow 1, Flow 2, and so on. (Keep in mind that FRED only supports FIFO Queuing.) With a maximum queue depth of 40, and 10 flows, you can think of each flow’s fair share of the queue space to be 40/10, or 4, in this case. FRED multiplies this fair share by a scaling factor, which defaults to 4. The scaling factor is used so that each flow has some capability to burst. This final number, 16 in this case, is the dividing line between fragile flows and nonadaptive flows.

Suppose, for instance, that Flow 1 and Flow 2 both use UDP. Flow 1 has 3 packets in the FIFO output queue, and Flow 2 has 20 packets in the queue. At first glance, it seems that Flow 2 should be considered a nonadaptive flow, because it has many packets in the queue. The calculated value of 4 * 40/10 (scaling factor * maximum queue length/number of flows), or 16, is greater than the number of packets in the queue that are part of Flow 1 (3 packets in the queue).

458 Chapter 6: Congestion Avoidance Through Drop Policies

Therefore, FRED considers Flow 1 to be a fragile flow. Similarly, the calculated value of 16 is smaller than the number of packets in the queue that are part of Flow 2 (20 packets in the queue), so FRED considers Flow 2 to be nonadaptive.

The first example hides one subtlety in how FRED decides which UDP flows are fragile, and which are nonadaptive. Consider the same example, but suppose now that only five flows exist. The formula works out to be 4 * 40/5 = 32. (Notice that the only part of the formula that changes over time is the number of flows; the scaling factor remains static, as does the maximum queue length.) As the number of flows decreases, the threshold that determines whether a flow is nonadaptive increases. If Flow 2 still has 20 packets in the queue, Flow 2 would now be considered to be a fragile flow, with packets discarded less aggressively.

After FRED decides which flows are robust, fragile, and nonadaptive, FRED can apply WREDlike logic to decide whether to discard any packets at all, and if so, what percentage of the packets. Frankly, the published details on how FRED determines the flows are sketchy at best. For you QoS exam takers, the following details about how FRED discards packets for the three types of flows is unlikely to be covered, because the coverage in the corresponding courses is also sketchy, or not even mentioned.

For robust and fragile flows, FRED acts just like WRED in terms of packet discard. FRED still uses the per-precedence or per-DSCP minimum threshold, maximum threshold, and MPD to determine when to discard packets, and how many. You can override the default values for each precedence or DSCP value through configuration, just like with WRED.

For nonadaptive flows, FRED lowers the maximum threshold. By doing so, FRED increases the packet discard rate more quickly. More importantly, lowering the maximum threshold for packets in the flow causes FRED to discard all packets for these nonadaptive flows more quickly than for fragile and robust flows, essentially preventing these flows from consuming the entire queue.

To get a full sense of what happens to nonadaptive flows, consider the following example. For nonadaptive flows, FRED reduces the maximum threshold used for the flow by half of the difference between the maximum and minimum thresholds. FRED and WRED use defaults for precedence 0 as follows: minimum threshold 20, maximum threshold 40, drop percentage 10 percent (MPD=10). FRED reduces the maximum threshold for a precedence 0 nonadaptive flow to 30, because the difference between the maximum and minimum is 20, and half of that is 10. By reducing the maximum threshold by half of the difference between the minimum and maximum, FRED increases the packet discard rate more quickly as the average queue depth nears 30. Most importantly, FRED discards all packets for these nonadaptive precedence 0 flows when the average queue depth reaches 30, preventing these flows from taking over the entire queue.

Table 6-10 lists the terms used by FRED to describe these processes.

462 Chapter 6: Congestion Avoidance Through Drop Policies

Example 6-4 FRED Example Using All Default Values, R3 S0/0 (Continued)

policy-map laundry-list class voip-rtp

set ip dscp ef class http-impo

set ip dscp af21 class http-not

set ip dscp af23 class class-default set ip dscp default

!

call rsvp-sync

!

interface Ethernet0/0

description connected to SW2, where Server1 is connected ip address 192.168.3.253 255.255.255.0

ip nbar protocol-discovery half-duplex

service-policy input laundry-list

!

interface Serial0/0

description connected to FRS port S0. Single PVC to R1. no ip address

encapsulation frame-relay load-interval 30 random-detect random-detect flow clockrate 128000

!

interface Serial0/0.1 point-to-point

description point-point subint global DLCI 103, connected via PVC to DLCI 101 ( R1)

ip address 192.168.2.253 255.255.255.0 frame-relay interface-dlci 101

!

!

! Some lines omitted for brevity

!

464 Chapter 6: Congestion Avoidance Through Drop Policies

Example 6-5 DSCP-Based FRED on R3 S0/0 (Continued)

The configuration begins with a change from precedence-based FRED to DSCP-based FRED using the random-detect dscp-based interface subcommand. (The configuration already contained the random-detect flow command to enable flow-based WRED.) Two FRED options can be set with the random-detect flow command, as seen in the example. The average depth factor defines the multiple of the average queue space per flow that can be allocated to a single

Flow-Based WRED (FRED) 465

flow before FRED decides to start discarding packets. (Formula: average depth factor * maximum queue depth / number of active flows) The flow count, set to 64 in this example, just sets the maximum number of unique flows tracked by FRED. Just like with WFQ, the setting of the number of flows must be set to a power of 2.

Just like with DSCP-based WRED, the command output for DSCP-based FRED does not differ from the earlier precedence-based FRED example in too many ways. The changes to the default values have been highlighted in the example. The show queueing command contains the only notable difference between the command outputs in the first two examples, now listing information about all the DSCP values recommended in the DSCP RFCs. Notice that the counters point out drops for both AF21 and AF23, which were previously both treated as precedence 2 by precedence-based FRED. Also note that FRED has discarded some voice traffic (DSCP EF) in this example. Because FRED operates on all traffic in the interface FIFO queue, it cannot avoid the possibility of discarding voice traffic.

Table 6-13 summarizes many of the key concepts when comparing WRED and FRED.

Table 6-13 WRED Versus FRED