1. Spring 2003CS 3321 Congestion Avoidance

2. Spring 2003CS 3322 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

3. Spring 2003CS 3323 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

4. Spring 2003CS 3324 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

5. Spring 2003CS 3325 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)

6. Spring 2003CS 3326 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

7. Spring 2003CS 3327 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

8. Spring 2003CS 3328 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; }

9. Spring 2003CS 3329 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)

10. Spring 2003CS 33210 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

11. Spring 2003CS 33211 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

12. Spring 2003CS 33212 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

13. Spring 2003CS 33213 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

14. Spring 2003CS 33214 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)

15. Spring 2003CS 33215 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

16. Spring 2003CS 33216 TCP Vegas Congestion window Avg sending rate (throughput) Avg queue size at bottleneck

17. Spring 2003CS 33217 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

18. Spring 2003CS 33218 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

19. Spring 2003CS 33219 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

20. Spring 2003CS 33220 TCP Vegas Congestion Window ExpectedRate (colored line), ActualRate (black line), shaded area is region between  and  thresholds

21. Spring 2003CS 33221 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?)