An End-System Architecture for Unified Congestion Management Hariharan S. Rahul, Hari Balakrishnan, Srinivasan Seshan MIT Lab for Computer Science

Two Questions Q: Why has the Internet not crumbled under its own load in recent years? Q: Can we remain sanguine about the future outlook? Internet Shared infrastructure and overload causes congestion Router

Not at all! Short flows dominate the Web –Slow Start uses bandwidth inefficiently Multiple flows between same hosts –Extremely aggressive and unfair to other apps Increasingly diverse apps and transports –Poor or no application adaptation to congestion

Attempted Solutions Persistent Connections (P-HTTP,HTTP/1.1) –Addresses the multiple short flows problem –Undesirable coupling between objects Integrated TCP Sessions (TCP-Int) –Addresses the multiple short flows problem –Independent TCP connections share control parameters (window,RTT) [BPS+98, Touch98] Both do not address application diversity

What We Really Need… Shared control information across all apps and transports (bandwidth, loss, RTT) Integrated end-to-end congestion manager : CM Congestion Manager IP HTTPVideo1 TCP1TCP2UDP AudioVideo2

Congestion Manager Features Ensures stable congestion behavior Enables application and transport adaptation to congestion via API Trusted intermediary between flows for bandwidth management Design motivated by end-to-end argument and Application Level Framing (ALF)

CM Components Adaptation API Algorithms and protocols Applications / Performance

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

Put the application in control Application decides what to transmit as late as possible No data buffering: cm_send() style API not useful Request/callback/notify API 1. cm_request(nsend) CMApp 2.app_notify(can_send) 3. cm_notify(nsent) Query: cm_query(&rate, &srtt)

Accommodate traffic heterogeneity TCP bulk transfers Short transactions (Web) Real-time flows Layered streams [And other unanticipated apps] cm_open(minrate);

Accommodate application heterogeneity API should not force an application style Asynchronous transmitters (e.g., TCP) –Request/callback/notify works well Synchronous transmitters –Need rate change triggers from CM change_rate(newrate)

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

Webserver and TCP over CM Application Congestion Manager 1.cm_open 2.cm_request 3.app_notify4.cm_notify 6.cm_close Webserver uses change_rate to pick source encoding 5.cm_update Steps 2,3,4,5 occur multiple times

CM Algorithms TCP friendly rate-based Additive-Increase/ Multiplicative-Decrease control Loss-resilient feedback protocol Flow segregation for non-best-effort networks Scheduler to apportion bandwidth

CM TCP Performance With CM CM greatly improves performance predictability and consistency TCP Newreno Time (s) Sequence number Flows using CM show good social behavior

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

Future Work Aggregate statistics at domain/subnet level Receiver API, protocol for receiver hints Flow segregation in non-best-effort networks Congestion control for multicast traffic

Links to papers HotOS paper: Technical Report (MIT-LCS-TR-771) Questions?