1 / 44

Transport: TCP

Transport: TCP . Manpreet Singh (Slides borrowed from various sources on the web). 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

sun
Download Presentation

Transport: TCP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related