Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Network tap wikipedia , lookup
Remote Desktop Services wikipedia , lookup
Wake-on-LAN wikipedia , lookup
Computer network wikipedia , lookup
Airborne Networking wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Deep packet inspection wikipedia , lookup
Internet protocol suite wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
The Internet Congestion Manager Hari Balakrishnan MIT Laboratory for Computer Science http://wind.lcs.mit.edu/ CM team Dave Andersen, Deepak Bansal, Dorothy Curtis, Bodhi Priyantha, Srinivasan Seshan Motivation • End-systems implement many functions – – – – – – Reliability In-order delivery Demultiplexing Message boundaries Connection abstraction Congestion control Of these, congestion control MUST be done for all communications State of Congestion Control “Multimedia Transmissions Drive Net Toward Gridlock” Sara Robinson New York Times 8/23/99 Two Issues • Adaptation – Enable applications to learn about network conditions and adapt • Concurrent flows – Efficiently multiplex streams and share paths Congestion Manager (CM): A new end-system architecture for congestion management Adaptation Application Transport Network Link • Little information transferred across layers to applications • More & more non-TCP applications • Available bandwidth • Round-trip times • Loss information Physical networks CM exports a simple adaptation API Concurrent Flows • Overload causes congestion Additive-Increase & Multiplicative-Decrease (AIMD) “Slow start” • Concurrent streams compete, causing aggressive network behavior! CM abstracts all congestion-related information into one place Time What Can We Do? • Inside-the-network smarts – – – – RED and variants Fair queueing and variants Differentiated services Integrated services • End-system architecture – Leverage a decade of experience – Interact well with router mechanisms The Big Picture HTTP Per-”macroflow” TCP1 statistics (cwnd,rtt,…) API Congestion Manager Audio Video1 TCP2 Video2 UDP IP All congestion management tasks performed in CM Apps learn and adapt using API The CM Architecture Application (TCP, http, video, etc.) Application API Congestion Controller API Hints Dispatch Scheduler Responder Prober Sender CM protocol Congestion Detector Receiver Problems • How does CM control when and whose transmissions occur? – Keep application in control of what to send • How does CM discover network state? – What information is shared? – What is the granularity of sharing? Key issues: API and information sharing Transmission API • Buffered-send – Does not allow apps to “pull back” data App cm_send( Rate change ,dst) Pull out and re-encode (hard!) CM IP Packet queue to dst Lesson: move buffering into the application Transmission API (cont.) • Callback-based send App send( ) cm_request() cmapp_send() based on allowed rate Schedule requests, not packets CM IP cm_notify(nsent) Enables apps to adapt “at the last instant” Transmission API (cont.) • Request API works for asynchronous sources wait for (some_events) { get_data(); /* e.g., from a file, image capture, etc. */ send(); /* call cm_request() and send on callback */ } • But what about synchronous sources (e.g., audio with constant sampling rate)? do_every_t_ms { /* timer loop */ get_data(); send(); /* oops, waiting for send callback wrecks timing */ } • Solution: rate-change callback cmapp_update(rate, srtt) Feedback about Network State • Monitoring successes and losses – Application hints – Probing system • Notification API (application hints) – Application calls cm_update(nsent, nrecd, congestion indicator, rtt) Probing System • Receiver modifications necessary – Support for separate CM header – Uses sequence number to detect losses – Sender can request count of packets received • Receiver modifications detected/negotiated via handshake – For incremental deployment IP header IP payload CM header IP payload Congestion Controller • Responsible for deciding when to send a packet • Window-based AIMD with traffic shaping (“TCP-friendly”) • Exponential aging when feedback low – Halve window every RTT (use min RTT) • Can plug in other algorithms – Selected on a “macroflow” granularity CM Scheduler • Responsible for deciding who should send a packet • Currently hierarchical round robin • Hints from application or receiver – Used to prioritize flows • Plug in other algorithms – Selected on a “macroflow” granularity – Prioritization interface may be different How will apps use the CM? • TCP – Asynchronous callback API • HTTP – Rate callbacks to decide content • Congestion controlled UDP – Buffered API • Conferencing applications – Synchronous API for real-time streams – Combination of others for other streams TCP/CM 1. cm_open TCP (reliability, conn. mgmt.) 7. cm_close 2. cm_request 4. send 6. cm_update 3. cmapp_send on ACK CM 5. cm_notify IP Steps 2-6 occur multiple times Sequence number CM Web Performance TCP Newreno Time (s) CM greatly improves predictability and consistency With CM Layered Streaming Audio Sequence number 450 400 350 Competing TCP 300 TCP/CM 250 200 150 Audio/CM 100 50 0 0 5 10 15 Time (s) 20 25 Audio adapts to available bandwidth Combination of TCP & Audio compete equally with normal TCP Status & Future • Implementation in progress (Linux) – – – – • • • • TCP/CM + Web server Layered audio server Congestion-controlled UDP sockets Modify clients to reflect user preferences Handling diffserv and traffic splitters Aggregation: per-host, per-subnet,… Feedback frequency analysis Aging of congestion information Deployment Issues • In the long-term, change senders and receivers to use the CM • In the short-term, change only senders e easier deployment – Requires receiver app feedback (e.g., TCP ACKs) • CM protocol and headers negotiable e incremental deployment • IETF working group to be formed Summary • CM enables proper and stable congestion behavior • Simple API to enable application to learn and adapt to network state • Improves consistency and predictability of network transfers • Provides benefit even when deployed at senders alone