1. An Integrated Congestion Management Architecture for Internet Hosts Hari Balakrishnan MIT Lab for Computer Science http://inat.lcs.mit.edu/~hari

2. Two Questions 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? Internet Shared infrastructure and overload causes congestion Router

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

4. Problem #2: Application Heterogeneity u1 u-m u3 u2 r1 r2 r3 r-n Server 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 Internet Client

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 r1 r-n r3 r2 Put everyone on same ordered byte stream 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 Server Client

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 r1 r-n r3 r2 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 Server Client

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

10. What We Really Need… An integrated approach to end-to-end congestion management for the Internet using the CM IP HTTPVideo1 TCP1TCP2UDP AudioVideo2 Congestion Manager

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 n r 2 = K { (n r /n d ) + 1 }, where n r = # recd and n d = # 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 x times per RTT Loss probability

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? Time (s) Sequence number

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 With CM CM greatly improves performance predictability and consistency TCP Newreno Time (s) Sequence number

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

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