Upload
edward-skinner
View
222
Download
5
Tags:
Embed Size (px)
Citation preview
Adaptive Transmission Protocols for the Future
Internet
Hari BalakrishnanMIT Lab for Computer Science
http://www.sds.lcs.mit.edu/~hari
Internet Service Model
• Congestion due to overload causes losses• Transmission protocols provide end-to-
end data transport– Loss recovery (if reliability is important)– Congestion management (to reduce
instability)– Connection setup/teardown
Internet
A best-effort network: losses & reordering can occur
Router
Transmission Protocols
• User Datagram Protocol (UDP)– Simple datagram delivery– Other protocols built on top (e.g., RTP for
video)
• Transmission Control Protocol (TCP) – Reliable, in-order byte stream delivery– Loss recovery & congestion control
• TCP is dominant today, and is tuned for:– Long-running transfers– Wired links and symmetric topologies
Problem #1: The Web!
r1r1
r-nr-n
r3r3
r2r2
ServerClient
• Multiple reliable streams• Individual objects are small• So what?
Far too inefficient!Far too aggressive!
Internet
Problem #2: Application Heterogeneity
u1u1
u-mu-m
u3u3
u2u2r1r1
r2r2
r3r3
r-nr-n
Server
• New applications (e.g., real-time streams)– The world isn’t only about HTTP or even TCP!
• So what?Applications do not adapt to congestionLong-term Internet stability is threatened
Internet
Client
Problem #3: Technology Heterogeneity
In-Building
Campus-Area Packet Radio
Metro-Area
Regional-Area+
Asymmetry
Cellular DigitalPacket Data (CDPD)
Metricom Ricochet Lucent WaveLAN
IBM Infrared
• Tremendous diversity• So what?
Awful performanceMobility-related inefficiencies
Why is Efficient Transport Hard?
• Congestion• Channel errors• Asymmetry• Latency variability• Packet reordering• Mobility• Large network “pipes”• Small network “pipes”
Solution: Adaptive Transmissions
• A framework to adapt to various network conditions
• Guiding principle: the end-to-end argument– Do only the “right” amount inside the network– Expose important information to applications
• Algorithms to adapt to different conditions• Wanted: A grand unified architecture for
Internet data transport
This Talk• Congestion• Channel errors• Asymmetry• Latency variability• Packet reordering• Mobility• Large network “pipes”• Small network “pipes”
0
TCP Overview
8
11
76
13
4
12 lost1
5
Timeouts based on mean round-trip time (RTT) and deviationFast retransmissions based on duplicate ACKs
0
109
• Congestion control– Window-based algorithm to determine
sustainable rate– Upon congestion, reduce window– “ACK clocking” sends data smoothly
• Loss recovery
Congestion Management Challenges
• Heterogeneous traffic mix• Multiple concurrent streams• Variety of applications and
transports• Control algorithms must be stable• Clean separation from other tasks
like loss recovery
“Solution” #1: Persistent Connections
r1r1
r-nr-n
r3r3
r2r2Put everyone on same
ordered byte stream
While this fixes some of the problems of independentconnections, it really is a step in the wrong direction!
1. Far too much coupling between objects2. Far too application-specific3. Does not enable application adaptation
ServerClient
“Solution” #2: Web Accelerators
• Is your Web experience too slow?• Chances are, it’s because of pesky TCP
congestion control and those annoying timeouts
• Web accelerators will greatly speed up your transfers…
• By just “adjusting” TCP’s congestion control!
• Who cares if the Internet is stable or not?
“Solution” #3: Integrated TCP Sessions
r1r1
r-nr-n
r3r3
r2r2
• Independent TCP connections, but shared control parameters [BPS+98, Touch98]• Shared congestion windows, round-trip estimates• But, this approach doesn’t accomodate non-TCP traffic
ServerClient
What is the World Heading Toward?
• The world won’t be just HTTP• The world won’t be just TCP
Logically different streams (objects) should be kept separate, yet efficient congestion
management must be performed.
u1u1
u-mu-m
u3u3
u2u2r1r1
r2r2
r3r3
r-nr-n
Server
Internet
Client
What We Really Need…
An integrated approach to end-to-end congestion management for the Internet using the CM
IP
HTTP Video1
TCP1 TCP2 UDP
Audio Video2
CongestionManager
CM: Some Salient Features
• Shared learning– Maintains host- and domain-specific information
• Heterogeneous application support• Simple application interfaces to CM• Robust and stable rate control algorithms• Flexible bandwidth-apportioning using
receiver hints• Enables application adaptation to
congestion and changing bandwidth
The CM API• A simple but powerful application-to-
CM API• Three classes of functions
– Query– Control – Application callback
• Design principle: Application-Level Framing (ALF)– Feed information up to application– Application decides what to send; CM tells
it how fast
How the API Works
CM does not buffer any data; request/callback/notify API
Preliminary Results
• Simulation results show significant improvements in performance predictability– E.g., TCP with CM reduces timeouts and shares
bandwidth well between connections
• CM’s internal congestion algorithm is rate-based– Great platform for experimenting with new control
schemes
• Experiments with scheduling algorithms planned
• Proxy receiver hosts are problematic
Summary & Status• The CM provides a simple API to make
applications adaptive and network-aware– Enables all traffic to adhere to basic
congestion control principles– Improves performance predictability– Enables shared state learning
• ns-2 experiments in progress• Linux implementation coming soon
(including rate-adaptive applications)
This Talk• Congestion• Channel errors• Asymmetry• Latency variability• Packet reordering• Mobility• Large network “pipes”• Small network “pipes”
TCP/Wireless Performance TodayTechnology Rated
BandwidthTypical TCPThroughput
IBMInfrared
1 Mbps 100-800 Kbps
LucentWaveLAN
2 Mbps 50 Kbps-1.5 Mbps
MetricomRicochet
100 Kbps 10-35 Kbps
Hybrid wirelesscable
10 Mbps 0.5-3.0 Mbps
Goal: To bridge the gap between perceived and rated performance
Channel Errors
Internet
Router
Loss Congestion23
21
Loss ==> Congestion
210
Burst losses lead to coarse-grained timeouts
Result: Low throughput
Performance Degradation
0.0E+00
5.0E+05
1.0E+06
1.5E+06
2.0E+06
0 10 20 30 40 50 60
Time (s)
Seq
uenc
e nu
mbe
r (b
ytes
)
TCP Reno(280 Kbps)
Best possible TCP with no errors(1.30 Mbps)
2 MB wide-area TCP transfer over 2 Mbps Lucent WaveLAN
Our Solution: Snoop Protocol
• Shield TCP sender from wireless vagaries– Eliminate adverse interactions between protocol
layers– Congestion control only when congestion occurs
• The End-to-End Argument [SRC84]– Preserve TCP/IP service model: end-to-end
semantics– Is connection splitting fundamentally important?
• Eliminate non-TCP protocol messages– Is link-layer messaging fundamentally important?
Fixed to mobile: transport-aware link protocolMobile to fixed: link-aware transport protocol
Snoop Protocol: FH to MH
FH Sender
Mobile Host
Base Station5
1
12346
Snoop agent: active interposition agent– Snoops on TCP segments and ACKs– Detects losses by duplicate ACKs and timers– Suppresses duplicate ACKs from FH sender
Cross-layer protocol design: snoop agent state is soft
Snoop agent
Snoop Protocol: FH to MH
Mobile Host
1Base Station
Snoop Agent
FH Sender
Snoop Protocol: FH to MH
Mobile Host
1234Base Station
5
FH Sender
Snoop Protocol: FH to MH
Mobile Host
Base Station5
1
12346
FH Sender
Snoop Protocol: FH to MH
Mobile Host
5
1234
Base Station
32
6
21
Sender
Snoop Protocol: FH to MH
Mobile Host
61234
Base Station
43
1
5
2
ack 0
Sender
Duplicate ACK
Snoop Protocol: FH to MH
Mobile Host
1234
Base Station
1
1
56
4 3 2
Sender
Retransmit from cacheat higher priority
ack 0
ack 0
ack 0
65
Snoop Protocol: FH to MH
Mobile Host
1234
Base Station
1
1
SuppressDuplicate Acks
56
4 3 2
Sender 5
ack 0
ack 4
Snoop Protocol: FH to MH
Base Station
6
56
1 4 3 25
Senderack 4
ack 5
Clean cache on new ACK
Snoop Protocol: FH to MH
Mobile Host
Base Station
6 5 4 3 21
Senderack 4
6
ack 6
ack 5
Snoop Protocol: FH to MH
Mobile Host
Base Station
5 4 3 21
Active soft state agent at base stationTransport-aware reliable link protocolPreserves end-to-end semantics
6
Senderack 5 ack 6
789
0.0E+00
5.0E+05
1.0E+06
1.5E+06
2.0E+06
0 10 20 30 40 50 60
Bestpossible TCP (1.30 Mbps)
Snoop Performance Improvement
Time (s)Time (s)
Seq
uenc
e nu
mbe
r (b
ytes
)
Snoop (1.11 Mbps)
TCP Reno(280 Kbps)
2 MB wide-area TCP transfer over 2 Mbps Lucent WaveLAN
Benefits of TCP-Awareness
• 30-35% improvement for Snoop: LL congestion window is small (but no coarse timeouts occur)
• Connection bandwidth-delay product = 25 KB
00 10 20 30 40 50 60 70 80
20000
30000
40000
50000
60000
10000
Time (sec)
Con
gest
ion
Win
dow
(by
tes)
LL (no duplicate ack suppression)
Snoop
Suppressing duplicate acknowledgments and TCP-awareness leads to better utilization of link bandwidth and performance
Snoop Protocol Status
• BSD/OS implementation – Integrated with Daedalus low-latency handoff software
• Version 1 released 1996; Version 2 released 1998
• In daily production use at Berkeley and UC Santa Cruz
• Several hundred downloads– Ports to Linux, FreeBSD, NetBSD
Summary: Wireless Bit-Errors
• Problem: wireless corruption mistaken for congestion
• Solution: Snoop Protocol• General lessons
– Lightweight soft-state agent in network infrastructure • Guided by the End-to-End Argument• Fully conforms to the IP service model
– Cross-layer protocol design & optimizations
Transport
Network
Link
Physical
Link-aware transport (Explicit Loss Notification)
Transport-aware link(Snoop agent at BS)
Conclusions• Efficient data transport is a hard problem:
congestion, errors, asymmetry,...• Adaptive transmission schemes are essential in
the future Internet• Architectural components should include
– Congestion Manager (CM)– Error-handlers (e.g., Snoop protocol)– (And many other features)
• Wanted: a grand unified transmission architecture for resource management and application adaptation