Transcript lecture 10

CSE 561 – Congestion Control with
Network Support
David Wetherall
[email protected]
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
– May 31 (wed, week 10) plus ?
djw // CS 561, Spring 2000
L10.2
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.3
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.4
This Lecture
• Papers:
– Shenker, Making Greed Work in Networks, Sigcomm94
– Floyd/Jacobson, RED Gateways for Congestion Avoidance, TON93
djw // CS 561, Spring 2000
L10.5
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.6
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.7
Incipient Congestion at a Router
• Sustained overload causes queue to build and overflow
Queue length
Instantaneous
Average
Time
djw // CS 561, Spring 2000
L10.8
Random Early Detection (RED)
• Send “early” signal by probabilistically dropping a
packet, allow source to respond before queue builds
MaxThreshold
MinThreshold
AvgLen
djw // CS 561, Spring 2000
L10.9
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
AvgLen
MinThresh
djw // CS 561, Spring 2000
MaxThresh
L10.10
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.11
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.12
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.13
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.14
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.15
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.16
Fair Queuing
Flow 1
Flow 2
Round-robin
service
Flow 3
Flow 4
djw // CS 561, Spring 2000
L10.17
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
Flow 1
F=8
F=5
Flow 2
Output
F = 10
• More generally, assign weights to queues (WFQ)
djw // CS 561, Spring 2000
L10.18
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
L10.19