1. An Integrated Congestion Management Architecture for Internet Hosts
Hari Balakrishnan
MIT Lab for Computer Science

2. Shared infrastructure and overload causes congestion
Two Questions
Internet
Router
Shared infrastructure and overload causes congestion
Q: Why has the Internet not crumbled under its own load in recent years?
A: Soundness of TCP congestion control + friendly TCP workload
Q: Can we remain sanguine about the future outlook?

3. Problem #1: The Web! Multiple reliable streams
Internet r2 r3
Server
Client
r-n
Multiple reliable streams
Individual objects are small
So what?
Far too inefficient!
Far too aggressive!

4. Problem #2: Application Heterogeneityu1 r1
Internet u2 r2 u3 r3
Server
Client
u-m
r-n
New applications (e.g., real-time streams)
The world isn’t only about HTTP or even TCP!
So what?
Applications do not adapt to congestion
Long-term Internet stability is threatened

5. Congestion Management Challenges
Heterogeneous traffic mix
Variety of applications and transports
Multiple concurrent streams
Separation from other tasks like loss recovery
Stable control algorithms
Enable adaptive applications

6. “Solution” #1: Persistent Connections
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

7. “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?

8. “Solution” #3: Integrated TCP Sessions
Server
Client
r-n
Independent TCP connections, but shared control parameters [BPS+98, Touch98]
Shared congestion windows, round-trip estimates
But, this approach doesn’t accommodate non-TCP traffic

9. What is the World Heading Toward?u1 r1
Internet u2 r2 u3 r3
Server
Client
u-m
r-n
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.

10. What We Really Need…
HTTP
Audio
Video1
Video2
TCP1
TCP2
UDP
Congestion
Manager IP
An integrated approach to end-to-end congestion management for the Internet using the CM

11. Congestion Manager Properties
Ensures proper and stable congestion behavior
Enables application and transport adaptation to congestion via API
Trusted intermediary between flows for bandwidth management
Per-host & per-domain statistics (bandwidth, loss rates, RTT)
Design motivated by end-to-end argument and Application Level Framing (ALF)

12. CM Features Algorithms and protocols Adaptation API
Applications & performance

13. CM Algorithms Rate-based AIMD control Loss-resilient feedback protocol
Exponential aging when feedback is infrequent
Flow segregation to handle non-best-effort networks
Scheduler to apportion bandwidth between flows

14. CM’s Rate-based Control is TCP-friendly
Throughput goes as 1/sqrt(p) for AIMD scheme
nr2 = K { (nr/nd) + 1 }, where nr = # recd and nd = # dropped is necessary and sufficient for verifying TCP “friendliness”

15. Receiver Feedback Implicit: hints from application Explicit: CM probes
Probe every half RTT using loss-resilient protocol
Low overhead
Tracks loss rate, RTT estimate
But why do we need feedback?

16. Why Feedback? Loss rate increases with feedback infrequency
Loss probability
x times per RTT

17. Handling Infrequent Feedback
Exponential aging: reduce rate by half, every silent RTT
Continues transmissions at safe rate without clamping apps
Which RTT to use? Average? Minimum?
Sequence number
Time (s)

18. Better than Best-effort Networks
Future networks will not treat all flows equally
Per-host aggregation incorrect
Solution: flow segregation based on loss rates
[Evaluation in-progress]

19. CM Scheduler Currently HRR scheduler for rate allocation
Uses receiver hints to apportion bandwidth between flows
Experiments show it working well
Exploring other scheduling algorithms for delay management as well
Useful for real-time streams

20. The CM API Goal: To enable easy application adaptation
Four guiding principles:
Put the application in control
Accommodate traffic heterogeneity
Accommodate application heterogeneity
Learn from the application

21. Put the application in control
Application decides what to transmit as late as possible
CM does not buffer any data
cm_send() style API not useful
Request/callback/notify API
cm_request(nsend);
app_notify(can_send);
cm_notify(nsent);
Query function: cm_query(&rate, &srtt);

22. Accommodate traffic heterogeneity
TCP bulk transfers
Short transactions
Real-time flows at continuum of rates
Layered streams
[And other unanticipated apps]
cm_open(minrate);

23. Accommodate application heterogeneity
API should not force particular application style
Asynchronous transmitters (e.g., TCP)
Triggered by events other than periodic clocks
Request/callback/notify works well
Synchronous transmitters
Maintain internal timer for transmissions
Need rate change triggers from CM change_rate(newrate);

24. Learn from the application
cm_notify(nsent) upon transmission
cm_update(nrecd, duration, loss_occurred, rtt)
Hint to CM (implicit feedback)
Called by TCP on ACK reception, RTP applications on RTCP feedback, etc.
cm_close() to clean up flow state

25. Application 1: Web/TCP
Web server uses change_rate() to pick convenient source encoding

26. CM Web Performance TCP Newreno Sequence number With CM Time (s)
CM greatly improves
performance predictability
and consistency

27. Application 2: Layered Streaming Audio
Competing TCP
TCP/CM
Sequence number
Audio/CM
Time (s)

28. Conclusions CM ensures proper and stable congestion behavior
CM tells flows their rates
Simple, yet powerful API to enable application adaptation
Application is in control of what to send
Improves performance consistency and predictability for individual applications and makes them better network citizens