inside the queuing system, thereby implementing
class-based WRED (CBWRED). Each class is queued in its separate
queue and has a queue limit, performing tail drop by default.
WRED can be configured as the preferred dropping method in a
queue, implementing a differentiated drop based on traffic
class or on the IP precedence or DSCP value. Note
The combination of CBWFQ and WRED on a single device is
currently the only way to implement the Differentiated Services
(DiffServ) Assured Forwarding (AF) per-hop behavior (PHB) using
Cisco IOS software. Figure summarizes these points concerning
WRED.
Content 4.6 Congestion Avoidance
4.6.5 WRED Drop Profiles A per hop behavior (PHB)
is the externally observable forwarding behavior applied at a
DiffServ-compliant node to a DiffServ behavior aggregate (BA).
With the ability of the system to mark packets according to
DSCP setting, collections of packets (each with the same DSCP
setting and sent in a particular direction) can be grouped into
a DiffServ BA. Packets from multiple sources or applications
can belong to the same DiffServ BA. The class selector BA is
used for backward compatibility with non-DiffServ-compliant
devices (RFC 1812-compliant devices and, optionally, RFC
791-compliant devices). Therefore, the class selector range of
DSCP values is used for backward compatibility with IP
precedence. Figure plots drop probability against average queue
size. Note that queues receive different drop treatments based
on the IP precedence class or DSCP value. DSCP-Based WRED
(Expedited Forwarding)
EF PHB is suggested for
applications that require a hard guarantee on the delay and
jitter. Typically, mission critical applications would require
this service and would be allocated a small percentage of the
total network capacity. In DSCP, the Expedited Forwarding (EF)
PHB is identified based on these parameters: - A low
departure rate is ensured to provide low delay to
delay-sensitive applications.
- Bandwidth is guaranteed
to prevent starvation of the application if there are multiple
applications using EF PHB.
- Bandwidth is policed to
prevent starvation of other applications or classes that are
not using this PHB.
- Packets requiring EF should be
marked with DSCP binary value 101110 (46).
For the
EF DiffServ traffic class, WRED configures itself by default so
that the minimum threshold is very high, increasing the
probability of no drops being applied to that traffic class. It
is expected that EF traffic will be dropped very late, compared
to other traffic classes, and the EF traffic is therefore
prioritized in the event of congestion. Figure is a drop
probability graph for DSCP-based WRED.
Content 4.6
Congestion Avoidance 4.6.6 Configuring
CBWRED The random-detect command is used to enable
WRED on an interface. By default, WRED is IP precedence-based
and uses eight default WRED profiles, one for each value of IP
precedence. Figure shows the command syntax. Within the CBWFQ
system, WRED is used to perform per-queue dropping within the
class queues. Therefore, each class queue has its own WRED
method, which can be further weighed based on the IP precedence
or DSCP value. Each queue can therefore be configured with a
separate drop policy to implement different drop policies for
every class of traffic. WRED treats all non-IP traffic as
precedence 0. As a result, non-IP traffic is more likely to be
dropped than IP traffic. WRED cannot be configured on the same
interface as custom queuing (CQ), priority queuing (PQ), or
WFQ. However, CBWRED can be configured in conjunction with
CBWFQ. Restricting nondistributed, non-class-based WRED to only
FIFO queuing on an interface is typically not a major issue
because WRED is usually applied in the network core, where
advanced queuing mechanisms are not typically used. WRED is
suited for the network core because WRED has a relatively low
performance impact on routers. Changing the WRED Traffic
Profile
When WRED is enabled, default values are
selected for each traffic profile based on the weight used (IP
precedence or DSCP). Network administrators can then modify
these default values to match their specific administrative
quality of service (QoS) policy goals. Figure shows the command
syntax for changing WRED traffic profiles. When you are
modifying the default WRED profile for IP precedence, the
following values are configurable: - Minimum
threshold: When the average queue depth is above the
minimum threshold, WRED starts dropping packets. The rate of
packet drop increases linearly as the average queue size
increases, until the average queue size reaches the maximum
threshold. The size of the hold queue is equivalent to the
number of packets that can be held within a queue. The
hold-queue length ranges from 0 to 4096, and, therefore, the
minimum/maximum threshold range is 1 to 4096.
-
Maximum threshold: When the average queue size is above
the maximum threshold, all packets are dropped. If the
difference between the maximum threshold and the minimum
threshold is too small, many packets might be dropped at once,
resulting in global synchronization. The default maximum
threshold will reflect the defined hold-queue size. Thus, if
the hold queue is changed, the maximum threshold will
change.
- Mark probability denominator: This is
the fraction of packets dropped when the average queue depth is
at the maximum threshold. For example, if the denominator is
10, one out of every 10 packets is dropped when the average
queue is at the maximum threshold. The maximum probability of
drop at the maximum threshold can be expressed as 1 /
mark-prob-denominator. The maximum drop probability is 10
percent if default settings are used that have a mark
probability denominator value of 10. The value of the mark
probability can range from 1 to 65,536.
If required,
RED can be configured as a special case of WRED, by assigning
the same profile to all eight IP precedence values. The default
WRED parameters are based on the best available data. It is
recommended that these parameters not be changed from their
default values unless you have determined that your
applications will benefit from the changed values. CBWFQ
Using IP Precedence with WRED: Example
The example in
Figure shows an IP precedence CBWRED deployment. This example
of CBWFQ with WRED focuses on a network that provides the
following three different service levels for three traffic
classes: - Mission-critical class: This class is
marked with IP precedence values 3 and 4 (3 is used for
high-drop service, and 4 is used for low-drop service within
the service class) and should get 30 percent of an interface
bandwidth.
- Bulk class: This class is marked
with IP precedence values 1 and 2 (1 is used for high-drop
service, and 2 is used for low-drop service) and should get 20
percent of the interface bandwidth.
- Best-effort
class: This class should get the remaining bandwidth share
and should be fair-queued.
To enforce this service
policy, a router uses CBWFQ to perform bandwidth sharing and
WRED within service classes to perform differentiated
dropping. Figure shows the WRED traffic profile representing
the QoS policy and the configuration that is used to implement
the example service policy. The traffic is classified based on
the IP precedence bits, and all noncontract traffic is
classified into the default class: - The
mission-critical class is guaranteed at least 30 percent of
bandwidth with a custom WRED profile that establishes a
low-drop and a high-drop PHB.
- The bulk class is
guaranteed at least 20 percent of bandwidth, is configured with
somewhat lower WRED drop thresholds, and is therefore more
likely to be dropped than the mission-critical class if
interface congestion occurs.
- All other traffic is
part of the default class and is fair-queued with default WRED
parameters.
Content 4.6 Congestion