Spring 2003 CS 332 1

Congestion Avoidance

Spring 2003 CS 332 2

Congestion Avoidance• TCP congestion control strategy:

– Increase load until congestion occurs, then back off from this point

– Needs to create losses to determine connection bandwidth

• Alternative:– Predict when congestion is about to happen, then

reduce host sending rates just before packets start being dropped.

– Not widely adopted at this time

Spring 2003 CS 332 3

DECbit

• Designed for Digital Network Architecture (DNA)– Connectionless network with connection-oriented

transport protocol (sound familiar?)

• General idea– Router monitors load, set binary congestion bit when

congestion imminent

– Receiver copies congestion bit into ACK it sends back

– Sender cuts its sending rate

Spring 2003 CS 332 4

DECbit Details• Router measures average queue length over previous

busy+idle cycle, plus current busy cycle.• If above average is >= 1, then set congestion bit

– Value of 1 seems to optimize power

– Tradeoff between higher throughput and longer delay

• Host maintains a congestion window– If less than 50% of last windows worth of packets have

congestion bit set, increase window by one packet

– Else decrease window size to 0.875 times current value

• Note additive increase/multiplicative decrease

Spring 2003 CS 332 5

Random Early Detection (RED)

• Similar to DECbit• Invented by Sally Floyd and Van Jacobson, early 90s• Designed to be used with TCP• Two differences between RED and DECbit

– RED implicitly notifies of imminent congestion by dropping a packet, thus causing timeout or duplicate ACK

– When RED drops a packet and how it decides which to drop (DECbit just drops when queue fills)

Spring 2003 CS 332 6

RED Philosophy

• Philosophy: drop a few packets before buffer is exhausted in hope that this will avoid having to drop lots of packets later (note could have simply marked packets instead of dropping them)

• Queuing philosophy: early random drop– Drop arriving packet with some drop probability

whenever queue length exceeds some drop level

• Algorithm defines:– How to monitor queue length– When to drop packet

Spring 2003 CS 332 7

RED (cont.)

• Compute average queue length similar to TCP timeout:

AvgLen = (1 – Weight)× AvgLen + Weight × SampleLen

0 < Weight < 1

Effectively low

pass filter to handle

bursty nature of traffic

Spring 2003 CS 332 8

More RED• Two parameters: MinThreshold, MaxThreshold

if (AvgLen MinThreshold) { queue_packet();

} else if (MinThreshold < AvgLen < MaxThreshold){

calculate probability P;

drop arriving packet with probability P;

} else if (MaxThreshold AvgLen) { drop arriving packet;

}

Spring 2003 CS 332 9

Still More RED• Rationale: if AvgLen reaches MaxThreshold, then

gentle approach isn’t working (though research has indicated that a more smooth transition to complete dropping might be more appropriate)

P= MaxP × (AvgLen – MinThreshold)/(MaxThreshold – MinThreshold)

Spring 2003 CS 332 10

More RED than you can shake a stick at

• A Problem: As is, packet drops not well distributed in time.– Occur in clusters

– Because packet arrivals from a connection are likely to arrive in bursts, this clustering causes multiple drops in single connection

– Bad, since only need one drop per round trip, to slow, whereas lots of drops could send connection into slow start

Spring 2003 CS 332 11

RED just won’t go away…

• Solution: Make P a function of both AvgLen and how long since last packet dropped:

TempP = MaxP × (AvgLen – MinThreshold)/(MaxThreshold – MinThreshold)

P = TempP/(1 – count × TempP)

• count: how many packets have been queued while AvgLen has been between two thresholds

• Note that larger count => larger P• Spreads out occurrence of drops

Spring 2003 CS 332 12

RED again

• Because packet drops are random, flows that use more bandwidth have higher probability of packet drop, so a sense of fairness built in (sort of)

• At times, queue length will exceed MaxThreshold (though AvgLen may not). Need extra space in queue above MaxThreshold to handle these bursts without forcing router into tail drop mode

Spring 2003 CS 332 13

Tuning RED• If traffic bursty, MinThreshold should be large enough to

allow link utilization at fairly high level• MaxThreshold – MinThreshold should be larger than typical

increase in calculated queue length during on RTT (set MaxThreshold to twice MinThreshold)

• From time router drops packet to time router sees relief is at least one RTT, so makes no sense to respond to congestion on time scales less than one RTT (100ms good rule). Choose weight so that changes on time scale less than RTT are filtered out

• Caveat: These all depend on traffic mix (I.e. network workload). Active area of research

Spring 2003 CS 332 14

Source Based Congestion Avoidance

• Key: watch for clues that router queues building up• Scheme 1: Congestion window increases as in TCP, but every

two round trip delays, check if current RTT is greater than avg of min and max observed RTT. If so, decrease window by one-eighth

• Scheme 2: Every RTT, increase window by one packet. Compare throughput achieved to throughput with window one packet smaller (i.e. find slope of the throughput vs window curve). If difference less than half throughput achieved when only one packet in network, then decrease window by one packet. (Throughput calculated as (num bytes outstanding in network)/RTT)

Spring 2003 CS 332 15

TCP Vegas

• Metaphor: driving on ice. Speedometer (window size) says you’re going 30mph, but you know (observed throughput) you’re only going 10. Extra energy absorbed by tires (buffers)

• TCP Vegas idea: measure and control amount of “extra” data in network (i.e. data source would not have transmitted if trying to match bandwidth)– Too much extra data => delay and congestion– Too little extra data => slow response to transient

increases in bandwidth

Spring 2003 CS 332 16

TCP Vegas

Congestion window

Avg sending rate(throughput)

Avg queue sizeat bottleneck

Spring 2003 CS 332 17

TCP Vegas

• BaseRTT: RTT of packet when flow not congested (set to minimum observed RTT)

• ExpectedRate = CongestionWindow/BaseRTT (CongestionWindow is from TCP. Assumed here to be equal to num bytes in transit)

• ActualRate: Record RTT for distinguished packet, count bytes sent between packet transmit and return of ACK, divide this by RTT. Done once per round trip

• Compare ActualRate to ExpectedRate and adjust window accordingly

Spring 2003 CS 332 18

TCP Vegas

• Diff = ExpectedRate – ActualRate – Must be nonnegative or we need to change BaseRTT

, with < corresponds roughly to too little extra data in network corresponds roughly to too much extra data in network

• If Diff < , increase window linearly during next RTT• If Diff > , decrease window linearly during next RTT• If < Diff < , leave window alone

Spring 2003 CS 332 19

Intuition

• Farther actual throughput gets from expected throughput, more congestion in network, sending should be reduced

• Actual throughput gets too close to expected throughput, then in danger of underutilizing available bandwidth

• Goal is to keep between and extra bytes in network

Spring 2003 CS 332 20

TCP Vegas

Congestion

Window

ExpectedRate (colored line), ActualRate (black line), shaded area

is region between and thresholds

Spring 2003 CS 332 21

TCP Vegas , compared to throughput rates, so typically

given in KBps.• Intuition: how many extra buffers connection is

occupying in network– Ex. BaseRTT = 100ms, packet size 1KB, = 30 KBps,

= 60 KBps. So in one RTT, have between 3 KB and 6 KB in network (I.e. 3 to 6 packets, or equivalently 3 to 6 extra buffers in network)

– In practice setting to one buffer and to three buffers works well

• TCP Vegas decreases window linearly (so why isn’t it unstable?)