1 / 18

An End-System Architecture for Unified Congestion Management

An End-System Architecture for Unified Congestion Management. Hariharan S. Rahul, Hari Balakrishnan, Srinivasan Seshan MIT Lab for Computer Science http://inat.lcs.mit.edu/. Two Questions. Internet. Router. Q: Why has the Internet not crumbled under its own load in recent years?

prince
Download Presentation

An End-System Architecture for Unified Congestion Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. An End-System Architecture for Unified Congestion Management Hariharan S. Rahul, Hari Balakrishnan, Srinivasan Seshan MIT Lab for Computer Science http://inat.lcs.mit.edu/

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

  3. 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

  4. 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

  5. Congestion Manager What We Really Need… HTTP Audio Video1 Video2 • Shared control information across all apps and transports (bandwidth, loss, RTT) • Integrated end-to-end congestion manager : CM TCP1 TCP2 UDP IP

  6. 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)

  7. CM Components • Adaptation API • Algorithms and protocols • Applications / Performance

  8. 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

  9. 1. cm_request(nsend) 2.app_notify(can_send) 3. cm_notify(nsent) 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 App CM • Query:cm_query(&rate, &srtt)

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

  11. 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)

  12. 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

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

  14. 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

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

  16. 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

  17. 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

  18. Links to papers • HotOS paper: http://inat.lcs.mit.edu/papers/RBS99.ps • Technical Report (MIT-LCS-TR-771) • http://inat.lcs.mit.edu/papers/BRS99.ps • Questions?

More Related