1 / 12

The Future of Transport

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

saniya
Download Presentation

The Future of Transport

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. The Future of Transport Hari Balakrishnan LCS and EECS Massachusetts Institute of Technology http://www.sds.lcs.mit.edu/~hari hari@lcs.mit.edu

  2. Focus • Congestion management • New applications • New application traffic patterns • Heterogeneous technologies • Wireless • Asymmetric networks • Large and small pipe size technologies

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

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

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

  6. Per-host & per-domaininformation Congestionmanagement What We Really Need… Apps An integrated approach to end-to-end congestion management for the Internet Transportinstances IP

  7. 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 • Congestion Manager (CM)

  8. Heterogeneous Technologies • Non-congestion losses (“errors”) • Asymmetry • Bandwidth • Latency (delay variations) • Pipe sizes • Large pipes • Small pipes

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

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

  11. 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”

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

More Related