Transcript csci5211: Computer Networks and Data Communications

Congestion Control and Active
Queue Management
• Review of TCP Congestion Control
– A simple TCP throughput formula
• RED and Active Queue Management
– How RED works
– Fluid model of TCP and RED interaction (optional material)
– Other AQM mechanisms
• XCP: congestion for large delay-bandwidth product
– Router-based mechanism
– Decoupling congestion control from fairness
• DCCP: datagram congestion control protocol
– congestion control for non-TCP flows
– TCP-Friendly Rate Control (TFRC)
Readings: do required and optional readings if interested
winter 2008
congestion control and AQM
1
TCP Congestion Control Behavior
TCP runs at end-hosts
• congestion control:
– decrease sending rate when
loss detected, increase when
no loss
• routers
– discard, mark packets
when congestion occurs
• interaction between end
systems (TCP) and routers?
– want to understand
(quantify) this interaction
congested router drops packets
winter 2008
congestion control and AQM
2
Generic TCP CC Behavior:
Additive Increase
• window algorithm (window W )
– up to W packets in network
– return of ACK allows sender to send another packet
– cumulative ACKS
• increase window by one per RTT
W <- W +1/W per ACK
 W <- W +1 per RTT
• seeks available network bandwidth
• Ignoring the “slow start” phase during which window
increased by one per ACK
W <- W +1 per ACK
 W <- 2W per RTT
winter 2008
congestion control and AQM
3
receiver
sender
winter 2008
W
congestion control and AQM
4
Generic TCP CC Behavior:
Multiplicative Decrease
• window algorithm (window W)
• increase window by one per RTT
W <- W +1/W per ACK
• loss indication of congestion
• decrease window by half on detection of loss, (triple
duplicate ACKs), W <- W/2
winter 2008
congestion control and AQM
5
receiver
TD
sender
winter 2008
congestion control and AQM
6
Generic TCP CC Behavior:
After Time-Out (TO)
• window algorithm (window W)
• increase window by one per RTT
W <- W +1/W per ACK
• halve window on detection of loss, W <- W/2
• timeouts due to lack of ACKs -> window reduced to
one, W <- 1
winter 2008
congestion control and AQM
7
receiver
sender
TO
winter 2008
congestion control and AQM
8
Generic TCP Behavior: Summary
• window algorithm (window W)
• increase window by one per RTT (or one over window
per ACK, W <- W +1/W)
• halve window on detection of loss, W <- W/2
• timeouts due to lack of ACKs, W <- 1
• successive timeout intervals grow exponentially long
up to six times
winter 2008
congestion control and AQM
9
Understanding TCP Behavior
• can simulate (ns-2)
+ faithful to operation of TCP
- expensive, time consuming
• deterministic approximations
+ quick
- ignore some TCP details, steady state
• fluid models
+ transient behavior
- ignore some TCP details
winter 2008
congestion control and AQM
10
TCP Throughput/Loss Relationship
loss occurs
W
TCP
window
size
W/2
Idealized model:
• W is maximum supportable
window size (then loss occurs)
• TCP window starts at W/2 grows
to W, then halves, then grows to
W, then halves…
• one window worth of packets
each RTT
• to find: throughput as function
of loss, RTT
time (rtt)
winter 2008
congestion control and AQM
11
TCP Throughput/Loss Relationship
# packets sent per “period” =
W
TCP
window
size
W/2
period
time (rtt)
winter 2008
congestion control and AQM
12
TCP Throughput/Loss Relationship
# packets sent per “period” =
W /2
W W
W

   1  ...  W   (  n)
2 2

n 0 2
W
TCP
window
size
W
 W W /2
   1   n
2
 2 n 0
W/2
period
time (rtt)
winter 2008
W
 W W / 2(W / 2  1)
   1 
2
2
 2
3
3
 W2  W
8
4
3
 W2
8
congestion control and AQM
13
TCP Throughput/Loss Relationship
3 2
# packets sent per “period”  W
8
1 packet lost per “period” implies:
W
8
8
or:
W

3W 2
3 ploss
3 packets
B  avg._thrup ut  W
4
rtt
1.22 packets
B  avg._thruput 
rtt
ploss
ploss 
TCP
window
size
W/2
period
time (rtt)
winter 2008
B throughput formula can be extended
to model timeouts and slow start [PFTK’98]
(see slide 59 for details)
congestion control and AQM
14
Drawbacks of FIFO with Tail-drop
• Sometimes too late a signal to end system about
network congestion
– in particular, when RTT is large
• Buffer lock out by misbehaving flows
• Synchronizing effect for multiple TCP flows
• Burst or multiple consecutive packet drops
– Bad for TCP fast recovery
winter 2008
congestion control and AQM
15
FIFO Router with Two TCP Sessions
winter 2008
congestion control and AQM
16
Active Queue Management
• Dropping/marking packets
depends on average queue
length -> p = p(x)
• Advantages:
• Examples:
– RED
– REM
– …
– …
Marking probability p
– signal end systems earlier
– absorb burst better
– avoids synchronization
1
pmax
0
tmin
tmax
2tmax
average queue length x
winter 2008
congestion control and AQM
17
RED: Parameters
• min_th – minimum threshold
• max_th – maximum threshold
• avg_len – average queue length
– avg_len = (1-w)*avg_len + w*sample_len
Discard Probability
1
0
min_th max_th queue_len
winter 2008
congestion control and AQM
Average
Queue Length
18
RED: Packet Dropping
• If (avg_len < min_th)  enqueue packet
• If (avg_len > max_th)  drop packet
• If (avg_len >= min_th and avg_len < max_th) 
enqueue packet with probability P
Discard Probability (P)
1
0
min_th max_th queue_len Average
Queue Length
winter 2008
congestion control and AQM
19
RED: Packet Dropping (cont’d)
• P = max_P*(avg_len – min_th)/(max_th – min_th)
• Improvements to spread the drops
P’ = P/(1 – count*P), where
• count – how many packets were consecutively enqueued
since last drop
Discard Probability
max_P
1
P
0
min_th
winter 2008
max_th queue_len Average
Queue Length
avg_len
congestion control and AQM
20
RED Router with Two TCP Sessions
winter 2008
congestion control and AQM
21
Dynamic (Transient) Analysis of TCP
Fluids
Optional materials (slides 22-33)
• model TCP traffic as fluid
• describe behavior of flows and queues using
Ordinary Differential Equations (ODEs)
• solve resulting ODEs numerically
winter 2008
congestion control and AQM
22
Loss Model
AQM Router
B(t)
Packet Drop/Mark
p(t)
Sender
Receiver
Round Trip Delay (t)
Loss Rate as seen by Sender: l(t) = B(t-t)*p(t-t)
winter 2008
congestion control and AQM
23
A Single Congested Router
• focus on single bottlenecked
router
– capacity {C (packets/sec) }
– queue length q(t)
– discard prob. p(t)
TCP flow i
• N TCP flows thru router
AQM
router
C, p
winter 2008
– window sizes Wi(t)
– round trip time
Ri(t) = Ai+q(t)/C
– throughputs
Bi (t) = Wi(t)/Ri(t)
congestion control and AQM
24
Adding RED to the Model
Marking probability p
RED: Marking/dropping based on average queue length x(t)
1
pmax
tmin
tmax
2tmax
Average queue length x
- q(t)
- x(t)
x(t): smoothed, time averaged q(t)
t ->
winter 2008
congestion control and AQM
25
System of Differential Equations
Timeouts and slow start ignored
Window Size: dWk  1 - p ( x (t - t k )) - Wk (t ) Wk (t - t k ) p ( x (t - t k ))
dt
Rk (t )
2 Rk (t - t k )
Additive
increase
Queue length:
Loss arrival
rate
Wk (t )
dq
 -C 1{q > 0}  k
dt
Rk (t )
Outgoing
traffic
winter 2008
Mult.
decrease
Incoming
traffic
congestion control and AQM
26
System of Differential Equations (cont.)
Average smoothed
queue length:
dx ln(1 - a )
ln a

x (t ) q (t )
dt
d
d
Where
a = averaging parameter of RED(wth)
d = sampling interval ~ 1/C
Loss probability:
dp dp dx

dt dx dt
Where dp is obtained from the marking profile
dx
winter 2008
congestion control and AQM
27
N+2 coupled equations
N flows
dWi dt  f1  p, Ri ,Wi ), i  1,, N
Wi(t) = Window size
of flow i
Ri(t) = RTT of flow i
dp dt  f3 q )
dq dt  f 2 Wi )
p(t) = Drop probability
q(t) = queue length
Equations solved numerically using MATLAB
winter 2008
congestion control and AQM
28
Steady State Behavior
• let t → ∞
dWk
 0,
dt
p (t )  p, W (t )  W ,
Rk (t )  Rk
• this yields
1 - p Wk Wk
0
p
Rk
2 Rk
or Wk 
2(1 - p)
p
• the throughput is
Bk 
winter 2008
2(1 - p)
Rk p

2
Rk p
for small p
congestion control and AQM
29
A Queue is not a Network
Network - set of AQM routers, V
sequence Vi for session i
Round trip time - aggregate delay
Ri(t) = Ai + SvVi qv(t)
Loss/marking probability - cumulative prob
pi (t) = 1-Pv Vi (1 - pv(qv(t)))
Link bandwidth constraints
Queue equations
winter 2008
congestion control and AQM
30
How well does it work?
• OC-12 – OC-48 links
• RED with target delay
5msec
• 2600 TCP flows
OC-12
OC-48
• decrease to 1300 at 30
sec.
• increase to 2600 at 90 sec.
2600  j
1300  j
t=30
winter 2008
congestion control and AQM
2600  j
t=90
31
instantaneous delay
simulation
fluid model
time (sec)
Good queue length match
winter 2008
congestion control and AQM
32
average window size
window size
simulation
fluid model
simulation
fluid model
time (sec)
time (sec)
matches average window size
winter 2008
congestion control and AQM
33
Issues with RED
• Parameter sensitivity
– how to set minth, maxth, and maxp
– Goal: maintain avg. queue size below midpoint
between min_{th} and max_{th}
• maxth needs to be significantly smaller than max.
queue size to absorb transient peaks
• maxp determines drop rate
– In reality, hard to set these parameters
• RED uses avg. queue length, may introduce
large feedback delay, lead to instability
winter 2008
congestion control and AQM
34
Other AQM Mechanisms
•
•
•
•
•
•
Adaptive RED (ARED)
BLUE
Virtual Queue
Random Early Discard (REM)
Proportional Integral Controller
Adaptive Virtual Queue
– Improved AQMs are designed based on control
theory to provide better faster response to
congestion and more stable systems
winter 2008
congestion control and AQM
35
Explicit Congestion Notification (ECN)
• Standard TCP:
– Losses needed to detect congestion
– Wasteful and unnecessary
• ECN (RFC 2481):
– Routers mark packets instead of dropping them
– Receiver returns marks to sender in ACK packets
– Sender adjusts its window accordingly
• Two bits in IP header:
– ECT: ECN-capable transport (set to 1)
– CE: congestion experienced (set to 1)
winter 2008
congestion control and AQM
36
TCP congestion control performs poorly as
bandwidth or delay increases
Shown analytically in [Low01] and via simulations
50 flows in both directions
Buffer = BW x Delay
RTT = 80 ms
50 flows in both directions
Buffer = BW x Delay
BW = 155 Mb/s
Because TCP lacks fast response
• Spare bandwidth is available  TCP increases
by 1 pkt/RTT even if spare bandwidth is huge
• When a TCP starts, it increases exponentially
 Too many drops  Flows ramp up by 1 pkt/RTT,
taking forever
to grab
bandwidth
Bottleneck
Bandwidth
(Mb/s)the large
Round
Trip Delay (sec)
winter 2008
congestion control and AQM
37
XCP: eXplicit congestion Control Protocol
Solution: Decouple Congestion Control from Fairness
High Utilization;
Small Queues;
Few Drops
winter 2008
Bandwidth
Allocation
Policy
congestion control and AQM
38
Why Decoupling?
Solution: Decouple Congestion Control from Fairness
Coupled because a single mechanism controls both
Example: In TCP, Additive-Increase MultiplicativeDecrease (AIMD) controls both
How does decoupling solve the problem?
1. To control congestion: use MIMD which shows fast
response
2. To control fairness: use AIMD which converges to
fairness
winter 2008
congestion control and AQM
39
Characteristics of XCP Solution
1. Improved Congestion Control (in high bandwidthdelay & conventional environments):
•
Small queues
•
Almost no drops
2. Improved Fairness
3. Scalable (no per-flow state)
4. Flexible bandwidth allocation: min-max fairness,
proportional fairness, differential bandwidth
allocation,…
winter 2008
congestion control and AQM
40
XCP: An eXplicit Control Protocol
1. Congestion Controller
2. Fairness Controller
winter 2008
congestion control and AQM
41
How does XCP Work?
Round Trip
Round
Time
Trip Time
Congestion
Congestion
WindowWindow
Feedback
Feedback
Feedback =
+ 0.1 packet
Congestion Header
winter 2008
congestion control and AQM
42
How does XCP Work?
Round Trip Time
Congestion Window
Feedback ==
Feedback
+- 0.3
0.1 packet
winter 2008
congestion control and AQM
43
How does XCP Work?
Congestion Window = Congestion Window + Feedback
XCP uses ECN and “Core Stateless” mechanism
(i.e. state carried in packet header)
Routers compute feedback without any
per-flow state
winter 2008
congestion control and AQM
44
How Does an XCP Router Compute the
Feedback?
Congestion Controller
Fairness Controller
Goal: Matches input traffic to
link capacity & drains the queue
Goal: Divides  between
flows to converge to fairness
Looks at aggregate traffic &
queue
MIMD
Algorithm:
Aggregate traffic changes by 
 ~ Spare Bandwidth
 ~ - Queue Size
So,  = a davg Spare -  Queue
winter 2008
Looks at a flow’s state in
Congestion Header
AIMD
Algorithm:
If  > 0  Divide  equally
between flows
If  < 0  Divide  between
flows proportionally to their
current rates
congestion control and AQM
45
Getting the devil out of the details …
Congestion Controller
 = a davg Spare -  Queue
Theorem: System converges
to optimal utilization (i.e.,
stable) for any link bandwidth,
delay, number of sources if:

0 <a <
4 2
and
 a2 2
Algorithm:
If  > 0  Divide  equally between flows
If  < 0  Divide  between flows
proportionally to their current rates
Need to estimate number of
flows N
N

pkts in T
No Parameter
Tuning
(Proof
based on Nyquist
Criterion)
winter 2008
Fairness Controller
1
T  (Cwnd pkt / RTTpkt )
No Per-Flow State
RTTpkt : Round Trip Time in header
Cwndpkt : Congestion Window in header
T: Counting Interval
congestion control and AQM
46
Congestion Control without Reliability
• So far: congestion control for reliable (TCP-like) data
streams
– Use AIMD window/rate adjustment
• What about “long-lived” UDP flows?
– VoIP, video streaming flows
– prefer timeliness over reliability
– AIMD: too abrupt rate adjustment
• DCCP: Datagram Congestion Control Protocol (IETF proposed
standard)
– Large increase in long-lived UDP flows on Internet
– Reduce impact of long-lived UDP flows on TCP flows and
among themselves, avoid congestion collapse
– Can’t leave it to application developers
• May lead to “buggy” implementation, even if they are willing to
implement congestion control
winter 2008
congestion control and AQM
47
• Minimalism:
DCCP Design Goals
– Minimal functionality in line with e2e argument
– Few core protocol features, rich in implementation
• Leave out other features that can be implemented
successfully by apps or intermediate library
• Minimize header size
• Robustness
– in particular to attacks such as DoS
– robust and transparent to middleboxes
• Framework for modern congestion control
– Allow use of a variety of congestion control algorithms
• Self-sufficiency
– perform congestion control without application
intervention
• Support timing-reliability trade-offs
winter 2008
congestion control and AQM
48
DCCP Overview
• Fundamental Design Choices:
– In-band signaling
• Alternative: a separate signaling channel
– Bi-directional communication
• Alternative: one-way data flow
– Per-packet sequence number space
• including all non-data control packets (even ack pkts!)
• Alternative: TCP-like byte stream, per-data pkt
• Core Features
–
–
–
–
Connection management
Synchronization among two end-points
“Negotiation” of congestion control mechanisms
Others: mobility/multi-homed end points, partial
checksum
winter 2008
congestion control and AQM
49
DCCP Header Format
0
8
16
source port
data offset
(a)
destination port
CCVal CsCov
res type 1
24
reserved
checksum
sequence number
sequence number (low bits) [48 or 24 bits]
(b)
reserved
acknowledgement number
acknowledgment number (low bits) [48 or 24 bits]
(0 to 1008 bytes) head option
(a) generic header: starts every DCCP packet
(b) additional header info depending on packet type
possibly followed by options
payload starts at data offset
winter 2008
congestion control and AQM
50
DCCP Packet Types and States
• Packet Types
DCCP-Sync,
DCCP-SyncAck:
for explicit re-synchronization
after burst of losses
• Protocol State Machine:
No “half-closed” state (cf. TCP)
winter 2008
congestion control and AQM
51
DCCP: Two “Half Connections”
• Half-connection (HC):
– data flowing one direction plus corresponding ACKs
• Eg. One HC: A-> B data plus B->A acks
• A: HC-sender; B: HC-receiver
• Each connection: two conceptually separate
HC’s
– some may have only one HC (i.e., data flow one-way)
• State (seq. no, ack. no., …) maintained for each
HC
– Each HC may use different congestion control
mechanisms
winter 2008
congestion control and AQM
52
Connection Set-up/Teardown: Exp 1
• Client close: client enters “timed wait” state
winter 2008
congestion control and AQM
53
Connection Set-up/Teardown: Exp 2
• Server close:
– client enters “timed wait” state
– server never enters “timed wait” state!
winter 2008
congestion control and AQM
54
How to Maintain State and Sync
without Reliability
• HC-sender:
– Maintain state about what have been sent, window of
expected ack no.’s, etc.
• HC-receiver:
– maintain state about what pkts been received, window of
expected seq. no.’s, etc.
– ack no in ACK/DATA-ACK: only acked previously received
packet (i.e., not cumulative ack!)
• packets can be data or “control” packets
• use “ACK Vector” option for selective ack’s
– But lost packets may never be re-transmitted
• “state explosion” at receiver!
• Sending “ack of ack’s” to clean up state at HC-receiver
• Sender and receiver may lose “sync” after burst of
packet losses!
– Use Sync and SyncAck to get into sync again
– Care must be taken to deal with “half-open” connection
winter 2008
congestion control and AQM
55
Congestion Control Mechanisms
• Represented by Congestion Control Identifier
• CCID 2: TCP-like congestion mechanism
– sawtooth rate adjustment
– quickly get available bandwidth
• CCID 3: TCP-Friendly Rate Control (TFRC) mechanism
– respond more gradually to congestion
– more suitably for audio/video flows
CCID 0: reserved;
CCID 1: unspecified sender-based
congestion control
• Feature Negotiation
– Provide a generic mechanism for negotiating shared
parameters
• select CCID for each HC
• negotiate CCID-specific parameters
winter 2008
congestion control and AQM
56
A Few Words about
Security and Mobility
• Want to prevent data injection, DoS attacks
– Use initiation cookies (or “nounces”)
– Identification and Challenge options
– In general, obey “TCP robustness principle”
• “be conservative in what you send, and liberal in what
you accept” (modulo security)
• weigh trade-off between being “strict with validity
check” vs. exploitation of such check for “denial-ofservice” attacks
• End-Point Mobility (and Multi-Homing)
– Basic Mechanism: end-point moves, send “DCCPmove” from new address
• contain old address and port
• mandatory security mechanism (identification option)
to prevent hijacking
winter 2008
congestion control and AQM
57
TFRC: General Idea
• Use a model of TCP's throughout as a function of the loss
rate and RTT directly in a congestion control algorithm
– If transmission rate is higher than that given by the model,
reduce the transmission rate to the model's rate.
– Otherwise increase the transmission rate
• Equation-based: TCP-friendly
– TCP throughput approximate formula:
– Improved formula taking into account effect of “time out”
winter 2008
congestion control and AQM
58
An Improved "Steady State" Model
A pretty good improved model of TCP Reno, including
timeouts, from Padhye et al, Sigcomm 1998:
Would be better to have a model of TCP SACK, but the differences
aren’t critical.
winter 2008
congestion control and AQM
59
TFRC Details
• The devil's in the details
– How to measure the loss rate?
– How to respond to persistent congestion?
– How to use RTT and prevent oscillatory behavior?
• Not as simple as first thought
winter 2008
congestion control and AQM
60
TFRC Performance (Simulation)
winter 2008
congestion control and AQM
61
TFRC Performance (Experimental)
winter 2008
congestion control and AQM
62