1. TCP Variations Naveen Manicka CISC 856 – Fall 2005 Computer & Information Sciences University of Delaware Nov 10, 2005 Most slides are borrowed from J. Leighton, B. Forouzan, P. Amer., I. Aydin

2. What Are TCP Variations? Implementations of TCP that use different algorithms to achieve end-to-end congestion control. –Tahoe –Reno –NewReno –Vegas –SACK –Rome –Paris

3. Evolution of TCP 19851990 1986 Congestion collapse 1 st observed 1988 Van Jacobson’s algorithms slow start, congestion avoidance, fast retransmit (all implemented in 4.3BSD Tahoe) SIGCOMM 88 1990 4.3BSD Reno fast recovery delayed ACK’s 1984 Nagel’s algorithm to reduce overhead of small packets; predicts congestion collapse 1993 1996 NewReno modified fast recovery SACK TCP Selective Ack (Floyd et al) 1993 TCP Vegas(not implemented) real congestion avoidance (Brakmo et al)

4. How Did TCP Cause Congestion? (Original Recipe TCP) Poor Efficiency In telnet-like applications, TCP sends 1 byte of data with 4000% overhead. Sending too much, too soon Unnecessary retransmits Sending window too large Very little change in behavior due to congestion

5. TCP Variation: TCP Tahoe 1 st improvement was TCP Tahoe (1988) –Adjusts sending window as congestion increases or decreases (AIMD congestion avoidance & slow-start) –Improved retransmission policy (Fast Retransmit) –Nagle’s algorithm –Improved RTO calculation and back-off (Karn’s algorithm)

6. Self-clocking or ACK Clock Maintain equilibrium of system Self-clocking systems tend to be very stable under a wide range of bandwidths and delays. The principal issue with self-clocking systems is getting them started. PrPr PbPb ArAr AbAb Receiver Sender AsAs

7. 7 TCP Tahoe Window Control TCP sender maintains two new variables:  cwnd – congestion window cwnd is inferred from the level of congestion in the network.  ssthresh – slow-start threshold ssthresh can be thought of as an estimate of the level below which congestion is not expected. send_win = min (rwin, cwnd)

8. Slow Start Phase (cwnd < ssthresh) Initially: –cwnd = 1*MSS (Maximum Segment Size) –ssthresh is very large. If no loss: –cwnd += 1*MSS (after each new ACK) –(This gives exponential growth of cwnd) If loss (timeout): –ssthresh = max( flight size/2, 2*MSS) –cwnd = 1*MSS

9. Congestion Avoidance Phase (cwnd > ssthresh) If no loss: –increase cwnd at most 1*MSS per RTT (additive increase) –cwnd += ( MSS*MSS / cwnd ) on every ACK (approximation to increasing cwnd by 1*MSS per RTT) If loss: –ssthresh = max ( flight size/2, 2*MSS ) (multiplicative decrease) –cwnd = 1*MSS.

10. Slow Start & Congestion Avoidance ssthresh Initally: - cwnd = 1*MSS - ssthresh = very high (65535) If a new ACK comes: -if cwnd < ssthresh  update cwnd according to slow start -if cwnd > ssthresh  update cwnd according to congestion avoidance -If cwnd = ssthresh  either If timeout (i.e. loss) : - ssthresh = flight size/2; - cwnd = 1*MSS time cwnd Loss, e.g. timeout slow start – in green congestion avoidance – in blue (initial) ssthresh

11. assume ssthresh = 8*MSS Example: Slow Start/Congestion Avoidance cwnd = 10 cwnd = 4 Eight ACKs cwnd = 2 cnwd = 8 cwnd = 1 cwnd = 9 Eight TCP-PDUs nineACKs nine TCP-PDUs ten ACKs ten TCP-PDUs cwnd = 11 ssthresh S R

12. TCP Tahoe’s Retransmission Policy When a segment is lost, original TCP waits for an ACK that’s not coming and eventually times- out. Often, many, if not all, of the segments sent after the lost segment arrive at the receiver. For each segment received, the receiver sends a duplicate ACK, notifying the sender that the receiver is waiting for the missing segment. TCP Tahoe interprets duplicate ACK’s as an indication that a segment was lost.

13. TCP Tahoe’s Fast Retransmit 1.Sender receives 3 dupACKS. 2.Sender infers that the segment is lost. 3.Sender re- sends the segment immediately! 4.Sender returns to slow-start. ACK 1 segment 1 cwnd = 1 cwnd = 2 segment 2 segment 3 ACK 3 cwnd = 4 segment 4 segment 5 segment 6 segment 7 ACK 2 3 duplicate ACKs ACK 3 segment 4 fast-retransmit of segment 4 S R

14. TCP Tahoe Trace (with one dropped segment) Lost segment Fast Retransmit Begin slow-start Begin congestion avoidance RTT

15. Could Tahoe Do Better? Receipt of dupACKs tells the sender that the receiver is still getting new segments, i.e. there is still data flowing between sender and receiver Why does sender go back to slow start after fast retransmit? Why does sender let Ack clock die?

16. TCP Variation: TCP Reno 2nd Improvement was TCP Reno (1990) –From Tahoe: Nagle’s algorithm Improved RTO calculation and back-off AIMD congestion avoidance with slow-start Fast retransmit –New to Reno: Fast recovery

17. Fast Recovery cwnd Slow StartCongestion Avoidance Time “inflating” cwnd with dupACKs “deflating” cwnd with a new ACK (initial) ssthresh new ACK fast-retransmit new ACK timeout Concept: After fast retransmit, reduce cwnd by half, and continue sending segments at this reduced level. Observations: Receiver is still getting T-PDUs. There can’t be overwhelming congestion. How does sender transmit T-PDUs on a dupACK? Need to use a “trick” - inflate cwnd.

18. After receiving 3 dupACKS: –Retransmit the lost segment. –Set ssthresh = flight size/2. –Set ndupacks=3 and cwnd=ssthresh + ndupacks. --- (inflating) In Reno: send_win = min ( rwnd, cwnd + ndupacks ). If dupACK arrives: –cwnd =+ 1MSS --- (inflating) –Transmit new segment, if allowed. If new ACK arrives: –ndupacks = 0 –cwnd = initial ssthresh in (2) --- (deflating) –Exit fast recovery. If RTO timer expires: –ndupacks = 0 –Perform slow-start -- (ssthresh = flight size/2, cwnd = 1 * MSS) Fast Retransmit & Fast Recovery

19. TCP Reno Trace (with one dropped segment) Lost segment Fast Retransmit Begin fast recovery Begin congestion avoidance RTT Exit fast recovery

20. TCP Tahoe & Reno Trace (with one dropped segment) Slow Start Congestion Avoidance

21. What if There are Multiple Losses in a Window? With two losses in a window, Reno will occasionally timeout. With three losses in a window, Reno will usually timeout. With four losses in a window, Reno is guaranteed to timeout! With three or more losses in a window, Tahoe typically out performs Reno!

22. TCP Reno Trace (with two dropped segments) Fast Retransmit 1 Fast Retransmit 2 Begin fast recovery 1 Begin fast recovery 2

23. TCP Variation: TCP NewReno 3rd Improvement was TCP NewReno (1995) –From Tahoe: Nagle’s algorithm Improved RTO calculation and back-off AIMD congestion avoidance with slow-start –New to NewReno: Fast retransmit & modified fast recovery

24. Modifications to Fast Recovery –Partial ACKs: An ACK that acknowledges some but not all the segments that were outstanding at the start of fast recovery. NewReno interprets this as an indication of multiple loss. –If partial ACK received, re-transmit the next lost segment immediately and set ndupacks = 0 (deflate send_win). –Sender remains in fast recovery until all data outstanding when fast recovery was initiated is ACK’ed. Additional dupACK’s increase ndupacks.

25. TCP NewReno Trace (with two dropped segments) Fast retransmit of lost segment Modified fast recovery Exit fast recovery Partial Ack Outstanding Data Ack

26. Tahoe, Reno & NewReno Trace (with two dropped segments)

27. State Transitions for Tahoe, Reno & New Reno

28. Is There a Better Way? The only way Tahoe, Reno and NewReno can detect congestion is by creating congestion! –They carefully probe for congestion by slowly increasing their sending rate. –When they find (create), congestion, they cut sending rate at least in half! This slow advance and rapid retreat approach results in a saw-toothed sending rate and highly erratic throughput. What if TCP could detect congestion without causing congestion?

29. TCP Variation: TCP Vegas (True Congestion Avoidance) Introduced by Brakmo and Peterson (1994) Three changes to TCP Reno –Modified congestion avoidance Don’t wait for a timeout, if actual throughput < expected throughput decrease the congestion window. (AIAD!) Estimate of expected throughput, –T expected = window size / smallest measured RTT –New retransmission mechanism motivation: what if sender never receives 3-dupACKs (due to lost segments or window size is too small.) mechanism: sender does retransmission after a dupACK received, if RTT estimate > timeout. –Modified slow start motivation: sender tries finding correct window size without causing a loss. mechanism: exponential cwnd growth only every other RTT.

30. TCP Variation: TCP Vegas Congestion Avoidance: –2 thresholds α and β, to control amount of extra data i.e T extra = T expected – T actual T extra Window size increased by 1. α No change in window size. T extra > β => Window size decreased by 1. –Avoids large oscillations like in other variations. More balanced throughput

31. Vegas vs. NewReno TCP NewReno throughput with simulated background traffic TCP Vegas throughput with simulated background traffic Source: Brakmo and Peterson, TCP Vegas: End to End Congestion Avoidance on a Global Internet, IEEE JSAC, Vol 13, No. 8, Oct. 1995, pp. 1465 – 1480

32. What Variations Are Being Used? Experimental results obtained by testing 84394 web servers (27914 classified): –NewReno76% –Tahoe 4%(w/o Fast Retransmit) –Reno15% –Other 1% –Tahoe 4% Source: Medina, Allman, and Floyd, “Measuring the Evolution of Transport Protocols in the Internet”, May 2004

33. TCP Today TCP is currently defined by: –IETF Std’s.: RFC793, RFC1122 (Tahoe w/o FR) –IETF Proposed Std’s.: RFC1323 (Scaled windows & timestamps) RFC2018, RFC2883, RFC3517 (SACK) RFC2581 (Reno) RFC2988 (RTO) RFC3168 (ECN) RFC3390 (Larger IW) –IETF Exp. RFC’s: RFC2582 (NewReno) Many many more!

34. Questions ? …

35. Summary of TCP Behavior When entering slow start, if connection is new, ssthresh = arbitrarily large value cwnd = 1. else, ssthresh = max(flight size/2, 2*MSS) cwnd = 1. In slow start ++cwnd on new ACK TCP Variation Response to 3 dupACK’s Response to Partial ACK of Fast Retransmission Response to “full” ACK of Fast Retransmission Tahoe Do fast retransmit, enter slow start ++cwnd Reno Do fast retransmit, enter fast recovery Exit fast recovery, deflate window, enter congestion avoidance NewReno Do fast retransmit, enter modified fast recovery Fast retransmit and deflate window – remain in modified fast recovery Exit modified fast recovery, deflate window, enter congestion avoidance When entering either fast recovery or modified fast recovery, ssthresh = max(flight size/2, 2*MSS) cwnd = ssthresh. In congestion avoidance cwnd += 1*MSS per RTT