Adaptive Transmission Protocols for the Future Internet

1
Adaptive Transmission Protocols for the Future
Internet

• Hari Balakrishnan
• MIT Lab for Computer Science
• http//www.sds.lcs.mit.edu/hari

2
Internet Service Model
Internet
Router
A best-effort network losses reordering can
occur

• 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

3
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

4
Problem 1 The Web!
r1
r2
r3
Server
Client
r-n

• Multiple reliable streams
• Individual objects are small
• So what?
• Far too inefficient!
• Far too aggressive!

5
Problem 2 Application Heterogeneity
u1
r1
u2
r2
u3
r3
Server
Client
u-m
r-n

• New applications (e.g., real-time streams)
• The world isnt only about HTTP or even TCP!
• So what?
• Applications do not adapt to congestion
• Long-term Internet stability is threatened

6
Problem 3 Technology Heterogeneity

• Tremendous diversity
• So what?
• Awful performance
• Mobility-related inefficiencies

7
Why is Efficient Transport Hard?

• Congestion
• Channel errors
• Asymmetry
• Latency variability
• Packet reordering
• Mobility
• Large network pipes
• Small network pipes

8
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

9
This Talk

• Congestion
• Channel errors
• Asymmetry
• Latency variability
• Packet reordering
• Mobility
• Large network pipes
• Small network pipes

10
TCP Overview

• Loss recovery

7
8
6
10
5
9
4
3
1
0
1
1
lost
2
0
1
1
Timeouts based on mean round-trip time (RTT) and
deviation Fast retransmissions based on
duplicate ACKs

• Congestion control
• Window-based algorithm to determine sustainable
  rate
• Upon congestion, reduce window
• ACK clocking sends data smoothly

11
TCP Dynamics
Data
Sequence number (bytes)
ACKs
Time (s)
12
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

13
Solution 1 Persistent Connections
r1
Put everyone on same ordered byte stream
r2
r3
Server
Client
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
3. Does not enable application adaptation
14
Solution 2 Web Accelerators

• Is your Web experience too slow?
• Chances are, its because of pesky TCP congestion
  control and those annoying timeouts
• Web accelerators will greatly speed up your
  transfers
• By just adjusting TCPs congestion control!
• Who cares if the Internet is stable or not?

15
Solution 3 Integrated TCP Sessions
r1
r2
r3
Server
Client
r-n

• Independent TCP connections, but shared control
  parameters BPS98, Touch98
• Shared congestion windows, round-trip estimates
• But, this approach doesnt accomodate non-TCP
  traffic

16
What is the World Heading Toward?
u1
r1
u2
r2
u3
r3
Server
Client
u-m
r-n

• The world wont be just HTTP
• The world wont be just TCP

Logically different streams (objects) should be
kept separate, yet efficient congestion
management must be performed.
17
What We Really Need
HTTP
Video1
Audio
Video2
TCP1
TCP2
UDP
IP

• An integrated approach to end-to-end congestion
  management for the Internet using the CM

18
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

19
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

20
How the API Works
CM does not buffer any data request/callback/noti
fy API
21
Preliminary Results

• Simulation results show significant improvements
  in performance predictability
• E.g., TCP with CM reduces timeouts and shares
  bandwidth well between connections
• CMs internal congestion algorithm is rate-based
• Great platform for experimenting with new
  control schemes
• Experiments with scheduling algorithms planned
• Proxy receiver hosts are problematic

22
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)

23
This Talk

• Congestion
• Channel errors
• Asymmetry
• Latency variability
• Packet reordering
• Mobility
• Large network pipes
• Small network pipes

24
TCP/Wireless Performance Today
25
Channel Errors
Router
Loss ? Congestion
26
Performance Degradation
Best possible TCP with no errors (1.30 Mbps)
TCP Reno (280 Kbps)
Sequence number (bytes)
Time (s)
2 MB wide-area TCP transfer over 2 Mbps Lucent
WaveLAN
27
Conventional Approaches

• Link-layer protocols LC83

Base Station

• Adverse interactions with transport layer
• Timer interactions DCY93
• Interactions with fast retransmissions
• Large end-to-end round-trip time variation

ARQ/FEC

• Hard state at base station
• Complicates mobility
• Vulnerable to failures
• Violates end-to-end semantics

28
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?

29
Snoop Protocol FH to MH
1
2
3
Snoop agent
Base Station
FH Sender

• 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

Mobile Host
30
Snoop Protocol FH to MH
Snoop Agent
Base Station
FH Sender
Mobile Host
31
Snoop Protocol FH to MH
5
Base Station
FH Sender
Mobile Host
32
Snoop Protocol FH to MH
1
2
3
Base Station
FH Sender
Mobile Host
33
Snoop Protocol FH to MH
6
1
2
3
5
Base Station
3
Sender
Mobile Host
34
Snoop Protocol FH to MH
1
2
3
Base Station
Sender
ack 0
Duplicate ACK
Mobile Host
1
35
Snoop Protocol FH to MH
1
2
3
Base Station
Retransmit from cache at higher priority
Sender
ack 0
ack 0
ack 0
Mobile Host
1
36
Snoop Protocol FH to MH
1
2
3
Base Station
Sender
ack 0
Suppress Duplicate Acks
ack 4
Mobile Host
1
37
Snoop Protocol FH to MH
Clean cache on new ACK
Base Station
Sender
ack 4
5
ack 5
38
Snoop Protocol FH to MH
Base Station
Sender
ack 4
ack 5
1
ack 6
Mobile Host
39
Snoop Protocol FH to MH
7
9
8
Base Station
Sender
ack 5
ack 6
1
6
Mobile Host
40
Snoop Performance Improvement
Best possible TCP (1.30 Mbps)
Snoop (1.11 Mbps)
TCP Reno (280 Kbps)
Sequence number (bytes)
Time (s)
Time (s)
2 MB wide-area TCP transfer over 2 Mbps Lucent
WaveLAN
41
Benefits of TCP-Awareness
Snoop
Congestion Window (bytes)
LL (no duplicate ack suppression)
0
0
10
20
30
40
50
60
70
80
Time (sec)

• 30-35 improvement for Snoop LL congestion
  window is small (but no coarse timeouts occur)
• Connection bandwidth-delay product 25 KB

42
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

43
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
Link-aware transport (Explicit Loss Notification)
Network
Link
Transport-aware link(Snoop agent at BS)
Physical
44
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