CSE 561 – Congestion Control with Network Support

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