1. The Internet Congestion Manager Hari Balakrishnan MIT LCS http://kendall.lcs.mit.edu/

2. Motivation Increasing number of concurrent flows –E.g., Web, conferencing apps,... Increasing number of non-TCP apps –E.g., conferencing, games, device networks Emergence of “unresponsive” flows –E.g., “Web accelerators” CM: An end-system architecture for congestion management CM: An end-system architecture for congestion management

3. Concurrent Flows Compete, rather than cooperate for resources –N “slow starts,” aggressive behavior on congestion –No shared state learning Why not lump them all together? –Coupling between different streams –Application-specific (e.g., P-HTTP) CM abstracts all congestion-related information into one location CM abstracts all congestion-related information into one location

4. Adaptive Applications Layering makes it remarkably hard for applications to learn! –E.g., TCP hides bandwidth information Key problem: API design Application-Level Framing (ALF) –Put the application in control of key decisions

5. What We Really Want IP HTTPVideo1 TCP1TCP2UDP AudioVideo2 All congestion management tasks performed in CM Apps learn and adapt using API All congestion management tasks performed in CM Apps learn and adapt using API Congestion Manager Per-host statistics

6. CM API State maintenance –cm_open(), cm_close(), cm_mtu() Transmission Notification Querying –cm_query(&rate, &srtt); –Put in loss rate etc. too

7. Transmission API Callback-based send Buffered-send cm_request() cmapp_send() App CM IP send()

8. Transmission API (cont.) Request API: asynchronous sources while (some_event) { get_data(); send(); } Synchronous sources do_every_t_ms { get_data(); send(); } Solution: cmapp_update(rate, srtt) callback

9. Notification API Application hints –cm_update(nsent, nrecd, lossmode, rtt) IP output calls cm_notify(nsent) on every transmit At the receiver –Hints notification to apportion bandwidth

10. The CM Architecture Applications Prober Congestion Controller Scheduler Applications Responder Hints dispatch Congestion detector Sender Receiver CM protocol API

11. Details Congestion controller –Window-based AIMD with traffic shaping –Exponential aging when feedback low –Plug in other algorithms (per-macroflow!) Scheduler –Weighted RR, H-FSC –Plug in other algorithms (per-macroflow!) Prober-responder uses CM protocol

12. Status Implementation in progress (Linux) –Web server + TCP/CM cmapp_send() used by TCP cmapp_update(rate, srtt) used by httpd –Layered audio server –Modified browsers Extensive simulation results –Paper at SIGCOMM ‘99

13. Research Questions Aggregation: per-host, per-subnet,… Handling diff-serv (split macroflow) Feedback frequency analysis “Proxy” hosts End-host policing More applications

14. Deployment Issues In the long-term, change senders and receivers to use the CM In the short-term, sender-only changes CM protocol and headers negotiable ==> incremental deployment