1 / 14

The Internet Congestion Manager

The Internet Congestion Manager. Hari Balakrishnan MIT LCS http://kendall.lcs.mit.edu/. Motivation. Increasing number of concurrent flows E.g., Web, conferencing apps,... Increasing number of non-TCP apps E.g., conferencing, games, device networks Emergence of “unresponsive” flows

hindsl
Download Presentation

The Internet Congestion Manager

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. The Internet Congestion Manager Hari Balakrishnan MIT LCS http://kendall.lcs.mit.edu/

  2. Motivation • Increasing number of concurrent flows • E.g., Web, conferencing apps,... • Increasing number of non-TCP apps • E.g., conferencing, games, device networks • Emergence of “unresponsive” flows • E.g., “Web accelerators” CM: An end-system architecture for congestion management

  3. Concurrent Flows • Compete, rather than cooperate for resources • N “slow starts,” aggressive behavior on congestion • No shared state learning • Why not lump them all together? • Coupling between different streams • Application-specific (e.g., P-HTTP) CM abstracts all congestion-related information into one location

  4. Adaptive Applications • Layering makes it remarkably hard for applications to learn! • E.g., TCP hides bandwidth information • Key problem: API design • Application-Level Framing (ALF) • Put the application in control of key decisions

  5. Per-host statistics Congestion Manager What We Really Want HTTP Audio Video1 Video2 TCP1 TCP2 UDP IP All congestion management tasks performed in CM Apps learn and adapt using API

  6. CM API • State maintenance • cm_open(), cm_close(), cm_mtu() • Transmission • Notification • Querying • cm_query(&rate, &srtt); • Put in loss rate etc. too

  7. App send() cmapp_send() cm_request() CM IP Transmission API • Callback-based send • Buffered-send

  8. Transmission API (cont.) • Request API: asynchronous sources while (some_event) { get_data(); send(); } • Synchronous sources do_every_t_ms { get_data(); send(); } • Solution: cmapp_update(rate, srtt) callback

  9. Notification API • Application hints • cm_update(nsent, nrecd, lossmode, rtt) • IP output calls cm_notify(nsent) on every transmit • At the receiver • Hints notification to apportion bandwidth

  10. Applications Applications Congestion Controller Hints dispatch CM protocol Congestion detector Scheduler Responder Prober Receiver Sender The CM Architecture API API

  11. Details • Congestion controller • Window-based AIMD with traffic shaping • Exponential aging when feedback low • Plug in other algorithms (per-macroflow!) • Scheduler • Weighted RR, H-FSC • Plug in other algorithms (per-macroflow!) • Prober-responder uses CM protocol

  12. Status • Implementation in progress (Linux) • Web server + TCP/CM • cmapp_send() used by TCP • cmapp_update(rate, srtt) used by httpd • Layered audio server • Modified browsers • Extensive simulation results • Paper at SIGCOMM ‘99

  13. Research Questions • Aggregation: per-host, per-subnet,… • Handling diff-serv (split macroflow) • Feedback frequency analysis • “Proxy” hosts • End-host policing • More applications

  14. Deployment Issues • In the long-term, change senders and receivers to use the CM • In the short-term, sender-only changes • CM protocol and headers negotiable ==> incremental deployment

More Related