Tài liệu Congestion Avoidance pdf

Congestion Avoidance - 11RED Profile RED Profile Average Queue Size Drop Probability 10% 100% Minimum Threshold Maximum Threshold Maximum Drop Probability No drop Random drop Full drop T

Trang 1

Objectives

Upon completion of this module, you will be able to perform the following tasks:

n Describe Random Early Detection (RED)

n Describe and configure Weighted Random Early Detection (WRED)

n Describe and configure Flow-based WRED

Trang 2

5-2 Congestion Avoidance Copyright  2001, Cisco Systems, Inc

Random Early Detection

Overview

The section describes the need for congestion avoidance in nearly-congested networks and explains the benefits of using RED on congested links

Objectives

Upon completion of this lesson, you will be able to perform the following tasks:

n Explain the need for congestion avoidance mechanisms

n Explain how RED works and how it can prevent congestion

n Describe the benefits and drawbacks of RED

Trang 3

Router Interface Congestion

• Router interfaces congest when the output queue is full

– Additional incoming packets are dropped

– Dropped packets may cause significant application performance degradation

– By default, routers perform tail-drop

– Tail-drop has significant drawbacks

– WFQ, if configured, has a more intelligent dropping scheme

When an interface on a router cannot transmit a packet immediately, the packet is queued, either in an interface Tx ring, or the interface output hold queue, depending

on the switching path 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 router’s capability

to buffer and forward traffic, the queues increase to their maximum length and the interface becomes congested Tail drop is the router’s default queuing response to congestion 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 congestion is eliminated and the queue is no longer full

Congestion avoidance techniques monitor network traffic loads in an effort to anticipate and avoid congestion at common network bottleneck points Congestion avoidance is achieved through packet dropping using more complex techniques than simple tail-drop

As mentioned, tail drop is the default queuing response to congestion Tail drop treats all traffic equally and does not differentiate between classes of service Weighted fair queuing, if configured on an interface, has a more elaborate scheme for dropping traffic, as it is able to punish the most aggressive flows via its

Congestion Discard Threshold (CDT)-based dropping algorithm Unfortunately, WFQ does not scale to backbone speeds WFQ dropping is discussed in detail in its associated module

This module introduces Random Early Detection (RED) and its scalable dropping method, which is suitable for low and high-speed networks

Trang 4

Tail-drop Flaws

• Simple tail-drop has significant flaws

–TCP synchronization –TCP starvation

–High delay and jitter –No differentiated drop –Poor feedback to TCP

The simple tail-dropping scheme unfortunately does not work very well in environments with a large number of TCP flows or in environments in which selective dropping is deserved Understanding of the interaction between TCP stack intelligence and dropping in the network is required to implement a more efficient and fair dropping scheme, especially in SP environments

Tail drop has the following shortcomings:

n When congestion occurs, dropping affects most of the TCP sessions, which simultaneously back-off and then restart again This causes inefficient link utilization at the congestion point (TCP global synchronization)

n TCP starvation, where all buffers are temporarily seized by aggressive flows, and normal TCP flows experience buffer starvation

n Buffering at the point of congestion can introduce delay and jitter, as packets are stuck waiting in queues

n There is no differentiated drop mechanism, and therefore premium traffic is dropped in the same way as best-effort traffic

n Even in the event of a single TCP stream across an interface, the presence of other non-TCP traffic can congest the interface and TCP traffic will also be dropped In this scenario, the feedback to the TCP protocol is very poor and therefore it cannot adapt properly to a congested network

Trang 5

TCP Synchronization TCP Synchronization

• Multiple TCP sessions start at different times

• TCP window sizes are increased

• Tail-drops cause many packets of many sessions to be dropped at the same time

• TCP sessions restart at the same time (synchronized)

Flow A Flow B Flow C

Average link utilization

A router can handle multiple concurrent TCP sessions There is a high probability that when traffic exceeds the queue limit at all, it vastly exceeds the limit due to the bursty nature of packet networks However, there is also a high probability that excessive traffic depth caused by packet bursts is temporary and that traffic does not stay excessively deep except at points where traffic flows merge, or at edge routers

If the receiving router drops all traffic that exceeds the queue limit, as is done by default (with tail drop), many TCP sessions then simultaneously go into slow start Consequently, traffic temporarily slows down to the extreme and then all flows

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 utilized Global

synchronization of Transmission Control Protocol (TCP) hosts, for example, can occur because packets are dropped all at once Global synchronization manifests when multiple TCP hosts reduce their transmission rates in response to packet dropping, then increase their transmission rates once again when the congestion is reduced The most important point is that the waves of transmission known as global synchronization result in significant link under-utilization

Trang 6

TCP Starvation, Delay and Jitter TCP Starvation, Delay and Jitter

• Constant high buffer usage (long queue) causes delay

• More aggressive flows can cause other flows to starve

• Variable buffer usage causes jitter

• No differentiated dropping

Prec.

0 Prec.

Packets of aggressive flows

Prec.

3

Packets of starving flows

Delay Packets experience long delay if interface is constantly congested

Prec.

3 Prec.

3

TCP does not react well if multiple packets are dropped

Tail- drop does not look at IP precedence

Another TCP-related phenomenon, which reduces optimal throughput of network applications is TCP starvation When multiple flows are established over a router, some of these flows may be much more aggressive as compared to others For instance, when a file transfer application’s TCP transmit window increases, it can send a number of large packets to its destination The packets immediately fill the

queue on the router, and other, less aggressive flows can be starved, because they

are tail-dropped at the output interface

During periods of congestion, packets are queued up to the full queue length, which also causes increased delay for packets already in the queue In addition, queuing, being a probabilistic mechanism, introduces unequal delays for packets of the same flow, producing jitter

Trang 7

Conclusion

• Tail-drop should be avoided

• Tail-drop can be avoided if congestion is prevented

• Congestion can be prevented if TCP sessions (that still make up more than 80 percent of average Internet traffic) can be slowed down

• TCP sessions can be slowed down if some packets are occasionally dropped

• Therefore: packets should be dropped when interface is nearing congestion

Based on the knowledge of TCP behavior during periods of congestion, it can be concluded that 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, which would slow down traffic before actual congestion occurs

IP traffic can be “slowed down” only for traffic using an adaptive transmission protocol, such as TCP Dropping packets of a TCP session indicates to the sender that it should lower its transmission rate to adapt to changing network conditions UDP, on the other hand, has no built-in adaptive mechanisms – it sends packets out at a rate specified by the application About 80% of Internet traffic today is carried over the TCP protocol If TCP packets of aggressive flows are intelligently dropped, those sessions will slow down and congestion will be avoided

Therefore, to prevent congestion, the output queues should not be allowed to get full, and TCP can be controlled via packet dropping The new dropping

mechanisms should drop packets before congestion occurs, and drop them in such

a way that primarily influences aggressive traffic flows

Trang 8

Random Early Detection Random Early Detection

• Random Early Detection (RED) is a mechanism that randomly drops packets even before a queue is full

• RED drops packets with an increasing probability

-Random Early Detection is a dropping mechanism that randomly drops packets before a queue is full The dropping strategy is based primarily on the average queue length - that is, when the average queue gets longer (fuller), RED will be more likely to drop an incoming packet than when the queue is shorter

Because RED drops packets randomly, it has no per-flow intelligence The rationale behind this is that an aggressive flow will represent most of the arriving traffic, therefore it is more probable that RED will drop a packet of an aggressive session RED therefore punishes more aggressive sessions with higher statistical probability, and is therefore able to somewhat selectively slow down 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, the TCP global synchronization is much less likely to occur, and TCP can utilize the bandwidth more efficiently The average queue size also decreases significantly, as the possibility of the queue filling up is very small This is due to very aggressive dropping in the event of traffic bursts, when the queue is already quite full

RED distributes losses over time and maintains normally low queue depth while absorbing spikes RED can also utilize precedence/DSCP bits in packets to establish different drop profiles for different classes of traffic

Trang 9

RED Profile RED Profile

Average Queue Size

Drop Probability

10%

100%

Minimum Threshold

Maximum Threshold

Maximum Drop Probability

No drop Random drop Full drop

The probability of a packet being dropped is based on three configurable parameters:

n Minimum threshold - 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

n 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

n 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 512, one out of every 512 packets is dropped when the average queue is at the maximum threshold

These parameters define the RED profile, which implements the packet dropping strategy, based on the average queue length

Trang 10

RED Modes RED Modes

• RED has three modes:

– No drop – when the average queue size is between

0 and the minimum threshold

– Random drop - when the average queue size is between the minimum and the maximum threshold

– Full drop ( tail-drop ) – when the average queue size

is at maximum threshold or above

• Random drop should prevent congestion (prevent tail-drops)

As seen in the previous figure, RED has three dropping modes, based on the average queue size:

n When the average queue size is between 0 and the configured minimum threshold, no drops occur and all packets are queued

n When the average queue size is between the configured minimum threshold, and the configured maximum threshold, random drop occurs, which is linearly proportional to the average queue length The maximum probability of drop (when the queue is almost completely full) is 15% in Cisco IOS software

n When the average queue size is at or higher than the maximum threshold, RED performs full (tail) drop in the queue This event is unlikely, as RED should slow down TCP traffic ahead of congestion If a lot of non-TCP traffic is present, RED cannot effectively drop traffic to reduce congestion, and tail-drops are likely to occur

Trang 11

The figure shows TCP throughput behavior compared to link bandwidth in a scenario of congestion, and simple tail-dropping on a router The global synchronization phenomenon causes all sessions to slow down when congestion occurs, as all sessions are penalized when tail-drop is used because it drops packets with no discrimination between individual flows

When all sessions slow down, the interface becomes uncongested, and all TCP sessions restart their transmission at roughly the same time The interface quickly becomes congested again, causing tail-dropping, and all TCP sessions back off again This behavior cycles constantly, resulting in a link that is always

underutilized on the average

Trang 12

After RED After RED

• Average link utilization is much closer to link bandwidth

• Random drops cause TCP sessions to reduce window sizes

Flow A Flow B Flow C

The figure shows TCP throughput behavior compared to link bandwidth in a scenario of congestion, and RED configured on a router RED randomly drops packets, influencing a small number of sessions at a time, before the interface reaches congestion Overall throughput of sessions is increased, as well as average link utilization Global synchronization is very unlikely to occur, as there is selective, but random dropping of adaptive traffic

Trang 13

2 What does RED do to prevent TCP synchronization?

3 What are the three modes of RED?

Trang 14

Weighted Random Early Detection

Overview

The section describes the WRED mechanism available in Cisco IOS

Objectives

Upon completion of this lesson, you will be able to perform the following tasks:

n Describe the Weighted Random Early Detection (WRED) mechanism

n Configure WRED on Cisco routers

n Monitor and troubleshoot WRED on Cisco routers

Trang 15

Weighted Random Early

Detection

Weighted Random Early

Detection

• WRED uses a different RED profile for each weight

• Each profile is identified by:

– minimum threshold – maximum threshold – maximum drop probability

Weighted Random Early Detection (WRED) combines RED with IP Precedence

or DSCPs and does packet drops based on IP Precedence or DSCP markings

As with RED, WRED monitors the average queue depth in the router and determines when to begin packet drops based on the queue depth When the average queue depth crosses the user-specified “minimum threshold,” WRED begins to drop packets (both TCP and UDP) with a certain probability If the average queue depth ever crosses the user-specified ”maximum threshold,” then WRED reverts to ”tail drop,” where all incoming packets might be dropped The idea behind using WRED is to maintain the queue depth at a level somewhere between the minimum and maximum thresholds, and to implement different drop policies for different classes of traffic

WRED can selectively discard lower priority traffic when the interface becomes congested and provide differentiated performance characteristics for different classes of service WRED can also be configured so that non-weighted RED behavior is achieved

For interfaces configured to use the Resource Reservation Protocol (RSVP), WRED chooses packets from other flows to drop rather than the RSVP flows Also, IP Precedence or DSCPs govern which packets are dropped − traffic that is

at a lower priority has a higher drop rate and therefore is more likely to be throttled back

WRED reduces the chances of tail drop by selectively dropping packets when the output interface begins to show signs of congestion By dropping some packets early rather than waiting until the queue is full, WRED avoids dropping large numbers of packets at once and minimizes the chances of global synchronization Thus, WRED maximizes the utilization of transmission lines

Trang 16

In addition, WRED statistically drops more packets from large users than small ones Therefore, traffic sources that generate the most traffic are more likely to be slowed down than traffic sources that generate little traffic

WRED avoids the global synchronization problems that occur when tail drop is used as the congestion avoidance mechanism Global synchronization manifests when multiple TCP hosts simultaneously reduce their transmission rates in response to packet dropping, then increase their transmission rates again once the congestion is reduced

WRED is only useful 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 does not decrease congestion

WRED treats non-IP traffic as precedence 0, the lowest precedence Therefore, non-IP traffic, in general, is more likely to be dropped than IP traffic

WRED should be used wherever there is a potential bottleneck (congested link), which could very well be an access/edge link However, WRED is normally used

in the core routers of a network rather than at the network’s edge Edge routers assign IP Precedences to packets as they enter the network WRED uses these precedences to determine how to treat different types of traffic

Note that WRED is not recommended for any voice queue, although it may be enabled on an interface carrying voice traffic RED will not throttle back voice traffic, because it is UDP-based, and the network itself should not be designed to lose voice packets since lost voice packets result in reduced voice quality WRED controls congestion by impacting other prioritized traffic, and avoiding congestion helps to ensure voice quality

Trang 17

WRED Profiles WRED Profiles

• WRED profiles can be manually set

• WRED has 8 default value sets for IP precedence based WRED

• WRED has 64 default value sets for DSCP based WRED

of service in the event of congestion

To avoid the need of setting all WRED parameters in a router, 8 default values are already defined for precedence-based WRED, and 64 DiffServ-aligned values are defined for DSCP-based WRED Therefore, the default settings should suffice in the vast majority of deployments

Trang 18

IP Precedence and Class Selector

Profiles

IP Precedence and Class Selector

Profiles

In the Assured Forwarding PHB (as defined in RFC 2474,) WRED uses the Drop Preference (second digit of the AF number) to determine drop probability This enables differentiated dropping of AF traffic classes, which have different drop preference

Trang 19

DSCP-based WRED (Expedited Forwarding)

The Expedited Forwarding PHB is identified based on the following parameters:

n Ensures a minimum departure rate to provide the lowest possible delay to delay-sensitive applications

n Guarantees bandwidth to prevent starvation of the application if there are multiple applications using Expedited Forwarding PHB

n Polices bandwidth to prevent starvation of other applications or classes that are not using this PHB

n Packets requiring Expedited Forwarding should be marked with DSCP binary value “101110” (46 or 0x2E)

For the Expedited Forwarding 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 EF-traffic is therefore expected to be dropped very late, compared to other traffic classes, in the event of congestion

Trang 20

DSCP-based WRED (Assured Forwarding)

The Assured Forwarding PHB is identified based on the following parameters:

n Guarantees a certain amount of bandwidth to an AF class

n Allows access to extra bandwidth, if available

n Packets requiring AF PHB should be marked with DSCP value “aaadd0” where “aaa” is the number of the class and “dd” is the drop probability or drop preference of the traffic class

There are four standard-defined AF classes Each class should be treated independently and have bandwidth allocated based on the QoS policy

For the Assured Forwarding DiffServ traffic class, WRED configures itself by default for three different profiles, depending on the Drop Preference DSCP marking bits AF-traffic should therefore be classified into the three possible classes based on the application sensitivity to dropping WRED implements a congestion avoidance PHB in agreement with the initial classification

Trang 21

WRED Building Blocks WRED Building Blocks

Calculate Average Queue Size

FIFO Queue

Select WRED Profile

Current Queue Size

IP precedence or

DSCP

Min threshold Max threshold Max prob denom.

Queue Full?

No

Yes

Tail Drop Random Drop

The figure shows how WRED is implemented, and the parameters that influence WRED dropping decisions The WRED algorithm is constantly updated with the calculated average queue size, which is based on the recent history of queue sizes The configured WRED profiles define the dropping thresholds (and therefore the WRED probability slopes) When a packet arrives at the output queue, the IP precedence of DSCP-value is used to select the correct WRED profile for the packet The packet is then passed to WRED to perform a drop/enqueue decision Based on the profile and the average queue size, WRED calculates the probability for dropping the current packet and either drops it or passes it to the output queue

If the queue is already full, the packet is tail-dropped Otherwise, it is eventually transmitted out onto the interface

Trang 22

Configuring WRED and dWRED

random-detect random -detect Router(config-if)#

• Enables IP precedence based WRED

• Default service profile is used

• Non-distributed WRED cannot be combined with fancy queuing - FIFO queuing has to be used

• WRED can run distributed on VIP-based interfaces (dWRED)

• dWRED can be combined with dWFQ

The random-detect command is used to enable WRED on an interface By

default, WRED is precedence-based, using eight default WRED profiles

Used on VIP-based interfaces, this command enables distributed WRED (dWRED), where the VIP CPU performs WRED dropping This can significantly increase router performance, when used in the context of distributed CEF

switching, which is a prerequisite for dWRED functionality Also, dWRED can be combined with dWFQ, enabling truly distributed queuing and congestion avoidance techniques, running independently from the central CPU

With centralized platforms, WRED, if configured, cannot be combined with other queuing methods (priority, custom, and weighted-fair queuing) Those methods use either tail-dropping or their own dropping methods Therefore, WRED can only be configured with FIFO queuing on an interface This is not a major issue, because WRED is usually applied in the network core, where there should be no queuing configured WRED is suited for the network core as it has a relatively low performance impact on routers

Trang 23

Changing WRED profile Changing WRED profile

random-detect precedence precedence min-threshold max -threshold

mark-prob-denominator

random-detect precedence precedence min-threshold max-threshold

mark -prob -denominator

n Minimum threshold - 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

n 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

n 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 512, one out of every 512 packets is dropped when the average queue is at the maximum threshold

It is interesting to note, that the maximum probability of drop at the maximum threshold can be expressed as 1/mark-prob-denominator The maximum drop probability is 10%, if default settings are used

If required, RED can be configured as a special case of WRED, by assigning the same profile to all eight precedence values

Trang 24

n t

n avg

Router(config-if)#

• WRED takes the average queue size to determine the current WRED mode (no drop, random drop, full drop)

• High values of N allow short bursts

• Low values of N make WRED more burst-sensitive

• Default value (9) should be used in most scenarios

• Average output queue size with N=9 is

average t+1 = average t * 0.998 + queue_size t * 0.002

Current queue size Previous average

queue size New average

queue size

As mentioned previously, WRED does not calculate the drop probability using the current queue length, but rather uses the average queue length The average queue length is constantly recalculated, using two terms: the previously calculated

average queue size and the current queue size An exponential weighting constant

N influences the calculation by weighing the two terms, therefore influencing how the average queue size follows the current queue size, in the following way:

n A low value of N makes the current queue size more significant in the new average size calculation, therefore allowing larger bursts

n A high value of N makes the previous average queue size more significant in the new average seize calculation, so that bursts influence the new value to a smaller degree

The default value is 9 and should suffice for most scenarios, except perhaps those involving extremely high-speed interfaces (like OC12), where it can be increased slightly (to about 12) to allow more bursts

Trang 25

Configuring DSCP-based WRED

random-detect {prec-based | dscp-based}

• Selects WRED mode

• Precedence-based WRED is the default mode

• DSCP-based uses 64 profiles

The random-detect dscp-based command is used to enable DSCP-based

WRED on an interface, using the 64 default DSCP-based WRED profiles

Trang 26

Changing WRED Profile

random-detect dscp dscp min-threshold max -threshold mark

-prob-denominator

random-detect dscp dscp min-threshold max-threshold

mark-prob-denominator

• Changes RED profile for specified DSCP value

• Packet drop probability at maximum threshold is

1 / mark-prob-denominator

The DSCP-weighted WRED profiles can be changed, again using the known three

WRED parameters The mask-prob-denominator defines the packet drop

probability at the WRED maximum threshold The maximum drop probability is 10%, if default settings are used Normally, the DSCP-weighed profiles should be left at their default settings, as those settings are appropriate for most situations, if traffic is classified according to the DiffServ service specification

Tiêu đề	Congestion Avoidance
Trường học	Cisco Systems, Inc.
Chuyên ngành	Networking
Thể loại	Tài liệu
Năm xuất bản	2001
Thành phố	San Jose

Định dạng
Số trang	53
Dung lượng	2,42 MB