Congestion Control II

1. Congestion Control II Outline Queuing Discipline Reacting to Congestion Avoiding Congestion DECbit Random Early Detection (RED) TCP Vegas 0907422 Computer Networks

2. TCP Congestion Control Idea • assumes best-effort network (FIFO or FQ routers) • each source determines network capacity for itself • determines how many packets it can safely have in transit • safely: without having to retransmit 0907422 Computer Networks

3. TCP Congestion Control (continued I) • ACKs pace transmission (self-clocking) • arrival of an ACK signals that one of the TCP connection packets left network • it is safe to insert a new packet without adding to the level of congestion 0907422 Computer Networks

4. TCP Congestion Control (continued II) Challenge • determining the available capacity in the first place • adjusting to changes in the available capacity 0907422 Computer Networks

5. Additive Increase/Multiplicative Decrease (AIMD) Congestion Control Mechanism • Objective: adjust to changes in the available capacity • New state variable per connection: CongestionWindow • limits how much data the source has in transit MaxWin = MIN(CongestionWindow,AdvertisedWindow) EffWin = MaxWin - (LastByteSent -LastByteAcked)

6. Additive Increase/Multiplicative Decrease (cont) • Idea: • increase CongestionWindow when congestion goes down • decrease CongestionWindow when congestion goes up • TCP source is allowed to send no faster than the slowest component— the network or the destination host —can accommodate. 0907422 Computer Networks

7. Additive Increase /Multiplicative Decrease,AIMD (cont) • Question: how does the source determine whether or not the network is congested? • Answer: a timeout implies congestion • timeout signals that a packet was lost • packets are seldom lost due to transmission error • lost packet implies congestion 0907422 Computer Networks

8. Source Destination AIMD (cont) • Algorithm • increment CongestionWindow by one packet per RTT (linear increase) • divide CongestionWindow by two whenever a timeout occurs (multiplicative decrease) • In practice: increment a little for each ACK Increment = MSS * ( MSS/CongestionWindow) CongestionWindow += Increment 0907422 Computer Networks

9. CongestionWindow AIMD (cont) • Trace: sawtooth behavior 0907422 Computer Networks

10. Source Destination Draw Back of AIMD After a Connection is Established • AIMD mechanism takes too long to ramp up a connection when it is starting from scratch • Sending an entire advertised window’s all at once may lead to congestion (or make it worse) • TCP provides a second mechanism for increasing CongestionWindow at start of data transmission called Slow Start 0907422 Computer Networks

11. Slow Start Source Destination • Increases the congestion window rapidly from a cold start • exponentially, rather than linearly • Idea: • begin with CongestionWindow = 1 packet • double CongestionWindow each RTT (increment by 1 packet for each ACK) 0907422 Computer Networks

12. Slow Start (cont) • Although growth of CongestionWindow is exponential , it is slower than all at once • Used • when first starting connection • slow start doubles CongestionWindow each RTT until there is a loss • a timeout causes multiplicative decrease to divide CongestionWindow by 2 0907422 Computer Networks

13. Slow Start (cont I ) • Also used when connection goes dead waiting for timeout • a packet is lost • source reaches a point where it has sent as much data as allowed • it blocks while waiting for an ACK • Eventually, a timeout happens • source receives a single cumulative ACK that reopens entire advertised window • source uses slow start rather than dumping a whole window’s worth of data on network 0907422 Computer Networks

14. Slow Start: After A Dead Connection • source has a “useful” current value of CongestionWindow • the value that existed prior to the last packet loss, divided by 2 as a result of the loss • this value is stored in CongestionThreshold and used as a “target” CongestionWindow • After timeout and when retransmission is restarted, CongestionWindow is reset to one packet • double CongestionWindow each RTT until it reaches CongestionThreshold(slow start) • incremented by one packet per RTT after CongestionThreshold is reached (Additive Increase) 0907422 Computer Networks

15. Legend: Colored line: value of CongistionWindow Solid Bullets: time outs hash marks at top: time when packets are transmitted vertical bars: time when a packet that was eventually retransmitted was first transmitted • t= 0; Initial slow start phase: rapid increase in the CongestionWindow • t= 0.4; several packets are lost: CongestionWindow flattens out at 34 KB • No ACKs arriving, due to the fact that several packets were lost • No new packets are sent • t= 2; a timeout • CongestionThreshold = current divided by 2 (i.e., cut to 17 KB) • Slow start resets CongestionWindow to one packet and increases it to CongestionThreshold • Additive Increase kicks in after 17KB and will get CongestionWindow to 22KB • t= 4; CongestionWindow flattens out (due to a lost packet) • t= 5.5; a timeout happens, CongestionWindow divided by 2 to give a new CongestionThreshold ( 22 KB/ 2 ) which is set to 11 • slow start causes CongestionWindow to grow exponentially until it reaches 11 then it grows linearly • Behavior repeated at 8… Slow Start: Typical Trace 34 KB 34 KB 22 KB 17 KB 17 KB 11 KB 0907422 Computer Networks

16. Timeout Triggered Retransmission • Problem: coarse-grain TCP timeouts lead to idle periods 0907422 Computer Networks

17. With Fast Retransmission Fast Retransmit • Fast Retransmit: • When a packet is lost, does not wait for a time out to retransmit • Uses duplicate ACKs to trigger retransmission • second transmission of same acknowledgment called a duplicate ACK • a duplicate ACK implies other side received a packet out of order (i.e. a packet has been DELAYED or LOST) • TCP sender waits until it sees three duplicate ACKs before concluding that a packet is LOST and retransmitting that packet 0907422 Computer Networks

18. a version of TCP with the fast retransmit mechanism compared with the trace where fast retransmit was not implemented • the long periods during which the congestion window stays flat and no packets are sent have been eliminated 0907422 Computer Networks

19. Fast Recovery Fast Recovery: additional improvement possible • When the fast retransmit mechanism signals congestion • Slow start is not used • ACKs clock sending of packets • congestion window is not dropped to one packet • go directly to half the last successful CongestionWindow(i.e.CongestionThreshold) • Then use of additive increase begins • This is “Fast Recovery” because: • skip the slow start phase • go directly to CongestionThreshold 0907422 Computer Networks

20. Fast Recovery (continued) • Slow start is only used • At the beginning of a connection • Whenever a coarse-grained timeout occurs • At all other times, the congestion window follows pure additive increase/multiplicative decrease • In general, Fast Retransmit Fast Recovery • eliminate about half of the coarse-grained timeouts • roughly a 20% improvement in the throughput 0907422 Computer Networks

21. Congestion Avoidance • TCP’s strategy • control congestion once it happens • repeatedly increase load in an effort to find the point at which congestion occurs, and then back off • Alternative strategy • predict when congestion is about to happen • reduce rate before packets start being discarded • call this congestion avoidance, instead of congestion control • Two possibilities • router-centric: DECbit and Random Early Detection (RED) Gateways • host-centric: TCP Vegas 0907422 Computer Networks

22. DECbit Router monitors load • Explicitly notifies end nodes when congestion is about to occur • Sets a congestion bit in header • Destination copies congestion bit into ACK • The source adjusts its sending rate to avoid congestion 0907422 Computer Networks

23. DECbit (continued) Router • monitors average queue length over last “busy + idle” cycle and the current busy cycle • set congestion bit if average queue length > 1 • attempts to balance • Significant queuing (hence higher throughput) • Increased idle time (hence lower delay)

24. DECbit & Power Function • a queue length of 1 seems to optimize the power function 0907422 Computer Networks

25. End Hosts • Destination echoes congestion bit back to source • Source records how many packets resulted in a “set congestion bit” • If less than 50% of last window’s worth had bit set • increase CongestionWindow by 1 packet • If 50% or more of last window’s worth had bit set • decrease CongestionWindow by 0.875 times 0907422 Computer Networks

26. Random Early Detection (RED) • Notification is implicit: • dropped packets indicate congestion • Could make notification explicit (Explicit Congestion Notification, ECN; see pp. 488-489) • Current standard proposal for explicit notification (old method: DECbit) • Mark packet as queue gets full, reduce sending rate when marks are seen • RED drops packets to force sources to back off (versus tail drop) • rather than wait for queue to become full, drop each arriving packet with some drop probability whenever the queue length exceeds some drop level 0907422 Computer Networks

27. RED Details • Let SampleLen be queue length measured each time a packet arrives • Use a constant, Weight, such that 0 < Weight < 1 (usually 0.002) • Compute average queue length AvgLen = (1 - Weight) * AvgLen + Weight * SampleLen 0907422 Computer Networks

28. RED Details • two queue length thresholds trigger certain activity • When a packet arrives at the gateway if AvgLen <= MinThreshold then enqueue the packet if MinThreshold < AvgLen < MaxThreshold then calculate probability P drop arriving packet with probability P if MaxThreshold <= AvgLen then drop arriving packet

29. RED Details: Computing Probability P TempP = MaxP * (AvgLen - MinThreshold)/ (MaxThreshold - MinThreshold) P = TempP/(1 - count * TempP) count = number of newly arriving packets that have been queued (not dropped) while AvgLen has been between two thresholds P increases slowly with count 0907422 Computer Networks

30. Computing Probability P (cont) • Drop probability is a function of both AvgLen and how long it has been since the last drop. • As count increases , time since last drop increases, and drop probability increases • makes closely spaced drops less likely • prevents clusters of drops • multiple drops might send a connection back into slow start • a single drop is enough to cause connection to reduce window size 0907422 Computer Networks

31. RED Details (cont) • Drop Probability Curve • RED is good at keeping avg. queue size steady 0907422 Computer Networks

32. Tuning RED • MaxP is typically set to 0.02, meaning that when the average queue size is halfway between the two thresholds, the gateway drops roughly one out of 100 packets. TempP = MaxP * (AvgLen –MinThreshold)/ (MaxThreshold -MinThreshold) P = TempP/(1 - count * TempP) initially count = 0 TempP = .02 * 1/2 = .01 P = .01 0907422 Computer Networks

33. Tuning RED (continued) • Thresholds are hard to determine • If traffic is bursty, then MinThreshold should be sufficiently large to allow link utilization to be maintained at an acceptably high level • Difference between two thresholds should be larger than the typical increase in the calculated average queue length in one RTT; setting MaxThreshold to twice MinThreshold is reasonable for traffic on today’s Internet 0907422 Computer Networks

34. TCP Tahoe (series 1 in figure) First (old) version Reduce Congestion Window to 1 on any loss event Set CongestionThreshold to ½ of current cong. window size TCP Reno (series 2 in figure) Newer Most popular version Reduce Congestion Window To 1 on timeout By half on 3rd duplicate ACK Set CongestionThreshold to ½ of current congestioin window size TCP Versions: Tahoe and Reno 14 12 TCP Reno 10 8 congestion window size (segments) 6 TCP threshold 4 Tahoe 2 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Transmission round Series1 Series2 Assume: 3rd duplicate ACK at time 9 0907422 Computer Networks

35. TCP Vegas • Introduces variation of Reno implementation of TCP • Detects congestion in routers BEFORE loss occurs 0907422 Computer Networks

36. Congestion Avoidance using: TCP Vegas • Idea: source watches for some sign that router’s queue is building up and congestion will happen too. e.g. • RTT grows • sending rate flattens Congestion window Avg. source send rate Buffer space at bottleneck router In shaded region the cogestion widow increases. We expect throughput to increase but it cannot increase beyond available bandwidth Any increase in the window size only results in packets taking up buffer space at bottleneck router

37. Goals of Vegas Algorithm • Vegas tries NOT to send at a rate that causes buffers to fill • “Amount of extra data a connection has in transit” is • Data that the source would not have transmitted had it been trying to match exactly the available bandwidth of the network • The goal of TCP Vegas is to maintain the “right” amount of extra data in the network. • Too much extra data • long delays and possibly lead to congestion • Too little extra data • Source cannot respond rapidly to transient increases in available network bandwidth 0907422 Computer Networks

38. Vegas Algorithm Definitions: • A flow’s BaseRTT : RTT of a packet when the flow is not congested • TCP Vegas sets BaseRTT to the minimum of all measured round-trip times • Commonly the RTT of first packet sent by connection • Expected throughput = ExpectRate = CongestionWindow/BaseRTT • CongestionWindow is the TCP congestion window • Assume to be equal to the number of bytes in transit 0907422 Computer Networks

39. Vegas Algorithm (cont.) • Source calculates sending rate (ActualRate) once per RTT • Pick one packet per RTT, • Timestamp send/ACKreceive time • ActualRate= number of bytes in transit / RTT • Source compares ActualRate with ExpectRate • Define two thresholds, α< β, roughly corresponding to having too little and too much extra data in the network, respectively. • Diff = ExpectedRate – ActualRate • if Diff < a • increase CongestionWindow linearly • else if Diff > b • decrease CongestionWindow linearly • Else • leave CongestionWindow unchanged 0907422 Computer Networks

40. congestion window Throughput Illustrating the Algorithm Black line = actual rate Green line = expected rate Shaded = region between a and b The goal is to keep the ActualRate between these two thresholds, that is, within the shaded region. Whenever ActualRate falls below shaded region (i.e., gets too far from Expected Rate), TCP Vegas decreases the congestion window because it fears that too many packets are being buffered in the network. Whenever ActualRate goes above the shaded region (i.e., gets too close to the Expected Rate), TCP Vegas increases the congestion window because it fears that it is underutilizing the network.