1 / 24

FAST TCP

This presentation explores the viability of TCP Reno in today's high-speed networks and introduces FAST TCP as a stable and quick solution. It discusses the problems with TCP Reno, the dynamics of flow-level control, and compares the performance of different TCP variants. The presentation also explains the FAST TCP equation, its window control algorithm, and provides experimental results demonstrating its stability and throughput. Lastly, it highlights open issues and future plans for FAST TCP.

lamarj
Télécharger la présentation

FAST 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. FAST TCP Anwis Das Ajay Gulati Slides adapted from :IETF presentation slides Link: http://netlab.caltech.edu/FAST/index.html

  2. Background • Last time we saw reliable communication requires a transport level protocol • But user’s are selfish, leading to congestion • Van Jacobson solved the problem by adapting TCP • Slow Start • Congestion Avoidance • Accurate Estimation of RTT, etc • Is the solution still valid considering today’s technology??

  3. Hypothesis • TCP Reno is a good solution for low speed networks but not a viable solution for high-speed networks • Too conservative, not stable, and requires extremely small equilibrium loss probability • There exists an equation that governs the flow of all variants of TCP • FAST provides a solution to this equation and shows that it is stable and reaches equilibrium quickly

  4. Philosophy of Reno • Packet level • Designed and implemented first • Flow level • Understood afterwards • Flow level dynamics determines • Equilibrium: performance, fairness • Stability • Design flow level equilibrium & stability • Implement flow level goals at packet level

  5. Problems with TCP Reno • Equilibrium problem • Packet level: AI too slow, MI too drastic • Flow level: required loss probability too small • Dynamic problem • Packet level: must oscillate on binary signal • Flow level: unstable at large window

  6. ACK: W  W + 1/W Loss: W  W – 0.5W • Packet level • Flow level dynamics pkts TCP Flow Dynamics Reno TCP

  7. TCP Variant Performance • Reno:AIMD (1, 0.5) ACK: W  W + 1/W Loss: W  W – 0.5W • HSTCP:AIMD (a(w), b(w)) ACK: W  W + a(w)/W Loss: W  W – b(w)W • STCP:MIMD (1/100, 1/8) ACK: W  W + 0.01 Loss: W  W – 0.125W

  8. Flow level: Reno, HSTCP, STCP, FAST • Genericflow level dynamics! window adjustment control gain flow level goal = • Different gain k and utility Ui • They determine equilibrium and stability • Different congestion measure pi • Loss probability (Reno, HSTCP, STCP) • Queueing delay (Vegas, FAST)

  9. TCP Problem: binary signal oscillation

  10. Solution: multibit signal FAST stabilized

  11. FAST TCP Dynamics • Generic equation: window adjustment control gain flow level goal = • FAST TCP equation: • Can map generic equation to FAST TCP equation and understand how FAST TCP stabilizes faster than other TCP variants

  12. Window control algorithm • Full utilization • regardless of bandwidth-delay product • Globally stable • exponential convergence • Fairness • weighted proportional fairness • parameter a

  13. Window control algorithm Theorem (Jin, Wei, Low ‘03) In absence of delay • Mapping from w(t) to w(t+1) is contraction • Global exponential convergence • Full utilization after finite time • Utility function: ai log xi (proportional fairness)

  14. Dynamic sharing: 3 flows FAST Linux Steady throughput HSTCP STCP

  15. 30min queue FAST Linux loss throughput Dynamic sharing on Dummynet • capacity = 800Mbps • delay=120ms • 14 flows • iperf throughput • Linux 2.4.x (HSTCP: UCL) HSTCP STCP

  16. 30min queue FAST Linux loss throughput HSTCP STCP HSTCP

  17. small window 800pkts large window 8000 Aggregate throughput Dummynet: cap = 800Mbps; delay = 50-200ms; #flows = 1-14; 29 expts

  18. HSTCP ~ Reno Jain’s index Fairness Dummynet: cap = 800Mbps; delay = 50-200ms; #flows = 1-14; 29 expts

  19. stable in diverse scenarios Stability Dummynet: cap = 800Mbps; delay = 50-200ms; #flows = 1-14; 29 expts

  20. Open issues • 1 BaseRTT estimation • route changes, dynamic sharing • does not upset stability • 2 Small network buffer • at least like TCP • adapt a on slow timescale, but how? • 3 TCP-friendliness • friendly at least at small window • tunable, but how to tune? • 4 Reverse path congestion • should react? rare for large transfer? • 5 Did not compare to Vegas • Future plans

  21. What people on the street are saying about FAST TCP… • PC Magazine“The fastest hardware in the world will not do you much good if your software can't take advantage of it. • Business Week “Connections that leave broadband in the dust” • Steven Low “This is OK for driving slowly in a parking lot. But on the open road you need to be able to look further ahead: That's what we are doing with Fast TCP.” • Future Zone “Scientists have developed a new data transfer protocol for the Internet fast enough to download a full-length DVD movie in less than five seconds”

  22. And Of Course… • Anwis and Ajay (Rice CS) – “FAST TCP Rocks!!! We can’t wait to use it!”

More Related