Download The Future of Transport Protocols

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts
no text concepts found
Transcript
The Future of Transport
Hari Balakrishnan
LCS and EECS
Massachusetts Institute of Technology
http://www.sds.lcs.mit.edu/~hari
[email protected]
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
r2
r3
Put everyone on same
ordered byte stream
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.
What We Really Need…
Apps
Transport
instances
Congestion
management
IP
Per-host &
per-domain
information
An integrated approach to end-to-end
congestion management for the Internet
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 transportaware 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), mediaaccess, 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)
