The Internet Congestion Manager

1
The Internet Congestion Manager

• Hari Balakrishnan
• MIT Laboratory for Computer Science
• http//wind.lcs.mit.edu/
• CM team
• Dave Andersen, Deepak Bansal, Dorothy Curtis,
  Bodhi Priyantha, Srinivasan Seshan

2
Motivation

• End-systems implement many functions
• Reliability
• In-order delivery
• Demultiplexing
• Message boundaries
• Connection abstraction
• Congestion control

Of these, congestion control MUST be done for all
communications
3
State of Congestion Control

• Multimedia Transmissions Drive Net Toward
  Gridlock
• Sara Robinson New York Times 8/23/99

4
Two Issues

• Adaptation
• Enable applications to learn about network
  conditions and adapt
• Concurrent flows
• Efficiently multiplex streams and share paths

Congestion Manager (CM) A new end-system
architecture for congestion management
5
Adaptation
Application

• Little information transferred
• across layers to applications
• More more non-TCP applications

Transport

• Available bandwidth
• Round-trip times
• Loss information

Network
Link
Physical networks
CM exports a simple adaptation API
6
Concurrent Flows

• Overload causes congestion

Additive-Increase Multiplicative-Decrease (AIMD)
Window
Slow start
Time

• Concurrent streams compete, causing aggressive
  network behavior!

CM abstracts all congestion-related information
into one place
7
What Can We Do?

• Inside-the-network smarts
• RED and variants
• Fair queueing and variants
• Differentiated services
• Integrated services
• End-system architecture
• Leverage a decade of experience
• Interact well with router mechanisms

8
The Big Picture
HTTP
Video1
Audio
Video2
TCP1
TCP2
UDP
API
IP
All congestion management tasks performed in
CM Apps learn and adapt using API
9
The CM Architecture
Application (TCP, http, video, etc.)
Application
API
API
Hints Dispatch
Congestion Controller
Scheduler
Responder
Congestion Detector
Prober
CM protocol
Sender
Receiver
10
Problems

• How does CM control when and whose transmissions
  occur?
• Keep application in control of what to send
• How does CM discover network state?
• What information is shared?
• What is the granularity of sharing?

Key issues API and information sharing
11
Transmission API

• Buffered-send
• Does not allow apps to pull back data

cm_send( ,dst)
Lesson move buffering into the application
12
Transmission API (cont.)

• Callback-based send

Schedule requests, not packets
cm_notify(nsent)
Enables apps to adapt at the last instant
13
Transmission API (cont.)

• Request API works for asynchronous sources
• wait for (some_events)
• get_data() / e.g., from a file, image
  capture, etc. /
• send() / call cm_request() and send on
  callback /
• But what about synchronous sources (e.g., audio
  with constant sampling rate)?
• do_every_t_ms / timer loop /
• get_data()
• send() / oops, waiting for send callback
  wrecks timing /
• Solution rate-change callback cmapp_update(ra
  te, srtt)

14
Feedback about Network State

• Monitoring successes and losses
• Application hints
• Probing system
• Notification API (application hints)
• Application calls cm_update(nsent, nrecd,
  congestion indicator, rtt)

15
Probing System

• Receiver modifications necessary
• Support for separate CM header
• Uses sequence number to detect losses
• Sender can request count of packets received
• Receiver modifications detected/negotiated via
  handshake
• For incremental deployment

IP header
CM header
IP payload
IP payload
16
Congestion Controller

• Responsible for deciding when to send a packet
• Window-based AIMD with traffic shaping
  (TCP-friendly)
• Exponential aging when feedback low
• Halve window every RTT (use min RTT)
• Can plug in other algorithms
• Selected on a macroflow granularity

17
CM Scheduler

• Responsible for deciding who should send a packet
  
• Currently hierarchical round robin
• Hints from application or receiver
• Used to prioritize flows
• Plug in other algorithms
• Selected on a macroflow granularity
• Prioritization interface may be different

18
How will apps use the CM?

• TCP
• Asynchronous callback API
• HTTP
• Rate callbacks to decide content
• Congestion controlled UDP
• Buffered API
• Conferencing applications
• Synchronous API for real-time streams
• Combination of others for other streams

19
TCP/CM
TCP (reliability,conn. mgmt.)
CM
IP
Steps 2-6 occur multiple times
20
CM Web Performance
TCP Newreno
Sequence number
With CM
Time (s)
CM greatly improves predictability and consistency
21
Layered Streaming Audio
Competing TCP
TCP/CM
Sequence number
Audio/CM
Time (s)

• Audio adapts to available bandwidth
• Combination of TCP Audio compete equally with
  normal TCP

22
Status Future

• Implementation in progress (Linux)
• TCP/CM Web server
• Layered audio server
• Congestion-controlled UDP sockets
• Modify clients to reflect user preferences
• Handling diffserv and traffic splitters
• Aggregation per-host, per-subnet,
• Feedback frequency analysis
• Aging of congestion information

23
Deployment Issues

• In the long-term, change senders and receivers to
  use the CM
• In the short-term, change only senders e easier
  deployment
• Requires receiver app feedback (e.g., TCP ACKs)
• CM protocol and headers negotiable e incremental
  deployment
• IETF working group to be formed

24
Summary

• CM enables proper and stable congestion behavior
• Simple API to enable application to learn and
  adapt to network state
• Improves consistency and predictability of
  network transfers
• Provides benefit even when deployed at senders
  alone

25
Why Not Persistent Connections?
r1
Put flows on same ordered byte stream
r2
r3
Server
Client
r-n

• Different flows have different reliability
  semantics
• Loss of packet stalls all other flows!