1 / 19

CSE 561 – Congestion Control with Network Support

CSE 561 – Congestion Control with Network Support. David Wetherall djw@cs.washington.edu Spring 2000. Reminder. Presentations in-class May 3 (next wed) Lit Review Assignment due May 10 (wed, week 7) In-class exam May 17 (wed, week 8) Final project presentations

erelah
Download Presentation

CSE 561 – Congestion Control with Network Support

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. CSE 561 – Congestion Control with Network Support David Wetherall djw@cs.washington.edu Spring 2000

  2. Reminder • Presentations in-class May 3 (next wed) • Lit Review Assignment due May 10 (wed, week 7) • In-class exam May 17 (wed, week 8) • Final project presentations • May 31 (wed, week 10) plus ? djw // CS 561, Spring 2000

  3. Project Status Presentations • In-class, May 3 • 9 project groups • 8 minutes clocked plus 1 minute for questions • Use your time well: single presenter, practice • Feedback: peer evaluation • What you should convey: • Frame the problem you’re studying and why it matters • Tell us what you’ve done so far • Tell us what you plan to do and what kind of results you will show us at the end of quarter djw // CS 561, Spring 2000

  4. Lit Review Assignment • Due May 10 • Pick a topic area, review the research literature and report on the development and ongoing issues • Short report (8 pages, single-spaced max) in teams of two • An experiment • Mini-generals (but MUCH smaller) • Good to do before your actual generals! djw // CS 561, Spring 2000

  5. This Lecture • Papers: • Shenker, Making Greed Work in Networks, Sigcomm94 • Floyd/Jacobson, RED Gateways for Congestion Avoidance, TON93 djw // CS 561, Spring 2000

  6. Floyd/Jacobson, TON 93 • Describes motivation for and details of RED gateways and provides an evaluation of them • Basic idea: congestion avoidance by detecting incipient congestion and dropping packets early • Elegant insight: the value of randomization • Contribution: incrementally deployable scheme that improves on the drop tail situation and is practical djw // CS 561, Spring 2000

  7. Problems with DropTail Routers • Congestion is detected by overflowing the queue • Why is this bad? • Global synchronization phenomena • How does this happen and why is it bad? • Bias against bursty traffic • Why so? • Bottom line: we need help from the network djw // CS 561, Spring 2000

  8. Incipient Congestion at a Router • Sustained overload causes queue to build and overflow djw // CS 561, Spring 2000

  9. Random Early Detection (RED) • Send “early” signal by probabilistically dropping a packet, allow source to respond before queue builds MaxThreshold MinThreshold A vgLen djw // CS 561, Spring 2000

  10. RED Algorithm • Calculate average queue length (EWMA) • Probabilistically drop (below) as queue builds • Flows receive drops proportional to their share • When queue is too high, revert to drop tail P(drop) 1.0 MaxP A vgLen MinThresh MaxThresh djw // CS 561, Spring 2000

  11. Explicit Congestion Notification (ECN) • Why only drop packets to signal congestion? • Drops are a robust signal, but there are other means … • We need to be careful though: no extra packets • ECN signals congestion by setting a bit in the IP header • Receiver returns indication to the sender, who slows • RED actually works by “marking” packets • Mark can be a drop or ECN signal if hosts understand ECN • Supports congestion avoidance without loss djw // CS 561, Spring 2000

  12. RED in Practice • Elegant idea, how well has it worked? • Setting parameters • Needed feedback a function of number of flows? • Effectiveness for short flows? • Misbehaving users • RED provides scant protection itself, but can be used to identify/punish misbehaving connections (the “penalty box”) djw // CS 561, Spring 2000

  13. Shenker 94 • A game-theory take on the congestion problem • Interested about making statements on what is and isn’t possible in terms of a general setup with selfish users • Contribution is an incentive-based design philosophy and summary of what is known to be possible and what is known not to be possible for his setting. djw // CS 561, Spring 2000

  14. Shenker’s Setup • Users behave selfishly according to their own utility functions • Weak restrictions on utility functions: they go up as rates increase and congestion decreases • We can choose only the switch algorithms that are applied to all packets • Question: Can we design switch algorithms that give “good” performance for all utility functions? djw // CS 561, Spring 2000

  15. Results • FIFO / proportional allocation leads to poor network performance with selfish users • FQ / Fair Share has a unique Nash equilibrium that is fair and easily reached by selfish optimization • Not necessarily optimally efficient (Pareto optimal) • No other MAC service discipline has these properties djw // CS 561, Spring 2000

  16. Fair Queuing (FQ) • FIFO is not guaranteed (or likely) to be fair • Flows jostle each other and hosts must play by the rules • Routers don’t discriminate traffic from different sources • Fair Queuing is an alternative scheduling algorithm • Maintain one queue per traffic source (flow) and send packets from each queue in turn • Actually, not quite, since packets are different sizes • Provides each flow with its “fair share” of the bandwidth • Issues: • Implementation complexity, definition of flow djw // CS 561, Spring 2000

  17. Fair Queuing Flow 1 Flow 2 Round-robin service Flow 3 Flow 4 djw // CS 561, Spring 2000

  18. Fair Queuing • Want to share bandwidth • At the “bit” level, but in reality must send whole packets • Approximate with finish times for each packet • finish (F) = arrive + length*rate; rate depends on # of flows • Send in order of finish times, except don’t preempt (stop) transmission if a new packet arrives that should go first • More generally, assign weights to queues (WFQ) Flow 1 Flow 2 Output F = 10 F = 8 F = 5 djw // CS 561, Spring 2000

  19. Further Interest • Pricing for Congestion Avoidance • E.g., Frank Kelley and Cambridge University / MSR folk • How do we design an economic model from which congestion avoidance falls out? djw // CS 561, Spring 2000

More Related