Adaptive Transmission Protocols for the Future Internet

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