120 likes | 270 Views
The Future of Transport. Hari Balakrishnan LCS and EECS Massachusetts Institute of Technology http://www.sds.lcs.mit.edu/~hari hari@lcs.mit.edu. Focus. Congestion management New applications New application traffic patterns Heterogeneous technologies Wireless Asymmetric networks
E N D
The Future of Transport Hari Balakrishnan LCS and EECS Massachusetts Institute of Technology http://www.sds.lcs.mit.edu/~hari hari@lcs.mit.edu
Focus • Congestion management • New applications • New application traffic patterns • Heterogeneous technologies • Wireless • Asymmetric networks • Large and small pipe size technologies
State-of-the-World, Yesterday (& Today!) r1 r2 r3 Independent TCP streams r-n 1. Far too inefficient (multiple slow starts, etc.) 2. More alarmingly, far too aggressive n connections, 1 sees loss; window decreases only by (1 - 1/2n)
State-of-the-World, Today r1 Put everyone on same ordered byte stream r2 r3 r-n While this fixes some of the problems of independent connections, it really is a step in the wrong direction! 1. Far too much coupling between objects 2. Far too application-specific
What is the World Heading Toward? u1 r1 u2 r2 u3 r3 u-m r-n • The world won’t be just HTTP • The world won’t be just TCP Logically different streams (objects) should be kept separate, yet congestion management must be performed.
Per-host & per-domaininformation Congestionmanagement What We Really Need… Apps An integrated approach to end-to-end congestion management for the Internet Transportinstances IP
Some Salient Features • Shared learning • Heterogeneous application support • Simple application interfaces to congestion manager • Robust and stable network behavior • Flexible bandwidth-apportioning using receiver hints • First step: Transport-Independent Congestion Control (TICC)
Heterogeneous Technologies • Non-congestion losses (“errors”) • Asymmetry • Bandwidth • Latency (delay variations) • Pipe sizes • Large pipes • Small pipes
Errors + Congestion • Some people think that we need to split connections to perform well: This is wrong! • Careful design of link-layer and transport-aware link protocols work very well • Explicit Loss Notification (ELN) helps sender decouple loss recovery from congestion control
Asymmetry • Network and traffic characteristics in one direction affect performance in the other • Bandwidth, latency (variability), media-access, loss rate… • TCP improvements • ACK filtering (purge “redundant” ACKs) • Sender adaptation (rate-controlled transmissions, byte-based window increases) • ACK reconstruction • ACK congestion control (Padmanabhan98)
Pipe sizes • Large pipes are problematic • Timeouts when multiple losses occur • SACK fixes this (plus timestamp, PAWS, etc.) • The rtt-bias unfairness problem remains… • How big an rtt before TCP is unusable? • Small pipes are the more pressing problem! • Far too many timeouts • 55% of all recovery in one traffic trace of a busy Web server (over 1.6 million connections) • A solution: Newreno + Enhanced Recovery (ER) • Follow packet conservation, sending new probe packets upon duplicate ACKs • No timeouts unless congestion is “persistent”
Conclusions: Revolution or Evolution? • A revolution in congestion management • To accommodate heterogeneous applications • But incremental deployability is critical • And then there’s multicast... • An evolutionary approach to changing TCP • But with revolutionary “local” techniques • Changes to end-to-end mechanisms (e.g., elements of rate control)