1. End-to-end Congestion Management for the NGI
Hari Balakrishnan
MIT Laboratory for Computer Science
DARPA NGI PI Meeting
October 2, 2000
Srinivasan Seshan (CMU), Frans Kaashoek (MIT)
Dave Andersen, Deepak Bansal, Dorothy Curtis, Nick Feamster

2. iNAT Project: Motivation
Increasing heterogeneity in the Internet
Nodes: Mobiles, devices, sensors,...
Links: Optical, wireless,...
Services & applications: Web, telepresence, streaming, remote device control
Need a general solution for applications to discover resources and deal with mobility
Need a general framework for learning about and adapting to changing network conditions

3. iNAT Approach Intelligent naming Adaptive transmission
Resource discovery: Intentional Naming System (INS) using expressive names and self-configuring name resolver overlay network
Mobility: Via dynamic name updates and secure connection migration (check out demo!)
Adaptive transmission
End-system congestion management and adaptation framework for the NGI
Congestion Manager software and algorithms

4. The Problem End-to-end congestion management is essential
Reacting when congestion occurs
Probing for spare bandwidth when it doesn’t
The future isn’t about just TCP!
Many applications are inherently adaptive, but they don’t adapt today
Enable applications to learn about network conditions
Many applications use concurrent flows between sender and receiver, which has adverse effects
Enable efficient multiplexing and path sharing
What are some key features of the world I just described?
- Lots of heterogeneity
- Much higher levels of dynamism than today
- Much more decentralized and needs much more robustness
- allow for tetherless operation
Congestion Manager (CM): A new end-system architecture for congestion management

5. The Big Picture IP HTTP Audio Video1 Video2 Per-”macroflow” statistics
(cwnd,rtt,…)
TCP1
TCP2
UDP
API
Congestion
Manager IP
Flows aggregated into macroflows to share congestion state
All congestion management tasks performed in CM
Apps learn and adapt using API

6. CM Architecture Sender Receiver Application (TCP, HTTP, RTP, etc.)
feedback
Application
API
API
cm_update(feedback)
Congestion
Detector
Hints
Dispatch
Congestion
Controller
Scheduler
Sharing macroflow
bandwidth
Deciding who
can send
Requirements of api and probing sys result in following arch..
Cong ctl is repository of cong info… it gets info from the application hints as well as probing system… it implements
Cong ctl algorithms and decides when and how fast data should be sent
Once it decides data can be sent.. Control is passed to scheduler…. Sched decides which active application should be able to send.
Probing system interacts with receiver’s cong detector and responder to detect losses using cm protocol
Implemented in ns now and ongoing implementation in linux
Stable controls
Deciding when
to send
Responder
Prober CM
protocol

7. Lesson: move buffering into the application
Transmission API
Traditional kernel buffered-send has problems
Does not allow app to “pull back” data
App CM IP
Rate change
cm_send( ,dst)
Can’t pull out and re-encode
Packets queued
to dst
Lesson: move buffering into the application

8. Transmission API (cont.)
Callback-based send
App CM IP
cm_request()
send( )
cmapp_send() based on
allowed rate
Schedule requests,
not packets
Enables apps to adapt “at the last instant”

9. Benefits of macroflow sharing
Shared learning
Avoids overly aggressive behavior
Good for Internet stability and fairness
Adoption incentives
More consistent performance of concurrent downloads
Avoids independent slow-starts and improves response times
Beats persistent-connection HTTP on interactive performance by allowing parallel downloads

10. predictability and consistency of downloads
CM Web Performance
TCP Newreno
Sequence number
With CM
Time (s)
CM greatly improves
predictability and consistency of downloads

11. CM applications TCP over CM Congestion-controlled UDP HTTP server
Uses TCP/CM for concurrent connections
cm_query() to pick content formats
SCTP: Stream Control Transport Protocol
Real-time streaming applications
Synchronous API for audio (e.g., vat)
Callback API for video (scalable MPEG-4 delivery system)

12. Congestion Control for Streaming Applications
CM provides a flexible framework for per-macroflow congestion control algorithms
TCP-style additive-increase/multiplicative decrease (AIMD) is ill-suited for streaming media
Window
Time
MD causes large, drastic rate changes
Slow start
Goal: Smooth rate reductions

13. l  K  size / (sqrt(p)  RTT)
TCP-friendliness
Throughput vs. loss-rate equation for AIMD:
l  K  size / (sqrt(p)  RTT)
Important for safe deployment and competition with TCP connections
Two different approaches:
Increase/Decrease rules
Increase: w(t+R)  I(w); e.g., w+1 or 2w
Decrease: w(t+dt)  D(w), e.g., w/2
Loss-rate monitoring (e.g., TFRC)
Estimate loss rate, p, and set rate  f(p)

14. Binomial Algorithms I(w) and D(w) are nonlinear functions
I: w(t+R)  w + a / wK
D: w(t+ dt)  w - b wL
Generalize linear algorithms
AIMD (K=0, L=1); MIMD (K=-1, L=1)
When L < 1, reductions are smaller than multiplicative-decrease
Are there interesting TCP-friendly binomial algorithms?

15. The (K,L) space I: w(t+R)  w + a / wK D: w(t+ dt)  w - b wL Unstable
AIMD
AIAD
MIAD
MIMD 1
More aggressive than AIMD
(-1 < K+L < 1)
Less aggressive than AIMD
(K+L > 1)
SQRT (K=L=0.5)
IIAD (K=1, L=0) K
Unstable
(K+L < -1)
TCP-friendly
K+L = 1

16. Window Evolution w(t) AIMD dw/dt = a / (wK RTT)
Trade-off between increase aggressiveness
and decrease magnitude
TCP-friendliness rule: K+L = 1 t

17. Binomial Algorithms Benefit Layered MPEG-4 Delivery

18. CM Linux Implementation
App stream
Stream requests, updates
cmapp_*()
libcm.a
User-level library;
implements API
System calls (e.g., ioctl)
Control socket for callbacks
TCP
CM macroflows, kernel API
UDP-CC
Congestion
controller
Scheduler
Prober
ip_output()
cm_notify()
ip_output() IP

19. Server performance CPU seconds for 200K pkts cmapp_send()
Buffered UDP-CC
TCP, no delack
TCP/CM, no delack
TCP/CM, w/ delack
TCP, w/ delack
Packet size (bytes)

20. Status CM Linux alpha code release this week
Sender-only CM soon to be up for proposed standard in IETF ECM working group
WG document: draft-ietf-ecm-cm-02.txt
Mailing list:
On-going work:
Evaluation of “slowly responsive” algorithms
Macroflow formation for diffserv
Congestion control vs. feedback frequency
CM scheduler algorithms
Using binomial algorithms on high-speed paths

21. Summary
Congestion Manager (CM) framework provides end-to-end adaptation platform for NGI applications and protocols
CM enables:
Adaptive applications using application-level framing (ALF) ideas
Efficient multiplexing and stable control of concurrent flows by sharing path information
Per-macroflow congestion control algorithms, including binomial algorithms for streaming media
Download it!