590 likes | 689 Vues
Explore the motivation, approach, and architecture of FAST TCP designed by Cheng Jin, David Wei, Steven Low at Caltech. Learn about the performance, stability, and implementation strategies for increased efficiency in data transmission.
E N D
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 • Aiken, Doraiswami, Yip • Level(3) • Fernes • LANL • Wu
Outline • Motivation • Approach • Architecture
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)
ACK: W W + 1/W Loss: W W – 0.5W • Packet level • Flow level • Equilibrium • Dynamics packets Packet & flow level Reno TCP (Mathis formula)
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.
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)
Stable: 20ms delay Window Ns-2 simulations, 50 identical FTP sources, single link 9 pkts/ms, RED marking
Queue Stable: 20ms delay Window Ns-2 simulations, 50 identical FTP sources, single link 9 pkts/ms, RED marking
Unstable: 200ms delay Window Ns-2 simulations, 50 identical FTP sources, single link 9 pkts/ms, RED marking
Queue Unstable: 200ms delay Window Ns-2 simulations, 50 identical FTP sources, single link 9 pkts/ms, RED marking
30% noise avg delay 16ms 20ms 30% noise avg delay 208ms 200ms Flow level (in)stability isrobust
ns-2 simulation Instability reduces utilization capacity = 155Mbps, 622Mbps, 2.5Gbps, 5Gbps, 10Gbps; 100 ms RTT and 100 flows J. Wang (Caltech, June 02)
Outline • Motivation • Approach • Architecture
ACK: W W + 1/W Loss: W W – 0.5W • Packet level • Flow level • Equilibrium • Dynamics packets Packet & flow level Reno TCP (Mathis formula)
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.
Problem: binary signal TCP oscillation
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
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!
Solution: multibit signal FAST stabilized
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)
FAST Conv Slow Start Equil Loss Rec Solution: estimate target • FAST Scalable to any w*
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
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)
Outline • Motivation • Approach • Architecture
Reno TCP • Packet level • Designed and implemented first. • Flow level • Understood afterwards. Packet level design of FAST, HSTCP, STCP guided by flow level properties
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
~ Ack timescale ~ RTT timescale Ack timescale Data Control Window Control Burstiness Control Estimation TCP Protocol Processing Architecture
Architecture Each component • designed independently • upgraded asynchronously Data Control Window Control Burstiness Control Estimation TCP Protocol Processing
Data Control • Determines the order of transmission. • Important during recovery, especially at large windows. • Linux loss recovery tightly coupled with Window Control.
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.
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.
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.
Data Control Window Control Burstiness Control Estimation TCP Protocol Processing Architecture Each component • designed independently • upgraded asynchronously Window Control
Window control algorithm • Full utilization • regardless of bandwidth-delay product • Globally stable • exponential convergence • Fairness • weighted proportional fairness • parameter a
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)
Dynamic sharing: 3 flows FAST Linux Dynamic sharing on Dummynet • capacity = 800Mbps • delay=120ms • 3 flows • iperf throughput • Linux 2.4.x (HSTCP: UCL)
Dynamic sharing: 3 flows FAST Linux Steady throughput HSTCP STCP
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
30min queue Room for mice ! FAST Linux loss throughput HSTCP STCP HSTCP
ideal performance Aggregate throughput Dummynet: cap = 800Mbps; delay = 50-200ms; #flows = 1-14; 29 expts
small window 800pkts large window 8000 Aggregate throughput Dummynet: cap = 800Mbps; delay = 50-200ms; #flows = 1-14; 29 expts
HSTCP ~ Reno Jain’s index Fairness Dummynet: cap = 800Mbps; delay = 50-200ms; #flows = 1-14; 29 expts
stable in diverse scenarios Stability Dummynet: cap = 800Mbps; delay = 50-200ms; #flows = 1-14; 29 expts
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
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?
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
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
SC2002 Network OC48 OC192 (Sylvain Ravot, caltech)