Class of traffic being displayed. Output is
displayed for each configured class in the policy. offered
rate Rate, in kilobits per second, of packets entering the
class. drop rate Rate, in kilobits per second, at which packets
are dropped from the class. The drop rate is calculated by
subtracting the number of successfully transmitted packets from
the offered rate. Match Match criteria specified for the class
of traffic. pkts matched/bytes matched Number of packets (shown
in bytes) matching this class that were placed in the queue.
depth/total drops/no-buffer drops Number of packets, in bytes,
discarded for this class. “No-buffer” indicates that no memory
buffer exists to service the packet.
Content 4.6
Congestion Avoidance 4.6.1 Managing
Interface Congestion with Tail Drop When an interface on a
router cannot transmit a packet immediately, the packet is
queued, either in an interface transmit (Tx) ring or the
interface output hold queue, depending on the switching path
that is used. Packets are then taken out of the queue and
eventually transmitted on the interface. If the arrival rate of
packets to the output interface exceeds the ability of the
router to buffer and forward traffic, the queues increase to
their maximum length and the interface becomes congested. Tail
drop is the default queuing response to congestion. Tail drop
treats all traffic equally and does not differentiate among
classes of service. Figure shows tail drop occurring by
default. Applications may suffer performance degradation
stemming from packet loss caused by tail drop. When the output
queue is full and tail drop is in effect, all packets trying to
enter (at the tail of) the queue are dropped until the queue is
no longer full. Weighted fair queuing (WFQ), if configured on
an interface, provides a more sophisticated scheme for dropping
traffic. WFQ punishes the most aggressive flows using a
congestive discard threshold (CDT)-based dropping algorithm.
Content 4.6 Congestion Avoidance
4.6.2 Tail Drop Limitations The simple tail-drop
scheme does not work very well in environments with a large
number of TCP flows or in environments in which selective
dropping is required. Understanding the network interaction
between TCP stack intelligence and dropping is required to
implement a more efficient and fair dropping scheme, especially
in service provider environments. Tail drop has the following
shortcomings: - Normally, when congestion occurs,
dropping affects most of the TCP sessions, which simultaneously
back off and then restart again. This process causes
inefficient link utilization at the congestion point (TCP
global synchronization). To avoid dropping of TCP packets, TCP
reduces the window size.
- TCP starvation occurs, in
which all buffers are temporarily seized by aggressive flows,
and normal TCP flows experience buffer starvation.
-
There is no differentiated drop mechanism, and therefore
higher-priority traffic is dropped in the same way as
best-effort traffic.
Figure summarizes these
points. TCP Synchronization
A router can handle
multiple concurrent TCP sessions. However, bursty network
traffic could cause a router to fail if the traffic exceeds the
queue limit. Figure illustrates the issue of TCP
synchronization. If the receiving router drops all traffic that
exceeds the queue limit (the default tail drop action), many
TCP sessions then simultaneously go into slow start. Traffic
temporarily slows down to highly diminished levels, and then
all flows go into slow start again. This activity creates a
condition called global synchronization. Global synchronization
occurs as waves of congestion crest, only to be followed by
troughs during which the transmission link is not fully used.
Global synchronization of TCP hosts can occur because packets
are dropped all at once. Global synchronization occurs when
multiple TCP hosts reduce their transmission rates in response
to packet dropping. When congestion is reduced, their
transmission rates are increased. TCP Delay, Jitter, and
Starvation
Congestion is another name for tail loss.
Queues fill during periods of congestion. When the output queue
is full, tail drop drops packets to eliminate the congestion.
This causes delay. In addition, queuing introduces unequal
delays for packets of the same flow, resulting in jitter.
Figure illustrates these problems. Another TCP-related
phenomenon that reduces optimal throughput of network
applications is TCP starvation. When multiple flows are being
transmitted through a router, some of these flows may be much
more aggressive than other flows. For instance, when the TCP
transmit window increases for file-transfer applications, the
TCP session can send a number of large packets to its
destination. These packets immediately fill the queue on the
router, and other, less aggressive flows can be starved because
there is no differentiated treatment indicating which packets
should be dropped. As a result, less aggressive flows are
dropped at the output interface. Tail drop is not the optimal
mechanism for congestion avoidance and therefore should not be
used. Instead, more intelligent congestion avoidance mechanisms
should be used that are capable of slowing traffic before
congestion occurs.
Content 4.6 Congestion
Avoidance 4.6.3 Using Random Early
Detection Random early detection (RED) is a dropping
mechanism that randomly drops packets before a queue is full.
The basis of the dropping strategy is the average queue
length—that is, when the average size of the queue increases,
RED is more likely to drop an incoming packet than when the
average queue length is shorter. Because RED drops packets
randomly, it has no per-flow intelligence. The rationale is
that an aggressive flow will represent most of the arriving
traffic, and it is likely that RED will drop a packet of an
aggressive session. RED therefore punishes more aggressive
sessions with a higher statistical probability and is able to
somewhat selectively slow the most significant cause of
congestion. Directing one TCP session at a time to slow down
allows for full utilization of the bandwidth rather than
utilization that manifests itself as crests and troughs of
traffic. As a result of implementing RED, TCP global
synchronization is much less likely to occur, and TCP can use
link bandwidth more efficiently. In RED implementations, the
average queue size also decreases significantly because the
possibility of the queue filling up is reduced. This is because
RED is very aggressive in tail dropping when traffic bursts
occur and the queue is already quite full. RED distributes
losses over time and normally maintains a low queue depth while
absorbing traffic spikes. RED can also utilize IP precedence or
differentiated services code point (DSCP) bits in packets to
establish different drop profiles for different classes of
traffic. RED is useful only when the bulk of the traffic is
TCP traffic. With TCP, dropped packets indicate congestion, so
the packet source reduces its transmission rate. With other
protocols, packet sources might not respond or might re-send
dropped packets at the same rate, and so dropping packets might
not decrease congestion. Figure describes RED. RED Drop
Profiles
RED uses the traffic profile to determine the
packet-dropping strategy based on the average queue length. The
packet drop probability is based on the minimum threshold,
maximum threshold, and mark probability denominator. When the
average queue depth is above the minimum threshold, RED 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. Figure illustrates the RED drop
profile. The figure shows that depending on queue length, the
profile assigns a no drop, a random drop or full drop
probability. The probability of a packet being dropped is based
on three configurable parameters contained within the RED
profile: - Minimum threshold: When the average