Transport: TCP

1. Transport: TCP Manpreet Singh (Slides borrowed from various sources on the web)

2. Announcements (1/2) • Everybody needs to join the class mailing list...else I can't communicate class info. • Check the class archives to see if someone else has picked the same lecture or TCP application • We have a group of machines you can use for simulation (snoopy, linus, etc.).  • You need CSUG accounts to access these machines. • We’ll dig up more machines for those who want to do kernel hacking.

3. Announcements (2/2) • Need a volunteer to give the "post-modern" E2E lecture 9/9 (in class...).  • The non-research track students will have to do an initial demo by 11/9.  • Most of the functionality should be there • Allows us to give feed back • You time to do performance measurements.

4. Roadmap • Why is TCP fair ? • Loss-based congestion schemes • Tahoe • Reno • NewReno • Sack • Delay-based congestion control (Vegas) • Modeling TCP throughput • Equation-based congestion control

5. The Desired Properties of a Congestion Control Scheme • Efficiency (high utilization) • Optimality (high throughput, utility) • Fairness (resource sharing) • Distributedness (no central knowledge for scalability) • Convergence and stability (fast convergence after disturbance, low oscillation)

6. Fairness goal: if N TCP sessions share same bottleneck link, each should get 1/N of link capacity TCP congestion avoidance: AIMD:additive increase, multiplicative decrease increase window by 1 per RTT decrease window by factor of 2 on loss event TCP Fairness AIMD TCP connection 1 bottleneck router capacity R TCP connection 2

7. Two competing sessions: Additive increase gives slope of 1, as throughout increases multiplicative decrease decreases throughput proportionally Why is TCP fair? equal bandwidth share R loss: decrease window by factor of 2 congestion avoidance: additive increase Connection 2 throughput loss: decrease window by factor of 2 congestion avoidance: additive increase Connection 1 throughput R

8. Loss vs Delay as signal ??? Loss is a binary signal Delay is a multi-bit signal TCP oscillation

9. Simulation-based Comparisons of Tahoe, Reno, and SACK TCP Kevin Fall Sally Floyd

10. Introduction • SACK compared with Tahoe, Reno and New-Reno • Simulations designed to highlight performance differences with and without SACK

11. Comparison • Tahoe: Slow start, congestion avoidance and fast retransmit • Reno: Tahoe + fast recovery • New-Reno: Reno with modified fast recovery • SACK: Reno + selective ACKs

12. exponential increase (per RTT) in window size (not so slow!) loss event: timeout (Tahoe TCP) and/or or three duplicate ACKs (Reno TCP) Slowstart algorithm (non-linear phase) time TCP Slowstart Host A Host B one segment RTT initialize: Congwin = 1 for (each segment ACKed) Congwin++ until (loss event OR CongWin > threshold) two segments four segments

13. TCP Congestion Avoidance Congestion avoidance (linear phase) /* slowstart is over */ /* Congwin > threshold */ Until (loss event) { every w segments ACKed: Congwin++ } threshold = Congwin/2 Congwin = 1 perform slowstart 1 1: TCP Reno skips slowstart (fast recovery) after three duplicate ACKs

14. Fast Retransmit • Receiving small number of duplicate ACKs (3) signals packet loss • Lost packet can be retransmitted before timeout • This improves channel utilization

15. TCP/Reno Congestion Control Initially: cwnd = 1; ssthresh = infinite (64K); For each newly ACKed segment: if (cwnd < ssthresh) /* slow start*/ cwnd = cwnd + 1; else /* congestion avoidance; cwnd increases (approx.) by 1 per RTT */ cwnd += 1/cwnd; Triple-duplicate ACKs: /* multiplicative decrease */ cwnd = ssthresh = cwnd/2; Timeout: ssthresh = cwnd/2; cwnd = 1; (if already timed out, double timeout value; this is called exponential backoff)

16. TCP/Reno: Big Picture Tahoe + Fast Recovery cwnd TD TD TD TO ssthresh ssthresh ssthresh ssthresh Time congestion avoidance slow start congestion avoidance congestion avoidance slow start congestion avoidance TD: Triple duplicate acknowledgements TO: Timeout

17. Old cwnd Packet lost New cwnd = (old cwnd)/2 Usable window increased by 1 for each duplicate ACK Left edge fixed till ACK received Fast Recovery • Observation: Each duplicate ACK indicates some packet has left pipe

18. New-Reno extension • New-Reno continues with fast recovery if a partial ACK is received Old cwnd Packet 1 lost Packet 2 lost LP: Last Packet sent before loss detection Usable window increased by 1 for each duplicate ACK until ACK for LP is received New cwnd = (old cwnd)/2

19. Why use SACK? • Without SACK sender has to use one of following retransmission strategies - Retransmit 1 dropped packet / RTT Reno, New-Reno - Retransmit packets that might have been successfully delivered Tahoe

20. SACK option [RFC2018] • Ex: 2nd segment dropped (each segment has 500 bytes)

21. SACK Congestion Control (1/2) • Conservative extensions to Reno • Fast recovery algorithm modified • Uses a variable called “pipe” to estimate outstanding data in the flow • Rules for changing “pipe” variable • + 1 when packet transmitted • - 1 when dup ACK received

22. SACK Congestion Control (2/2) • SACK sender tracks successfully sent packets using “scoreboard” structure • Missing packets are retransmitted • Similar to New-Reno in exiting from fast recovery – exits after all outstanding data at time of loss is ACked

23. Simulation Model used • Three flows are setup from S1 to K1, 2nd and 3rd flows are used to change packet drop pattern of 1st flow

24. One Packet Loss (1/2) Performs slow start Packet dropped Packet retransmitted

25. One Packet Loss (2/2) Performs fast recovery Packet dropped Packet retransmitted

26. Two Packet Loss (1/2) Performs slow start Packets dropped Packets retransmitted

27. Two Packet Loss (2/2) Performs fast recovery Packets dropped Packets retransmitted

28. Three Packet Losses (1/3) Has to wait for timeout Packets dropped Packets retransmitted

29. Three Packet Losses (2/3) No need for timeout Retransmits 1 pkt/RTT Packets dropped Packets retransmitted

30. Three Packet Losses (3/3) Retransmits more than 1 pkt /RTT Packets dropped Packets retransmitted

31. Observations • Tahoe: Robust, performs slow start • Reno: For > 2 losses, timeout is often needed • New-Reno: Can avoid timeouts, but still cannot retransmit > 1 pkt/RTT • SACK: Can retransmit > 1 pkt/RTT , thus recovers from losses faster

32. Conclusions • SACK can improve TCP performance • SACK can be used in high loss links too (Ex: Wireless) • New-Reno demonstrates that certain problems of Reno can be avoided without SACK

33. Reno vs Vegas (Congestion Avoidance) • Reno’s mechanism • Characteristics • uses the loss of segments as a signal • reactive not proactive • needs to create losses to find the available bandwidth • example send window congestion window Threshold window

34. 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 router In shaded region we expect throughput to increase but it cannot increase beyond available bandwidth

35. Vegas’ approach • Basic idea • Vegas tries not to send at a rate that causes buffers to fill • maintain the right amount of extra data • based on changes in the estimated amount of extra data • window size vs. throughput • Keep the actual rate straying too far from the available rate (resulting in smooth congestion avoidance period)

36. Vegas Algorithm • define a given connection’s BaseRTT • BaseRTT = the minimum of all measured RTT • expected throughput = WindowSize / BaseRTT • Actual rate = Flight size / RTT • Calculate the current Actual sending rate • Compare Actual (A) to expected (E) and adjusts the window (linear increase or decrease) • If (E-A) > beta, cwnd - - (congestion state) • If (E-A) < alpha, cwnd++ (low utilization) • When a loss is detected, reduce the window by a half

37. Algorithm (cont) • Parameters • a = 1 buffer • b = 3 buffers Black line = actual rate Green line = expected rate Shaded = region between a and b Note: Linear decrease in Vegas does not violate AIMD since it Happens before packets loss

38. Comparison of Reno and Vegas (Retransmission) • Reno’s retransmission mechanism • retransmission timeout • based on RTT and variance estimates • BSD-based : 500ms • Fast Retransmit and Fast Recovery • When the sender receives duplicate acks, it reduces the window size by a half and avoids timeout which causes retransmission with slow start • If multiple drops occur, timeout and slow start will follow anyway. • 19% increase in throughput

39. Vegas’ Retransmission • reads and records the system clock each time a segment is sent • when an ACK arrives, Vegas reads the clock again • RTT calculation using this time and the timestamp recorded for the relevant segment • uses this more accurate RTT estimate to decide to retransmit

40. Some fun topics to discuss…

41. Modeling TCP throughput • Consider congestion avoidance only cwnd W TD bottleneck bandwidth ssthresh W/2 Time congestion avoidance Assume one packet loss (loss event) per cycle Total packets send per cycle: 3W2/8 Thus p = 1/(3W2/8) = 8/(3W2) =>

42. Modeling TCP throughput… • 1/throughput = c * sqrt(p) * RTT

43. Equation-based Congestion Control • Don’t need reliability • But still want to be friendly to the network • What rate should we send the UDP traffic ? • Use detailed TCP analysis to relate throughput to loss and RTT. • Measure these values and then calculated appropriate throughput directly. • Result is rate-based and equation-driven protocol called TFRC.

44. mulTCP • Effect of AIMD parameters on the throughput of TCP