1 / 59

FAST TCP I: motivation, approach, architecture

FAST TCP I: motivation, approach, architecture. Cheng Jin David Wei Steven Low. http://netlab.caltech.edu. Acknowledgments. Caltech Bunn, Choe, Doyle, Newman, Ravot, Singh, J. Wang UCLA Paganini, Z. Wang CERN Martin SLAC Cottrell Internet2 Almes, Shalunov Cisco

gagan
Download Presentation

FAST TCP I: motivation, approach, architecture

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 I:motivation, approach, architecture Cheng Jin David Wei Steven Low http://netlab.caltech.edu

  2. Acknowledgments • Caltech • Bunn, Choe, Doyle, Newman, Ravot, Singh, J. Wang • UCLA • Paganini, Z. Wang • CERN • Martin • SLAC • Cottrell • Internet2 • Almes, Shalunov • Cisco • Aiken, Doraiswami, Yip • Level(3) • Fernes • LANL • Wu

  3. Outline • Motivation • Approach • Architecture

  4. ns-2 simulation DataTAG Network: CERN (Geneva) – StarLight (Chicago) – SLAC/Level3 (Sunnyvale) average utilization 95% 1G 27% 19% txq=100 txq=100 txq=10000 Linux TCP Linux TCP FAST capacity = 1Gbps; 180 ms round trip latency; 1 flow C. Jin, D. Wei, S. Ravot, etc (Caltech, Nov 02) Performance at large windows 10Gbps capacity = 155Mbps, 622Mbps, 2.5Gbps, 5Gbps, 10Gbps; 100 ms round trip latency; 100 flows J. Wang (Caltech, June 02)

  5. ACK: W  W + 1/W Loss: W  W – 0.5W • Packet level • Flow level • Equilibrium • Dynamics packets Packet & flow level Reno TCP (Mathis formula)

  6. Difficulties at large window • Equilibrium problem • Packet level: AI too slow, MI too drastic. • Flow level: requires very small loss probability. • Dynamic problem • Packet level: must oscillate on a binary signal. • Flow level: unstable at large window.

  7. AIMD reduces throughput 19% 27% 95% 1G txq=100 Linux TCP Linux TCP (Optimized) FAST capacity = 1Gbps; 180 ms round trip latency; 1 flow C. Jin, D. Wei, S. Ravot, etc (Caltech, Nov 02)

  8. Stable: 20ms delay Window Ns-2 simulations, 50 identical FTP sources, single link 9 pkts/ms, RED marking

  9. Queue Stable: 20ms delay Window Ns-2 simulations, 50 identical FTP sources, single link 9 pkts/ms, RED marking

  10. Unstable: 200ms delay Window Ns-2 simulations, 50 identical FTP sources, single link 9 pkts/ms, RED marking

  11. Queue Unstable: 200ms delay Window Ns-2 simulations, 50 identical FTP sources, single link 9 pkts/ms, RED marking

  12. 30% noise avg delay 16ms 20ms 30% noise avg delay 208ms 200ms Flow level (in)stability isrobust

  13. ns-2 simulation Instability reduces utilization capacity = 155Mbps, 622Mbps, 2.5Gbps, 5Gbps, 10Gbps; 100 ms RTT and 100 flows J. Wang (Caltech, June 02)

  14. Outline • Motivation • Approach • Architecture

  15. ACK: W  W + 1/W Loss: W  W – 0.5W • Packet level • Flow level • Equilibrium • Dynamics packets Packet & flow level Reno TCP (Mathis formula)

  16. Difficulties at large window • 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.

  17. Problem: binary signal TCP oscillation

  18. Problem: no target • 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

  19. Difficulties at large window • Equilibrium problem • Packet level: AI too slow, MI too drastic • Flow level: required loss probability too small • Dynamic problem • Packet level: Use multi-bit signal. • Flow level: Stablize flow dynamics!

  20. Solution: multibit signal FAST stabilized

  21. Flow level: Reno, HSTCP, STCP, FAST • Commonflow 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)

  22. FAST Conv Slow Start Equil Loss Rec Solution: estimate target • FAST Scalable to any w*

  23. Implementation strategy • Commonflow level dynamics window adjustment control gain flow level goal = • Small adjustment when close, large far away • Need to estimate how far current state is wrt tarqet. • Scalable. • Queueing delay easier to estimate compared with extremely small loss probability

  24. ACK: W  W + 1/W Loss: W  W – 0.5W • Reno AIMD(1, 0.5) • FAST Packet level ACK: W  W + a(w)/W Loss: W  W – b(w)W • HSTCP AIMD(a(w), b(w)) ACK: W  W + 0.01 Loss: W  W – 0.125W • STCP MIMD(a, b)

  25. Outline • Motivation • Approach • Architecture

  26. Reno TCP • Packet level • Designed and implemented first. • Flow level • Understood afterwards. Packet level design of FAST, HSTCP, STCP guided by flow level properties

  27. FAST TCP • Flow level • Understood and Synthesized first. • Packet level • Designed and implemented later. • Design flow level equilibrium & stability • Implement flow level goals at packet level

  28. ~ Ack timescale ~ RTT timescale Ack timescale Data Control Window Control Burstiness Control Estimation TCP Protocol Processing Architecture

  29. Architecture Each component • designed independently • upgraded asynchronously Data Control Window Control Burstiness Control Estimation TCP Protocol Processing

  30. Data Control • Determines the order of transmission. • Important during recovery, especially at large windows. • Linux loss recovery tightly coupled with Window Control.

  31. Window Control • Defines an explicit equilibrium point. • Uses queueing delay for equation-base congestion control. • Uses loss information whenever necessary. • Does not use a separate mechanism during recovery like TCP Reno.

  32. Burstiness Control • Smoothes out transmission rate to be more fluid-like. • Important to avoiding frequent packet loss at bottleneck links. • Essential to accurate queueing delay estimation.

  33. Summary • Reno TCP has poor performance at large windows. • Reno TCP has problems at both the packet-level and the flow-level. • FAST TCP addresses these by: • Using queueing delay. • Defining an explicit equilibrium. • Separating window control from the rest.

  34. The End

  35. Data Control Window Control Burstiness Control Estimation TCP Protocol Processing Architecture Each component • designed independently • upgraded asynchronously Window Control

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

  37. 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)

  38. Dynamic sharing: 3 flows FAST Linux Dynamic sharing on Dummynet • capacity = 800Mbps • delay=120ms • 3 flows • iperf throughput • Linux 2.4.x (HSTCP: UCL)

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

  40. 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

  41. 30min queue Room for mice ! FAST Linux loss throughput HSTCP STCP HSTCP

  42. ideal performance Aggregate throughput Dummynet: cap = 800Mbps; delay = 50-200ms; #flows = 1-14; 29 expts

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

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

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

  46. Performance on slow network Linux July 10, 2003 11:00-11:30 pm Caltech  Michigan 5-min runs Competing: separate senders to same receiver FAST & Linux seperately FAST & Linux competing Both get “>1/2” capacity! July 11, 2003 10:45-11:15 am

  47. Open issues • 4.3: baseRTT estimation • route changes, dynamic sharing • does not upset stability • 4.4: small network buffer • at least like TCP • adapt a on slow timescale, but how? • 6.2: TCP-friendliness • friendly at least at small window • tunable, but how to tune? • reverse path congestion • should react? rare for large transfer?

  48. IP Rights • Caltech owns IP rights • applicable more broadly than TCP • leave all options open • Will license free at least for education & research community • Will be flexible to facilitate wide deployment

  49. http://netlab.caltech.edu/FAST • FAST TCP: motivation, architecture, algorithms, performance. submitted for publication, July 1, 2003 • FAST TCP for high-speed long-distance networks. draft-jin-wei-low-tcp-fast-01.txt, June 30, 2003 • b-release: August 2003 Inquiry: fast-support@cs.caltech.edu

  50. SC2002 Network OC48 OC192 (Sylvain Ravot, caltech)

More Related