Quality of Service — Part II

In this article, we’ll look at the following topics:

  • IP Precedence bits
  • Random Early Detection (RED)
  • Committed Access Rate (CAR)
  • Some Cisco QoS Links

The IP Precedence bits allow us to specify what traffic gets what Class of Service. RED lets us selectively drop TCP packets to throttle the sender, providing better goodput. And CAR is input-side traffic admission control, allowing us to police inbound traffic.

IP Precedence Bits


Part of the new IP QoS tool kit in routers and switches is the IP Precedence bits. Devices at the edge of the network may classify traffic as deserving a certain Class of Service using these bits. Core devices can then use the bits to provide differing types of service to different flavors of traffic.

The IP Precedence bits are the first 3 bits of the IP header Type of Service (TOS) field. They are followed by 4 TOS bits and an unused bit. The Cisco documentation relating to QoS seems to sometimes be a bit sloppy as to precedence versus TOS bits, sometimes using TOS to refer to the TOS field in a rather general way. The IETF Diff-Serv group is looking at using the Precedence bits for ISP/carrier purposes, so it is not safe to assume these bits will make it through your service provider unscathed — they may well change the bits for their own purposes.

Cisco keyword values for precedence: critical, flash, flash-override, immediate, internet, network, priority, routine. One assumes these correspond respectively to numeric values 7 down to 0. The keywords may be found in the descriptions of the IP extended access list variants.

TOS keyword values: max-reliability, max-throughput, min-delay, min-monetary-cost, normal. TOS is not in much use today. It is up to an application to ask for the Type of Service it needs. The standing joke is that by default IP traffic is unreliable, slow, and costly, since none of the relevant TOS bits is usually turned on. Even were applications to use these bits, no-one that I know of is using them to provided differentiated service, although the IP extended access lists in the Cisco IOS do allow you to do so if you wish. This is perhaps somewhat of a chicken-and-egg problem: no reason to use TOS to provide better service if there are no customers, and no reason for applications to set the bits if it isn’t going to make a difference.

Random Early Detection (RED)


About Random Early Detection (RED)

Random Early Detection (RED) is a high-speed congestion avoidance mechanism. It is not intended as a congestion management mechanism, the way the queuing techniques (PQ, CQ, WFQ) are. It is also more appropriate for long-haul trunks with many traffic flows, e.g. trans-oceanic links, rather than campus networks.

When enabled, RED responds to congestion by dropping packets at the selected rate. This is recommended only for TCP/IP networks with mostly TCP traffic. The drops are intended to cause TCP to back off its transmission rate.

TCP normally adapts its transmission rate to the rate the network can support. Each TCP flow repeats a cycle of ramping up to approximately the available bandwidth, then slowing to either near zero or near half the bandwidth, depending on the implementation. Thus a typical TCP flow may average between 1/2 and 3/4 of the available bandwidth, in the absence of any other traffic.

Multiple TCP flows tend to become synchronized, speeding up and slowing down in synchronization. This behavior is sometimes called “porpoising”, because the flows surface and dive in unison, like a pod of porpoises. When congestion occurs, all TCP sessions normally get slowed down simultaneously, resulting in periods where link capacity is underutilized. By randomly slowing one TCP session, the others benefit, resulting in better goodput.

Note that dropping packets does not work with most other protocols, including AppleTalk and Novell.

When RSVP is also configured, packets from other flows are dropped before those from RSVP flows, when possible. We’ll look at RSVP in a later article.

Weighted RED (WRED) allows you to specify a RED policy in combination with IP precedence, so that different types of packets are dropped at different rates and levels of congestion. You can set it so precedence is ignored, or you can set it so that lower precedence packets are more likely to be dropped. WRED is an IOS 11.1 CC or 12.0 feature.

Distributed Weighted RED (DWRED) is available in IOS 12.0 for hardware that supports it. The Distributed WRED (DWRED) feature uses the VIP rather than the RSP to perform the queuing. It requires a Cisco 7500 series router or Cisco 7000 series router with RSP.


Configuring Random Early Detection (RED)


The default is for RED to be disabled on an interface. RED is only useful on interfaces where most of the traffic is TCP. Random early detection cannot be configured on an interface already configured with custom, priority, or fair queueing. To enable RED on an interface, configure:

Here constant is a number in the range 1 to 16 used to determine the rate that packets are dropped when
congestion occurs. The default is 10. The number is an exponent used in the exponential decay rate for the weighted queue size calculation used in RED. It is suggested that you change the default with caution. A big value means the queue size measurement changes slowly, making RED less responsive. The formula used for tracking queue size is:

where n is the exponential weighting constant.

To configure WRED on an interface, configure:

In this command, precedence refers to IP precedence, number 0 to 7. And min-thresh is the minimum threshold in number of packets, from 1 to 4096. When the average queue length reaches this number, RED begins to drop packets with the specified IP precedence. The number max-thresh is the maximum threshold in number of packets, from 1 to 4096. When the average queue length exceeds this number, WRED drops all packets with the specified IP precedence. Finally, mark-prob-denom is the denominator for the fraction of packets dropped when the average queue depth is max-threshold, in the range 1 to 65536. If the denominator is 512, one out of every 512 packets is dropped when the average queue is at the max-threshold. The value is from 1 to 65536. The default is 10.

The per-precedence min-threshold defaults are 9/18, 10/18, … 16/18 of the max-threshold size, for precedences 0 through 7 respectively. The max-threshold is determined based on interface speed and output buffering capacity.

Relevant EXEC Commands

Sample Configuration

RED configuration


WRED configuration



Committed Access Rate (CAR)


About Committed Access Rate (CAR)

Committed Access Rate (CAR) has two functions:

  • Packet Classification, using IP Precedence and QoS group setting
  • Access Bandwidth Management, through rate limiting

So CAR is basically the input side of Traffic Shaping (which we’ve talked about somewhat in a prior Frame Relay article).

Traffic is sequentially classified using pattern matching specifications, just like access lists, on a first-match basis. The pattern matched specifies what action policy rule to use, based on whether the traffic conforms. That is, if traffic is within the specified rate, it conforms, and is treated one way. Non-conforming (excess) traffic can be treated differently, usually either by giving it lower priority or by dropping it. If no rule is matched, the default is to transmit the packet. This allows you to use rules to rate limit some traffic, and allow the rest to be transmitted without any rate controls.

The possible action policy rules:

  • transmit
  • drop
  • continue (go to next rate-limit rule on the list)
  • set IP Precedence bits and transmit
  • set IP Precedence bits and continue
  • set QoS group and transmit
  • set QoS group and continue

IP Precedence uses the 3 bit precedence field in the IP header. This gives up to 6 Classes of Service (CoS): 0-5 can be used, but 6 and 7 are reserved per RFC791.

QoS group is an identifier within the router only. It can be set by CAR or by QPPB (see elsewhere). The QoS group is a number in the range 0 to 99, with 0 the default for unassigned packets (and not usable in assignments of QoS group).

The configurable parameters include:

  • committed rate (bits/second) — in increments of 8 Kbps
  • normal burst size (bytes) — how many bytes are handled in a burst above the committed rate limit without a penalty
  • extended burst size (bytes) — number of bytes in an extended burst — beyond this, packets are dropped

For traffic falling between normal and extended burst sizes, selected packets are dropped using a RED-like managed drop policy. (See RED, elsewhere).

Configuring Committed Access Rate (CAR)

It’s mostly one long command, repeated over and over with various rule specifications:


The arguments bpsnormal-burstextended-burst are as noted prior to this section (committed rate in bps and burst sizes in bytes).

Traffic matches can be specified using access-lists:

where acl-index is the access list number: from 1 to 99 classifies packets by precedence or precedence mask, from 100 to 199 classifies by MAC address.

And mask prec-mask is the IP precedence mask; a two-digit hexadecimal number. This is used to assign multiple precedences to the same rate-limit access list. (Precedences map to bits: precedence 0 is the 1 bit, precedence 1 the 2 bit, etc.).

Relevant EXEC Commands

Sample Configuration

Here’s a simple sample:

And a more complex one: