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: 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: