1. CSE 561 – Congestion Control with Network Support David Wetherall djw@cs.washington.edu Spring 2000

2. djw // CS 561, Spring 2000 L10.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 ?

3. djw // CS 561, Spring 2000 L10.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

4. djw // CS 561, Spring 2000 L10.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!

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

6. djw // CS 561, Spring 2000 L10.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

7. djw // CS 561, Spring 2000 L10.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

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

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

10. djw // CS 561, Spring 2000 L10.10 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 MinThreshMaxThresh AvgLen RED Algorithm

11. djw // CS 561, Spring 2000 L10.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

12. djw // CS 561, Spring 2000 L10.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”)

13. djw // CS 561, Spring 2000 L10.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.

14. djw // CS 561, Spring 2000 L10.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?

15. djw // CS 561, Spring 2000 L10.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

16. djw // CS 561, Spring 2000 L10.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

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

18. djw // CS 561, Spring 2000 L10.18 Flow 1Flow 2 Output F = 8 F = 10 F = 5 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)

19. djw // CS 561, Spring 2000 L10.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?