Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Congestion Avoidance

Download as pdf or txt
Download as pdf or txt
You are on page 1of 23

Избегнување на задушување

Congestion avoidance
Behavior of a TCP Sender
• Sender sends “N” bytes (as
much as credit allows)
• Start credit (window size) is
small
– To avoid overloading network
queues
• Increases credit exponentially
– To gauge network capability
Behavior of a TCP Receiver
• Receiver schedules an ACK on
receipt of “next message.”
• TCP acknowledges the next
segment it expects to receive,
not the last segment it
received.
– In the example, N+1 is blocked,
so the receiver keeps
acknowledging N+1 (the next
segment it expects to receive).
TCP Slow Start
• If ACK acknowledges
something
– Updates credit and sends
• If not, presumes it
indicates a lost packet
– Sends first
unacknowledged message
right away
– Halves current credit
(slows down)
– Increases slowly to gauge
network throughput
Multiple Drops in TCP
• If multiple drops occur in the
same session:
– Current TCPs wait for time-out
– Selective acknowledge may be
a workaround
– New “fast retransmit” phase
takes several round-trip times
to recover
Managing Interface Congestion
with Tail Drop

• Router interfaces experience congestion when the


output queue is full:
– Additional incoming packets are tail-dropped
– Dropped packets may cause significant application
performance degradation
– Tail drop has significant drawbacks
Tail Drop Limitations
• Tail drop should be avoided because it contains
significant flaws:
– TCP synchronization (dropping affects most of the TCP
sessions, which simultaneously bask off and then
restart again)
– TCP starvation (normal TCP flow starves because of
aggressive flows)
– No differentiated drop (no difference between
premium and best-effort traffic)
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).
TCP Delay, Jitter and Starvation

• Constant high buffer usage (long queue) causes


delay.
• More aggressive flows can cause other flows to
starve.
• No differentiated dropping occurs.
Summary
• TCP sender sends as many bytes as credit allows. TCP
receiver acknowledges the next segment it expects
to receive.
• TCP uses windowing and the TCP slow-start
mechanism as its means of controlling congestion.
• By default, routers resort to tail drop, relying on TCP
congestion controls when queues become full.
• Tail drop causes significant issues including TCP
synchronization, starvation, and delay. TCP
synchronization decreases the average utilization of
network links.
Random Early Detection
• Tail drop can be avoided if congestion is prevented.
• RED is a mechanism that randomly drops packets
before a queue is full.
• RED increases drop rate as the average queue size
increases.
• RED result:
– TCP sessions slow down to the approximate rate of
output-link bandwidth.
– Average queue size is small (much less than the maximum
queue size).
– TCP sessions are desynchronized by random drops.
RED Profiles
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)
Summary
• RED is a mechanism that randomly drops packets
before a queue is full, preventing congestion and
avoiding tail drop.
• RED operates by increasing the rate at which packets
are dropped from queues as the average queue size
increases.
• RED has three modes of operation: no drop, random
drop, and full drop (tail drop).
• With RED, TCP global synchronization is eliminated
and the average link utilization increases.
• RED is most useful in enterprise and service provider
networks on output interfaces where congestion is
expected to occur.
Weighted Random Early Detection
• WRED can use multiple different RED profiles.
• Each profile is identified by:
– Minimum threshold
– Maximum threshold
– Maximum drop probability
• WRED profile selection is based on:
– IP precedence (8 profiles)
– DSCP (64 profiles)
• WRED drops less important packets more
aggressively than more important packets.
• WRED can be applied at the interface or class level.
Class-Based WRED
• Class-based WRED is available when configured
in combination with CBWFQ only.
• Using CBWFQ with WRED allows the
implementation of DiffServ Assured Forwarding
PHB.
• Class-based configuration of WRED is identical to
standalone WRED.
WRED Building Blocks
WRED Profiles

• WRED profiles can be manually set.


• WRED has 8 default value sets for precedence-based
WRED.
• WRED has 64 default value sets for DSCP-based WRED
IP Precedence and
Class Selector Profiles
DSCP-Based WRED
(Expedited Forwarding)
DSCP-Based WRED
(Assured Forwarding)
WRED configuration
• policy-map wred-dscp-example
• class bulk-data
• bandwidth remaining percent 30
• random-detect dscp-based
Module Summary
• By default, routers use tail drop as a means of congestion
control when an output queue is full. Tail drop treats all
traffic equally and does not differentiate between classes
of service. When tail drop is in effect, packets are dropped
until the congestion is eliminated and the queue is no
longer full.
• Congestion avoidance techniques, such as RED, monitor
network traffic loads in an effort to anticipate and avoid
congestion at common network bottlenecks. Congestion
avoidance is achieved through packet dropping.
• WRED, the Cisco implementation of RED, combines the
capabilities of the RED algorithm with IP precedence or
DSCP.
• ECN is an extension to WRED that enables flow control and
congestion signaling without requiring packet drops.

You might also like