12
The Future of Transport Hari Balakrishnan LCS and EECS Massachusetts Institute of Technology http://www.sds.lcs.mit.edu/~hari [email protected]

The Future of Transport Hari Balakrishnan LCS and EECS Massachusetts Institute of Technology hari [email protected]

Embed Size (px)

Citation preview

Page 1: The Future of Transport Hari Balakrishnan LCS and EECS Massachusetts Institute of Technology hari hari@lcs.mit.edu

The Future of Transport

Hari Balakrishnan

LCS and EECS

Massachusetts Institute of Technology

http://www.sds.lcs.mit.edu/~hari

[email protected]

Page 2: The Future of Transport Hari Balakrishnan LCS and EECS Massachusetts Institute of Technology 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

Page 3: The Future of Transport Hari Balakrishnan LCS and EECS Massachusetts Institute of Technology hari hari@lcs.mit.edu

State-of-the-World, Yesterday (& Today!)

r1r1

r-nr-n

r3r3

r2r2

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)

Page 4: The Future of Transport Hari Balakrishnan LCS and EECS Massachusetts Institute of Technology hari hari@lcs.mit.edu

State-of-the-World, Today

r1r1

r-nr-n

r3r3

r2r2Put 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

Page 5: The Future of Transport Hari Balakrishnan LCS and EECS Massachusetts Institute of Technology hari hari@lcs.mit.edu

What is the World Heading Toward?

u1u1

u-mu-m

u3u3

u2u2

• The world won’t be just HTTP

• The world won’t be just TCP

r1r1

r2r2

r3r3

r-nr-n

Logically different streams (objects) should be kept separate, yet congestion management must be performed.

Page 6: The Future of Transport Hari Balakrishnan LCS and EECS Massachusetts Institute of Technology hari hari@lcs.mit.edu

What We Really Need…

An integrated approach to end-to-end congestion management for the Internet

IP

Apps

Transportinstances

Congestionmanagement

Per-host & per-domaininformation

Page 7: The Future of Transport Hari Balakrishnan LCS and EECS Massachusetts Institute of Technology hari hari@lcs.mit.edu

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)

Page 8: The Future of Transport Hari Balakrishnan LCS and EECS Massachusetts Institute of Technology hari hari@lcs.mit.edu

Heterogeneous Technologies

• Non-congestion losses (“errors”)

• Asymmetry Bandwidth Latency (delay variations)

• Pipe sizes Large pipes Small pipes

Page 9: The Future of Transport Hari Balakrishnan LCS and EECS Massachusetts Institute of Technology hari hari@lcs.mit.edu

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

Page 10: The Future of Transport Hari Balakrishnan LCS and EECS Massachusetts Institute of Technology hari hari@lcs.mit.edu

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)

Page 11: The Future of Transport Hari Balakrishnan LCS and EECS Massachusetts Institute of Technology hari hari@lcs.mit.edu

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”

Page 12: The Future of Transport Hari Balakrishnan LCS and EECS Massachusetts Institute of Technology hari hari@lcs.mit.edu

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)