FAST TCP: design and experiments

FAST TCP:design and experiments Cheng Jin David Wei Steven Low http://netlab.caltech.edu

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.

Problem: binary signal TCP oscillation

Solution: multibit signal FAST stabilized

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

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

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)

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

Dynamic sharing: 3 flows FAST Linux Steady throughput HSTCP STCP

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

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

Open issues • network latency estimation • route changes, dynamic sharing • does not upset stability • small network buffer • at least like TCP • adapt a on slow timescale, but how? • TCP-friendliness • friendly at least at small window • tunable, but how to tune? • reverse path congestion

What can FAST do? • Networks that support large windows • Long latency • High bandwidth • Networks experience moderate packet losses • HTTP traffic • Low-bandwidthnetworks and LANs

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

FAST TCP: design and experiments