The Future of Transport Hari Balakrishnan LCS and EECS Massachusetts Institute of Technology

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

State-of-the-World, Yesterday (& Today!) r1 r-n r3 r2 Independent TCP streams 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 r-n r3 r2 Put everyone on same ordered byte stream 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 u-m u3 u2 The world won’t be just HTTP The world won’t be just TCP r1 r2 r3 r-n Logically different streams (objects) should be kept separate, yet congestion management must be performed.

What We Really Need… An integrated approach to end-to-end congestion management for the Internet IP Apps Transport instances Congestion management Per-host & per-domain information

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 o Bandwidth o Latency (delay variations) Pipe sizes o Large pipes o 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 o ACK filtering (purge “redundant” ACKs) o Sender adaptation (rate-controlled transmissions, byte-based window increases) o ACK reconstruction o ACK congestion control (Padmanabhan98)

Pipe sizes Large pipes are problematic o Timeouts when multiple losses occur o SACK fixes this (plus timestamp, PAWS, etc.) o The rtt-bias unfairness problem remains… o How big an rtt before TCP is unusable? Small pipes are the more pressing problem! o Far too many timeouts 55% of all recovery in one traffic trace of a busy Web server (over 1.6 million connections) o 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 o To accommodate heterogeneous applications o But incremental deployability is critical o And then there’s multicast... An evolutionary approach to changing TCP o But with revolutionary “local” techniques o Changes to end-to-end mechanisms (e.g., elements of rate control)