CSE 561 – Congestion Control with Network Support

David Wetheralldjw@cs.washington.edu

Spring 2000

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 ?

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

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!

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

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

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

djw // CS 561, Spring 2000 L10.8

• Sustained overload causes queue to build and overflowQueue length

Instantaneous

Average

Time

Incipient Congestion at a Router

djw // CS 561, Spring 2000 L10.9

MaxThreshold MinThreshold

AvgLen

Random Early Detection (RED)

• Send “early” signal by probabilistically dropping a packet, allow source to respond before queue builds

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

MinThresh MaxThresh

AvgLen

RED Algorithm

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

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”)

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.

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?

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

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

djw // CS 561, Spring 2000 L10.17

Flow 1

Flow 2

Flow 3

Flow 4

Round-robinservice

Fair Queuing

djw // CS 561, Spring 2000 L10.18

Flow 1 Flow 2 Output

F = 8 F = 10F = 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)

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?