1. TCP Tutorial - Part III - It is licensed under a Creative Commons Attribution 2.5 License Laboratory of Intelligent Network @ KUT (http://link.kut.ac.kr)http://link.kut.ac.kr Youn-Hee Han

2. KUT2 Evolution of TCP

3. KUT3 19751980 1985 1990 1981 TCP & IP RFC 793 & 791 1974 TCP described by Vint Cerf, Bob Kahn In IEEE Trans Comm 1983 BSD Unix 4.2 supports TCP/IP 1984 Nagel’s algorithm to reduce overhead of small packets; predicts congestion collapse 1987 Karn’s algorithm to better estimate round-trip time 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 1975 Three-way handshake Ray Tomlinson In SIGCOMM 75 Evolution of TCP The slides are provided by Bradley Durandetta, Dept. of CIS, Univ. of Delaware.

4. KUT4 1993 1994 1996 1994 ECN Explicit Congestion Notification (Floyd) 1993 TCP Vegas(not implemented) real congestion avoidance (Brakmo et al) 1994 T/TCP Transaction TCP (Braden) 1996 NewReno modified fast recovery SACK TCP Selective Ack (Floyd et al) 1996 Improving TCP startup (Hoe) 1996 FACK TCP Forward Ack extension to SACK (Mathis et al) Evolution of TCP The slides are provided by Bradley Durandetta, Dept. of CIS, Univ. of Delaware.

5. KUT5 TCP Tahoe RFC 2001, Jan. 1997 Unconditionally (either type of loss event) cuts its cwin to 1 MSS and enter slow start phase Slow Start, Congestion Avoidance, Fast Retransmit  Slow Start (Exponential growth of cwnd) Each RTT : cwnd  2 * cwnd  Congestion Avoidance (Linear growth of cwnd) Each RTT : cwnd  cwnd + 1  Fast Retransmit Retransmits after 3 dupACKs without waiting for timeout SSCASSCA window time SS : slow start CA : congestion avoidance

6. KUT6 TCP Tahoe Trace (with one dropped segment) Lost segment Detect the packet loss Begin slow-start Begin congestion avoidance

7. KUT7 TCP Reno developed by Van Jacobson in 1990 standardized as RFC 2001, Jan. 1997 Van Jacobson in January 2006 Van Jacobson joined PARC as a research fellow in August 2006. He previously served as chief scientist at Packet Design LLC[1]. Prior to that, he was chief scientist at Cisco Systems and group leader for the Network Research Group at Lawrence Berkeley Laboratory.PARCPacket Design LLC[1]Cisco SystemsLawrence Berkeley Laboratory

8. KUT8 TCP Reno Slow start, Congestion Avoidance, Fast Retransmit + Fast Recovery Basic ideas  Fast recovery avoid slow start  3 dupACKs  fast retransmit + fast recovery  Timeout  slow start

9. KUT9 TCP Reno Fast Retransmit when the sender receives 3 “ duplicative ACKs ”, i.e. 4 identical ACKs without the arrival of any other intervening packets, Then, it assumes that the segment was lost, Sender retransmits the segment and moves to Fast Recovery phase (instead of moving to Slow Start phase) Fast Recovery the sender decreases cwnd the half of its original size, adds 3 (3 packets have left the network and buffered by the receiver) It continues to send new segments (if allowed by the cwnd value) until receiving new different ACK, which should acknowledge receiving all segments sent till moving to Fast Recovery phase (assuming that no more segments were lost). For each additional duplicated ACK received, increment cwnd by 1

10. KUT10 TCP Reno TCP Reno Example 0 1 2 Ack(1) 3 4 5 6 7 8 cwnd=8 Fast Retransmit  Fast Recovery - cwnd=8/2+3=7 - ssthresh=8/2=4 Ack(1) Ack(9) cwnd=8 cwnd=99 cwnd=1010 cwnd=1111 Exit Fast Recovery  Congestion Avoidance - cwnd=ssthresh=4 Ack(10) 1 12 Flight Size =No. of Unacknowledged segments

11. KUT11 TCP Reno Trace (with one dropped segment) 380000 400000 420000 440000 460000 480000 500000 4.95.05.15.25.35.45.55.65.7 Time (s) Sequence # 0 4 8 12 16 20 24 28 32 36 40 44 48 MSS Sent Segment ACK'ed Segment cwnd ssthresh cwnd in Fast Recovery Detect the packet loss by 3 DupACKs

12. KUT12 TCP Tahoe & Reno Trace (with one dropped segment)

13. KUT13 TCP Newreno RFC 2582, April 1999 It enables to the algorithm to manage a loss of more than one packet without changing the TCP message structure Another improvement (TCP SACK – RFC 2018) enables to cope with a loss of more than one packet by changing message structure (using TCP options)

14. KUT14 TCP Newreno Limitation of TCP Reno If cwnd size is too small (smaller than 4 packets) then it’s not possible to get 3 duplicate acks and run the algorithm TCP Reno can not manage a loss of multiple packets from a single window of data  It will cause a use of retransmission time out TCP Reno doesn’t manage a loss of packets during the Fast Recovery stage 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!

15. KUT15 TCP Newreno Limitation of TCP Reno 0 1 2 Ack(1) 3 4 5 6 7 8 cwnd=8 1 Fast Retransmit  Fast Recovery - cwnd=8/2+3=7 - ssthresh=8/2=4 Ack(1) Ack(3) cwnd=8 Exit Fast Recovery  Congestion Avoidance - cwnd=ssthresh=4 Ack(3) Flight Size =No. of Unacknowledged segments Flight Size(=7) > cwnd => No new segments cwnd=99 Segment #3 will be time-out

16. KUT16 380000 400000 420000 440000 460000 480000 500000 4.95.05.15.25.35.45.55.65.7 Time (s) Sequence # 0 4 8 12 16 20 24 28 32 36 40 44 48 MSS Sent Segment ACK'ed Segment cwnd ssthresh cwnd in Fast Recovery TCP Reno Trace (with two dropped segments) TCP Newreno

17. KUT17 Idea: The sender remembers a number of the last segment that was sent before entering the Fast Retransmit phase The sender deals with a situation when a “ new ” ACK (which is not DupAcks) does not cover the last remembered segment ( “ partial ACK ” ) The sender consider the partial ACK as a situation when more packets were lost before entering the Fast Retransmit. After discovering such situation the sender will retransmit the new lost packet too and will stay at the Fast Recovery stage The sender will finish the Fast Recovery stage when it will get ACK that covers last segment sent before the Fast Retransmit TCP Newreno

18. KUT18 Modifications to Fast Recovery Partial ACKs  An ACK that acknowledges some but not all the segments that were sent before the start of fast recovery. NewReno interprets “Partial ACK” as an indication of multiple loss. If partial ACK received, re-transmit the next lost segment immediately and deflate cwnd as follows:  cwnd = cwnd – the amount of new acknowledged data + 1 Sender remains in fast recovery until all data outstanding sent before fast recovery are ACK’ed. In this fast recovery phase, an additional dupACK’s increase cwnd by 1*MSS TCP Newreno

19. KUT19 TCP NewReno Trace (with two dropped segments) 380000 400000 420000 440000 460000 480000 500000 4.95.05.15.25.35.45.55.65.7 Time(s) Sequence # 0 4 8 12 16 20 24 28 32 36 40 44 48 MSS Sent Segment ACK'ed Segment cwnd ssthresh cwnd in fast recovery 7= 16 – 10 + 1

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

21. KUT21 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! (basically AIMD) 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?

22. KUT22 Is There a Better Way? Congestion window (cwnd) 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

23. KUT23 TCP Vegas Introduced by Brakmo and Peterson (1994) L. Brakmo, S. O'Malley, and L. Peterson. TCP Vegas: New techniques for congestion detection and avoidance. In Proceedings of the SIGCOMM '94 Symposium (Aug. 1994) pages 24-35. L. Brakmo and L. Peterson. TCP Vegas: End to End Congestion Avoidance on a Global Internet. IEEE Journal on Selected Areas in Communication, Vol 13, No. 8 (October 1995) pages 1465-1480. TCP Vegas vs. TCP (New)reno TCP Vegas provides a proactive response to congestion TCP (New)reno is reactive with respect to congestion Lawrence S. Brakmo @ The University of Arizona

24. KUT24 TCP Vegas TCP Tahoe vs. TCP (New)reno vs. TCP Vegas cwnd  cwnd/2 + 3 time cwnd SSCASSCAFR Duplicate ACK  CA cwnd  1 Timeout  SS cwnd  1 time cwnd SSCASSCA Duplicate ACK  CA cwnd  1 Timeout  SS SS time cwnd CA TCP Tahoe TCP (New)reno TCP Vegas

25. KUT25 TCP Vegas Modified congestion avoidance source watches for some sign that router ’ s queue is building up and congestion will happen too Sets congestion window size based on the difference between the expected and actual data rates Define …  cwnd: current congestion window size  rtt*: the minimum of all measured round-trip time It is commonly the RTT of the first segment sent by the connection Expected Throughput = cwnd/rtt*  rtt: actual (with congestion) round-trip time Actual Throughput = cwnd/rtt  Diff = Expected Throughput – Actual Throughput Note that Diff is always positive (Diff>0) Diff < 0 means that we need to change rtt*

26. KUT26 TCP Vegas Modified congestion avoidance Estimated flight size    = (cwnd/rtt* – cwnd/rtt)  rtt*  : low threshold for  (want  >  )  : high threshold for  (want  <  ) TCP Vegas attempts to control cwnd as follows:  If  < , increase cwnd by 1 * MSS  If  > , decrease cwnd by 1 * MSS  Otherwise (      ), cwnd is not changed. The overall goal is to keep between  and  extra bytes in the network.

27. KUT27 TCP Vegas Example Assumption  A connection with rtt* of 100ms  MSS = 1KBytes  cwnd = 3KBytes  Expected Throughput = 3KBytes/100ms = 30KBytes/s Actual Sampling  rtt=300ms  Actual Throughput = 3KBytes/300ms = 10KBytes/s  Estimated flight size  = (30 – 10) KBytes/s * 0.1s = 2 KBytes  2 segments Cwnd Control Example  If  =3KBytes (3 segments) and  =5KBytes (5 segments),  <  Result: cwnd = cwnd + 1 * MSS = 3 KBytes + 1 KBytes = 4 Kbytes  If  =1KBytes (1 segments) and  =3KBytes (3 segments),      Result: No change  If  =1KBytes (1 segments) and  =1.5KBytes (1.5 segments),  <  Result: cwnd = cwnd - 1 * MSS = 3 KBytes - 1 KBytes = 2 Kbytes

28. KUT28 TCP Vegas Alpha & Beta Initially, sets  to one and  to three.  =1 means …  at least one segment will be left on the buffer of the bottleneck router.  Then, when the aggregate traffic from the other connections decrease, our connection can take advantage of the extra available bandwidth immediately without having to wait for the one RTT delay necessary for the linear increase to occur.  -  =2 means …  Small occasional changes in the available bandwidth will not create oscillations in the window size.  The  -  region provides a damping effects

29. KUT29 TCP Vegas Consideration  =1 and  =3 Black line = actual rate Green line = expected rate Shaded = region between  and  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. congestion window Throughput 33

30. KUT30 TCP Vegas TCP Vegas generally outperforms TCP Reno in a homogeneous environment TCP Vegas achieves between 40% and 70% better throughput TCP Vegas has 20% to 50% of the losses compared to the TCP Reno TCP Reno TCP Vegas

31. KUT31 TCP Selective Ack TCP SACK RFC 2018, Oct. 1996 Selective Acknowledgment (SACK) allows…  the receiver to inform the sender about all segments that have been successfully received.  the sender to retransmit only those segments that have been lost. sender receiver 5500-5999 6000-6499 5000-5499 ACK 5500 6500-6999 ACK 5500; SACK=6000-6500 ACK 5500; SACK=6000-7000

32. KUT32 TCP Selective Ack TCP SACK-related Options SACK-Permitted Option: from sender to receiver SACK Option: from receiver to sender TCP SACK Rules A SACK cannot be sent unless the SACK-permitted option has been received (in the SYN). The first SACK block must contain the most recently received segment that is to be SACKed. The second block must contain the second most recently received segment that is to be SACKed, and so forth. Notice this can result in some data in the receiver’s buffers which should be SACKed but is not (if there are more segments to SACK than available space in the TCP header).

33. KUT33 TCP Selective Ack SACK Example (assuming Tahoe & long timeout) sender receiver 5000-5499 6500-6999 6000-6499 8000-8499 7000-7499 ACK 5500 ACK 5500; SACK=6000-6500 ACK 5500; SACK=7000-7500, 6000-6500 7500-7999 8500-8999 5500-5999 ACK 5500; SACK=8000-8500, 7000-7500, 6000-6500 ACK 5500; SACK=9000-9500, 8000-8500, 7000-7500 9000-9499 Assuming 3 maximum blocks

34. KUT34 TCP Selective Ack What should the Sender do? The sender must keep a buffer of unacknowledged data. When it receives a SACK option, it should turn on a SACK-flag bit for all segments in the transmit buffer that are wholly contained within one of the SACK blocks. After this SACK flag bit has been turned on, the sender should skip that segment during any later retransmission. Rough Example Assume packets 5-25 are transmitted Let packets 5, 12, and 18 be lost Receiver sends back a CACK=5, and SACK=(6-11,13-17,19-25) Sender knows that packets 5, 12, and 18 are lost and retransmits them immediately

35. KUT35 TCP Selective Ack SACK TCP at the Sender Example sender receiver 6000-6499 ACK 5500; SACK=6000-6500 5500-5999 6500-6999 7000-7499 ACK 5500; SACK=6000-7000 5000-5499 5500-5999 7000-7499 ACK 5500; SACK=6000-7500 SENDER TIMEOUT

36. KUT36 TCP Selective Ack SACK TCP Observation SACK TCP follows standard TCP congestion control; it should not damage the network. This information allows the sender to better decide what it needs to retransmit and what it does not.  This can only serve to help the sender, and should not adversely affect other TCPs (Tahoe, Reno, NewReno, Vegas). While it is still possible for a SACK TCP to needlessly retransmit segments, the number of these retransmissions has been shown to be quite low in simulations, relative to Reno and Tahoe TCP.

37. KUT37 TCP Selective Ack SACK TCP Implementation Windows 2000 Windows 98 / Windows ME Solaris 7 and later Linux kernel 2.1.90 and later FreeBSD and NetBSD have optional modules ACIRI has measured the behavior of 2278 random web servers that claim to be SACK-enabled. Out of these, 2133 (93.6%) appeared to ignore SACK data and only 145 (6.4%) appeared to actually use the SACK data. – why is SACK deployment so much slower than Reno and New-Reno?