An Integrated Congestion Management Architecture for Internet Hosts

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 Internet • 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? Router Shared infrastructure and overload causes congestion

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

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

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 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 r1 r2 r3 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. Internet What is the World Heading Toward? u1 r1 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. Congestion Manager What We Really Need… HTTP Audio Video1 Video2 An integrated approach to end-to-end congestion management for the Internet using the CM TCP1 TCP2 UDP IP

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 = # droppedis 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