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 Available bandwidth Round-trip times Loss information Application Transport Network Link CM exports a simple adaptation API Little information transferred across layers to applications More & more non-TCP applications Physical networks

6. Concurrent Flows Overload causes congestion CM abstracts all congestion-related information into one place CM abstracts all congestion-related information into one place Concurrent streams compete, causing aggressive network behavior! Additive-Increase & Multiplicative-Decrease (AIMD) Window Time “Slow start”

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 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-”macroflow” statistics (cwnd,rtt,…) API

9. The CM Architecture Application (TCP, http, video, etc.) Prober Congestion Controller Scheduler Responder Congestion Detector SenderReceiver CM protocol API Application API Hints Dispatch

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 App CM IP cm_send(,dst) Packet queue to dst Rate change Lesson: move buffering into the application Pull out and re-encode (hard!)

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

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(rate, 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. IP header 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 payload CM header 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 1. cm_open 2. cm_request 3. cmapp_send 6. cm_update on ACK 7. cm_close Steps 2-6 occur multiple times IP 5. cm_notify 4. send

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

21. Layered Streaming Audio Audio adapts to available bandwidth Combination of TCP & Audio compete equally with normal TCP Time (s) Sequence number Competing TCP TCP/CM Audio/CM

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? Different flows have different reliability semantics Loss of packet stalls all other flows! r1 r-n r3 r2 Put flows on same ordered byte stream Server Client