Queuing Strategies and Tools continued

The Magic of WRED Weighting
WRED looks at IP precedence or DSCP values to prioritize packets when the time comes to discard. You configure this via a traffic profile, which has a minimum threshold, a maximum threshold, and a MPD value. These profiles provide granular control over discarding, for example IPP 0 traffic can be discarded at a lower threshold than other traffic.

As with many IOS features, WRED has default profile settings assigned to DSCP values. Here's a chart of them:

DSCP    Min. Threshold   Max Threshold  MPD
AFx1             33                    40                      10
AFx2             28                    40                      10
AFx3             24                    40                      10
EF                 37                    40                      10

Since WRED uses the queue depth as a trigger for dropping traffic, you have to configure it for each queue. There are limits on which queuing mechanisms support WRED, though. They are physical interfaces with FIFO queuing, ATM VCs, and non-LLQ classes in a CBWFQ policy map. N.B.- when you configure WRED on a physical interface, all other queuing mechanisms are disabled and you'll have only one FIFO queue!

random-detect is the command to enable WRED. The default is to check IPP, so if you want to use DSCP you'll have to use the syntax random-detect dscp-based. If you want to change the default WRED values, the syntax for IPP or DSCP commands is as follows-


random-detect precedence IPP_value min-threshold max-threshold [mark-probability-denominator]
random-detect dscp DSCP_value min-threshold max-threshold [mark-probability-denominator]

One last odd note from the CCIE study book pertains to changing the rolling average of queue depth. If you feel the need to adjust the calculation, you can use the command random-detect exponential-weighting-constant EXPONENT. Changing this exponent value from default will affect drops because WRED doesn't base its decisions on the current queue length; WRED uses the average queue length to decide whether to drop packets. It appears that in most cases you'd be looking to shorten the time between calculating the average queue lengths.

Modified Deficit Round Robin (MDRR)
This was implemented only in the Cisco 12000 series because they didn't support CBWFQ or LLQ. It's expected that you'd only need to know the concepts of how MDRR works, so my discussion will be brief. MDRR configures 7 queues (0-6) which are serviced in round robin method. One additional queue is a priority queue.

If there are no packets in the PQ, each queue gets serviced in turn (once/cycle). If there are packets in the PQ, it will service them in one of two ways depending on configuration. Strict priority mode always services the PQ but will starve other traffic. Usually alternate mode is used for this reason. Alternate mode services the PQ in between each regular queue (PQ, queue1, PQ, queue2, etc.). You may still get jitter with this method but no starvation will occur.

MDRR also has two concepts you'll want to know: quantum value and deficit. These relate to MDRR scheduling. The quantum value is a number (in bytes) of data that will be transmitted from each queue. The deficit concept comes into play when a router pulls a packet from a queue that exceeds the quantum value. Since more bytes were sent than the quantum value "allows," the router tracks the extra data sent and subtracts that number from the quantum value when it next services that queue. Over time, this guarantees that each queue will get its configured percentage of the bandwidth.