Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 Congestion Control (contd) Shivkumar...
-
date post
20-Dec-2015 -
Category
Documents
-
view
234 -
download
1
Transcript of Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 Congestion Control (contd) Shivkumar...
Shivkumar KalyanaramanRensselaer Polytechnic Institute
1
Congestion Control (contd)
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
http://www.ecse.rpi.edu/Homepages/shivkuma
Based in part upon slides of Prof. Raj Jain (OSU), Srini Seshan (CMU), J. Kurose (U Mass), I.Stoica (UCB)
Shivkumar KalyanaramanRensselaer Polytechnic Institute
2
Queue Management Schemes: RED, ARED, FRED, BLUE, REM TCP Congestion Control (CC) Modeling, TCP Friendly CC Accumulation-based Schemes: TCP Vegas, Monaco Static Optimization Framework Model for Congestion Control Explicit Rate Feedback Schemes (ATM ABR: ERICA) Refs: Chap 13.21, 13.22 in Comer textbook Floyd and Jacobson "Random Early Detection gateways for Congestion Avoidance" Ramakrishnan and Jain,
A Binary Feedback Scheme for Congestion Avoidance in Computer Networks with a Connectionless Network Layer,
Padhye et al, "Modeling TCP Throughput: A Simple Model and its Empirical Validation" Low, Lapsley: "Optimization Flow Control, I: Basic Algorithm and Convergence" Kalyanaraman et al:
"The ERICA Switch Algorithm for ABR Traffic Management in ATM Networks" Harrison et al: "An Edge-based Framework for Flow Control"
Overview
Shivkumar KalyanaramanRensselaer Polytechnic Institute
3
Queuing Disciplines
Each router must implement some queuing discipline Queuing allocates bandwidth and buffer space:
Bandwidth: which packet to serve next (scheduling) Buffer space: which packet to drop next (buff mgmt)
Queuing also affects latency
Class C
Class B
Class A
Traffic Classes
Traffic Sources
DropScheduling Buffer Management
Shivkumar KalyanaramanRensselaer Polytechnic Institute
4
Typical Internet Queuing
FIFO + drop-tail Simplest choice Used widely in the Internet
FIFO (first-in-first-out) Implies single class of traffic
Drop-tail Arriving packets get dropped when queue is full
regardless of flow or importance Important distinction:
FIFO: scheduling discipline Drop-tail: drop (buffer management) policy
Shivkumar KalyanaramanRensselaer Polytechnic Institute
5
FIFO + Drop-tail Problems FIFO Issues: In a FIFO discipline, the service seen by a
flow is convoluted with the arrivals of packets from all other flows! No isolation between flows: full burden on e2e control No policing: send more packets get more service
Drop-tail issues: Routers are forced to have have large queues to
maintain high utilizations Larger buffers => larger steady state queues/delays Synchronization: end hosts react to same events
because packets tend to be lost in bursts Lock-out: a side effect of burstiness and synchronization
is that a few flows can monopolize queue space
Shivkumar KalyanaramanRensselaer Polytechnic Institute
6
Design Objectives
Keep throughput high and delay low (i.e. knee) Accommodate bursts Queue size should reflect ability to accept bursts
rather than steady-state queuing Improve TCP performance with minimal
hardware changes
Shivkumar KalyanaramanRensselaer Polytechnic Institute
7
Queue Management Ideas Synchronization, lock-out:
Random drop: drop a randomly chosen packet Drop front: drop packet from head of queue
High steady-state queuing vs burstiness: Early drop: Drop packets before queue full Do not drop packets “too early” because queue may reflect
only burstiness and not true overload Misbehaving vs Fragile flows:
Drop packets proportional to queue occupancy of flow Try to protect fragile flows from packet loss (eg: color them or
classify them on the fly) Drop packets vs Mark packets:
Dropping packets interacts w/ reliability mechanisms Mark packets: need to trust end-systems to respond!
Shivkumar KalyanaramanRensselaer Polytechnic Institute
8
Packet Drop Dimensions
AggregationPer-connection state Single class
Drop positionHead Tail
Random location
Class-based queuing
Early drop Overflow drop
Shivkumar KalyanaramanRensselaer Polytechnic Institute
9
Random Early Detection (RED)
Min threshMax thresh
Average Queue Length
minth maxth
maxP
1.0
Avg queue length
P(drop)
Shivkumar KalyanaramanRensselaer Polytechnic Institute
10
Random Early Detection (RED)
Maintain running average of queue length Low pass filtering
If avg Q < minth do nothing Low queuing, send packets through
If avg Q > maxth, drop packet Protection from misbehaving sources
Else mark (or drop) packet in a manner proportional to queue length & bias to protect against synchronization Pb = maxp(avg - minth) / (maxth - minth)
Further, bias Pb by history of unmarked packets
Pa = Pb/(1 - count*Pb)
Shivkumar KalyanaramanRensselaer Polytechnic Institute
11
RED Issues Issues:
Breaks synchronization well Extremely sensitive to parameter settings Wild queue oscillations upon load changes Fail to prevent buffer overflow as #sources increases Does not help fragile flows (eg: small window flows or
retransmitted packets) Does not adequately isolate cooperative flows from non-
cooperative flows Isolation:
Fair queuing achieves isolation using per-flow state RED penalty box: Monitor history for packet drops,
identify flows that use disproportionate bandwidth
Shivkumar KalyanaramanRensselaer Polytechnic Institute
12
Variant: ARED (Feng, Kandlur, Saha, Shin 1999)
Motivation: RED extremely sensitive to #sources and parameter settings
Idea: adapt maxp to load
If avg. queue < minth, decrease maxp
If avg. queue > maxth, increase maxp
No per-flow information needed
Shivkumar KalyanaramanRensselaer Polytechnic Institute
13
Variant: FRED (Ling & Morris 1997)
Motivation: marking packets in proportion to flow rate is unfair (e.g., adaptive vs non-adaptive flows)
Idea A flow can buffer up to minq packets w/o being marked
A flow that frequently buffers more than maxq packets gets penalized
All flows with backlogs in between are marked according to RED
No flow can buffer more than avgcq packets persistently Need per-active-flow accounting
Shivkumar KalyanaramanRensselaer Polytechnic Institute
14
Variant: BLUE (Feng, Kandlur, Saha, Shin 1999)
Motivation: wild oscillation of RED leads to cyclic overflow & underutilization
Algorithm On buffer overflow, increment marking prob On link idle, decrement marking prob
Shivkumar KalyanaramanRensselaer Polytechnic Institute
15
Variant: Stochastic Fair Blue Motivation: protection against non-adaptive flows Algorithm
L hash functions map a packet to L bins (out of NxL ) Marking probability associated with each bin is
Incremented if bin occupancy exceeds thresholdDecremented if bin occupancy is 0
Packets marked with min {p1, …, pL}
1
1
1 1 nonadaptive
adaptive
h1 hLhL-1h2
Shivkumar KalyanaramanRensselaer Polytechnic Institute
16
SFB (contd)
Idea A non-adaptive flow drives marking prob to 1
at all L bins it is mapped to An adaptive flow may share some of its L bins
with non-adaptive flows Non-adaptive flows can be identified and
penalized with reasonable state overhead (not necessarily per-flow)
Large numbers of bad flows may cause false positives
Shivkumar KalyanaramanRensselaer Polytechnic Institute
17
0 2 4 6 8 10 12 14 16 18 200
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
Link congestion measure
Lin
k m
ark
ing p
robability
REM Athuraliya & Low 2000
Main ideas Decouple congestion & performance measure “Price” adjusted to match rate and clear buffer Marking probability exponential in `price’
REM RED
Avg queue
1
Shivkumar KalyanaramanRensselaer Polytechnic Institute
18
Comparison of AQM Performance
DropTailqueue = 94%
REDmin_th = 10 pktsmax_th = 40 pktsmax_p = 0.1
REM
queue = 1.5 pktsutilization = 92% = 0.05, = 0.4, = 1.15
Shivkumar KalyanaramanRensselaer Polytechnic Institute
19
The DECbit Scheme
Basic ideas: Mark packets instead of dropping them Special support at both routers and e2e
Scheme: On congestion, router sets congestion indication (CI)
bit on packet Receiver relays bit to sender Sender adjusts sending rate
Key design questions: When to set CI bit? How does sender respond to CI?
Shivkumar KalyanaramanRensselaer Polytechnic Institute
20
Setting CI Bit
AVG queue length = (previous busy+idle + current interval)/(averaging interval)
Previous cycle Current cycle
Averaging interval
Current time
Time
Queue length
Shivkumar KalyanaramanRensselaer Polytechnic Institute
21
DECbit Routers
Router tracks average queue length Regeneration cycle: queue goes from empty to non-
empty to empty Average from start of previous cycle If average > 1 router sets bit for flows sending
more than their share If average > 2 router sets bit in every packet Threshold is a trade-off between queuing and delay Optimizes power = (throughput / delay) Compromise between sensitivity and stability
Acks carry bit back to source
Shivkumar KalyanaramanRensselaer Polytechnic Institute
22
DECbit Source
Source averages across acks in window Congestion if > 50% of bits set Will detect congestion earlier than TCP
Additive increase, multiplicative decrease Decrease factor = 0.875 Increase factor = 1 packet After change, ignore DECbit for packets in
flight (vs. TCP ignore other drops in window)
No slow start
Shivkumar KalyanaramanRensselaer Polytechnic Institute
23
Congestion Control Models Loss-based: TCP Reno etc Accumulation-based schemes: TCP Vegas, Monaco
Use per-flow queue contribution (backlog) as a congestion estimate instead of loss rate
Explicit rate-based feedback Controller at bottleneck assigns rates to each flow
Packet Pair congestion control [Not covered] WFQ at bottlenecks isolates flows, and gives fair rates Packet-pair probing discovers this rate and sets
source rate to that.
Shivkumar KalyanaramanRensselaer Polytechnic Institute
24
TCP Reno (Jacobson 1990)
SStime
window
CA
SS: Slow StartCA: Congestion Avoidance Fast retransmission/fast recovery
Shivkumar KalyanaramanRensselaer Polytechnic Institute
25
TCP Vegas (Brakmo & Peterson 1994)
SStime
window
CA
Converges, no retransmission … provided buffer is large enough
Shivkumar KalyanaramanRensselaer Polytechnic Institute
26
Accumulation: Single Queue
26),(),(
)],(),([
)]()([)]()([
)()(),(
)()()(
)()()(
ttOttI
ttttt
tSttStAttA
tqttqttq
ttSttAttq
tStAtq
ijij
ijij
ijijijij
ijijij
ijijij
ijijij
flow i at router j arrival curve Aij(t)
& service curve Sij(t) cumulative continuous non-decreasing
if no loss, thentime
Aij(t)
Sij(t)
queue
delaybit
t2t1
b1
b2
Shivkumar KalyanaramanRensselaer Polytechnic Institute
27
Accumulation: Series of Queues
27),(),(
)],(),([
)],(),([
),(),(
1
11
1
1
ttOtdtI
ttttdt
ttdttdt
tdtqtta
if
ii
if
ii
J
j
J
jkkij
J
jkkij
J
j
J
jkkiji
1
11
1
)()(J
jj
fi
J
j
J
jkkiji dddtqta
11,)()( 1, Jjitdt jijij we have
accumulation
then
1 j j+1 J
μij Λi,j+1
dj
fi
Λiμi
ingress egress
Shivkumar KalyanaramanRensselaer Polytechnic Institute
28
Queue vs Accumulation Behavior
28
queue qij(t) -- info of flow i queued in a fifo router j
accumulation ai(t) -- info of flow i queued in a set of fifo routers 1~J
),(),(),(
)(
ttOttIttq
tq
ijijij
ij
1
1
1
1
),(),(),(
)()(
J
jj
fii
fiii
J
j
J
jkkiji
ddttOtdtItta
dtqta
the collective queuing behavior of a set of fifo routers looks similar to that of one single fifo router
Shivkumar KalyanaramanRensselaer Polytechnic Institute
29
Accumulation: Distributed, Time-shifted Sum
1 j j+1 J
μij Λi,j+1
dj
fi
Λiμi
… …
29time
)(1f
ii dtq )(
1
J
jkkij dtq
)(tqiJ
1 j j+1 J
jd 1Jd
),( tdtI fii
)(tai
)( ttai
),( ttOi
fid
t
Shivkumar KalyanaramanRensselaer Polytechnic Institute
30
Control Policy
1 j j+1 J
μij Λi,j+1
dj
fi
Λiμi
0)( ii ta
30
control objective : keep if ,no way to probe increase of
available bw;0)( tai
ttttdtttarec
thentaif
thentaif
if
iii
iii
iii
)],(),([),(:
)(
)(
control algorithm :
Shivkumar KalyanaramanRensselaer Polytechnic Institute
31
31
Two Accumulation-Based Schemes
Monaco accumulation estimation: out-of-band / in-band congestion response: additive inc / additive dec (AIAD), and others.
Vegas accumulation estimation: only in-band ctrl packet congestion response: additive inc / additive dec (AIAD)
Shivkumar KalyanaramanRensselaer Polytechnic Institute
32
Accumulation vs. Monaco Estimator
1 j j+1 J
μij Λi,j+1
dj
fi
Λiμi
… …
time
)(1f
ii dtq )(
1
J
jkkij dtq
)(tqiJ
1 j j+1 J
jd 1Jd
)(taq im out-of-band
in-band ctrl pkt
),,(1
J
jkkq dtjit
qj
J
jkkq tdtjit
),,(1
Shivkumar KalyanaramanRensselaer Polytechnic Institute
33
33
Accumulation vs. Monaco Estimator
1 jf Jf
μij Λi,j+1
djf
fi
Λiμi
Jb jb+1 jb 1djb ctrl
data
jf+1
out-of-bd ctrl
in-band ctrl,data pkt
classifier
ctrl
fifo
Shivkumar KalyanaramanRensselaer Polytechnic Institute
34
Monaco
34
congestion estimation:out-of-band and in-band control packets
congestion response: if qm < α, cwnd(k+1) = cwnd(k) + 1;
if qm > β, cwnd(k+1) = cwnd(k) – 1; [ 1 = α < β = 3 ]
Shivkumar KalyanaramanRensselaer Polytechnic Institute
35
TCP Vegas
35
congestion estimation:define qv = ( cwnd / rttp – cwnd / rtt ) * rttp;
where rttp is round trip propagation delay (basertt)
congestion response: if qv < α, cwnd(k+1) = cwnd(k) + 1;
if qv > β, cwnd(k+1) = cwnd(k) – 1; [ 1 = α < β = 3 ]
Time
cwnd
slow start
congestionavoidance
Shivkumar KalyanaramanRensselaer Polytechnic Institute
36
Vegas Accumulation Estimator
36
the physical meaning of qv
rtt = rttp + rttq [ rttq is queuing time ]
qv = ( cwnd / rttp – cwnd / rtt ) * rttp
= ( cwnd / rtt ) * ( rtt – rttp )
= ( cwnd / rtt ) * rttq [ if rtt is typical ]
= sending rate * rttq [ little’s law ]
= packets backlogged [ little’s law again ] so vegas maintains α ~ β number of packets
queued inside the network it adjusts sending rate additively to achieve this
Shivkumar KalyanaramanRensselaer Polytechnic Institute
37
37
Accumulation vs. Vegas estimator
)()(
)(
)(
)()()(
1,
1,
tadta
dtq
ddtq
rttrttttq
bi
bi
fi
J
j
J
jn
bnji
J
j
J
jm
fm
biji
bq
fqiiv
b
b
b
b
b
f
f
f
f
f
Backlogv
1 jf Jf
μij Λi,j+1
djf
fi
Λiμi
Jb jb+1 jb 1djb ack
data
jf+1
Shivkumar KalyanaramanRensselaer Polytechnic Institute
38
Vegas vs. Monaco estimators
Vegas accumulation estimator ingress-basedround trip (forward data path and backward ack path)sensitive to ack path queuing delaysensitive to round trip propagation delay
measurement error
Monaco accumulation estimatoregress-basedone way (only forward data path) insensitive to ack path queuing delayno need to explicitly know one way propagation delay
Shivkumar KalyanaramanRensselaer Polytechnic Institute
39
Queue, Utilization w/ Basertt Errors
39
Shivkumar KalyanaramanRensselaer Polytechnic Institute
40
TCP Modeling
Given the congestion behavior of TCP can we predict what type of performance we should get?
What are the important factors Loss rate
Affects how often window is reduced RTT
Affects increase rate and relates BW to window RTO
Affects performance during loss recovery MSS
Affects increase rate
Shivkumar KalyanaramanRensselaer Polytechnic Institute
41
Overall TCP Behavior
Time
Window
• Let’s focus on steady state (congestion avoidance) with no slow starts, no timeouts and perfect loss recovery
Some additional assumptions Fixed RTT No delayed ACKs
Shivkumar KalyanaramanRensselaer Polytechnic Institute
42
Area = 2w2/3
Derivation
Each cycle delivers 2w2/3 packets Assume: each cycle delivers 1/p packets = 2w2/3
Delivers 1/p packets followed by a drop=> Loss probability = p/(1+p) ~ p if p is small.
Hence
t
window
2w/3
w = (4w/3+2w/3)/2
4w/3
2w/3
pw 2/3
Shivkumar KalyanaramanRensselaer Polytechnic Institute
43
Alternate Derivation Assume: loss is a Bernoulli process with probability p Assume: p is small wn is the window size after nth RTT
))1( (prob.lost ispacket no if,1
) (prob.lost ispacket a if,2/1
nn
nnn pww
pwww
pw
pw
wpwwpw
w
2
2
)1)(1(2
2
Shivkumar KalyanaramanRensselaer Polytechnic Institute
44
Law
Equilibrium window size
Equilibrium rate
Empirically constant a ~ 1 Verified extensively through simulations and on Internet References
T.J.Ott, J.H.B. Kemperman and M.Mathis (1996)M.Mathis, J.Semke, J.Mahdavi, T.Ott (1997)T.V.Lakshman and U.Mahdow (1997)J.Padhye, V.Firoiu, D.Towsley, J.Kurose (1998)
p1
p
aw
s
pD
ax
s
s
Shivkumar KalyanaramanRensselaer Polytechnic Institute
45
Implications Applicability
Additive increase multiplicative decrease (Reno) Congestion avoidance dominates No timeouts, e.g., SACK+RH Small losses Persistent, greedy sources Receiver not bottleneck
Implications Reno equalizes window Reno discriminates against long connections Halving throughput => quadrupling loss rate!
Shivkumar KalyanaramanRensselaer Polytechnic Institute
46
Renewal model including FR/FR with Delayed ACKs (b packets per ACK) Timeouts Receiver wnd limitation
Source rate
When p is small and Wr is large, reduces to
Refinement (Padhye, Firoin, Towsley & Kurose 1998)
pD
ax
s
s
)321(
83
3,1min3
2
1 ,min
2ppbp
Tbp
DD
Wx
oss
rs
Shivkumar KalyanaramanRensselaer Polytechnic Institute
47
TCP Friendliness
What does it mean to be TCP friendly? TCP is not going away Any new congestion control must compete
with TCP flowsShould not clobber TCP flows and grab bulk
of linkShould also be able to hold its own, i.e.
grab its fair share, or it will never become popular
Shivkumar KalyanaramanRensselaer Polytechnic Institute
48
Binomial Congestion Control
In AIMD Increase: Wn+1 = Wn + Decrease: Wn+1 = (1- ) Wn
In Binomial Increase: Wn+1 = Wn + /Wn
k
Decrease: Wn+1 = Wn - Wnl
k=0 & l=1 AIMD l < 1 results in less than multiplicative decrease
Good for multimedia applications
Shivkumar KalyanaramanRensselaer Polytechnic Institute
49
Binomial Congestion Control
Rate ~ 1/ (loss rate)1/(k+l+1)
If k+l=1 rate ~ 1/p0.5
TCP friendly AIMD (k=0, l=1) is the most aggressive of this
class SQRT (k=1/2,l=1/2) and IIAD (k=1,l=0) Good for applications that want to probe
quickly and can use any available bandwidth
Shivkumar KalyanaramanRensselaer Polytechnic Institute
50
Static Optimization Framework
xi(t)
pl(t)
Duality theory equilibrium Source rates xi(t) are primal variables Congestion measures pl(t) are dual variables Congestion control is optimization process over
Internet
Shivkumar KalyanaramanRensselaer Polytechnic Institute
51
Overview: equilibrium
Interaction of source rates xs(t) and congestion measures pl(t)
Duality theory They are primal and dual variables Flow control is optimization process
Example congestion measure Loss (Reno) Queueing delay (Vegas)
Shivkumar KalyanaramanRensselaer Polytechnic Institute
52
Overview: equilibrium
Llcx
xU
l
l
sss
xs
, subject to
)( max0
Congestion control problem
TCP/AQM protocols (F, G) Maximize aggregate source utility With different utility functions Us(xs)
Primal-dual algorithm
))( ),(( )1(
))( ),(( )1(
txtpGtp
txtpFtx
Reno, Vegas
DropTail, RED, REM
Shivkumar KalyanaramanRensselaer Polytechnic Institute
53
Model
c1 c2
Sources sL(s) - links used by source s
Us(xs) - utility if source rate = xs
Network Links l of capacities cl
x1
x2
x3
121 cxx 231 cxx
Shivkumar KalyanaramanRensselaer Polytechnic Institute
54
Primal problem
Llcx
xU
l
l
sss
xs
, subject to
)( max0
AssumptionsStrictly concave increasing Us
Unique optimal rates xs exist Direct solution impractical
Shivkumar KalyanaramanRensselaer Polytechnic Institute
55
Duality Approach
))( ),(( )1(
))( ),(( )1(
txtpGtp
txtpFtx
Primal-dual algorithm:
)( )( max )( min
, subject to )( max
00
0
:Dual
:Primal
ll
ll
sss
xp
ll
sss
x
xcpxUpD
LlcxxU
s
s
Shivkumar KalyanaramanRensselaer Polytechnic Institute
56
Gradient algorithm
Gradient algorithm
))(( )1( : source 1' tqUtx iii
)])(()([ )1( :link llll ctytptp
Theorem (Low, Lapsley, 1999) Converges to optimal rates in an asynchronousenvironment
Shivkumar KalyanaramanRensselaer Polytechnic Institute
57
Example
1
1 subject to
log max
31
21
0
xx
xx
xs
sxs
Lagrange multiplier: p1 = p2 = 3/2
1 1
x1
x2x3
Optimal: x1 = 1/3
x2 = x3 = 2/3
Shivkumar KalyanaramanRensselaer Polytechnic Institute
58
xs : proportionally fair (Vegas)
pl : Lagrange multiplier, (shadow) price, congestion measure
How to compute (x, p)? Gradient algorithms, Newton algorithm, Primal-dual algorithms…
Relevance to TCP/AQM ?? TCP/AQM protocols implement primal-dual algorithms over Internet
Example
1 1
x1
x2x3
Shivkumar KalyanaramanRensselaer Polytechnic Institute
59
1 1
x1
x2x3
xs : proportionally fair (Vegas)
pl : Lagrange multiplier, (shadow) price, congestion measure
How to compute (x, p)? Gradient algorithms, Newton algorithm, Primal-dual algorithms…
Relevance to TCP/AQM ?? TCP/AQM protocols implement primal-dual algorithms over Internet
Example
;)(
1)1( ;
)(
1)1(
;)()(
1)1(
23
12
211
tptx
tptx
tptptx
Aggregate rate
)1)()(()()1(
)1)()(()()1(
3122
2111
txtxtptp
txtxtptp
Shivkumar KalyanaramanRensselaer Polytechnic Institute
60
Active queue management
Idea: provide congestion information by probabilistically marking packets
Issues How to measure congestion (p and G)? How to embed congestion measure? How to feed back congestion info?
x(t+1) = F( p(t), x(t) )
p(t+1) = G( p(t), x(t) )
Reno, Vegas
DropTail, RED, REM
Shivkumar KalyanaramanRensselaer Polytechnic Institute
61
RED (Floyd & Jacobson 1993)
Congestion measure: average queue length
pl(t+1) = [pl(t) + xl(t) - cl]+
Embedding: p-linear probability function
Avg queue
marking
1
Shivkumar KalyanaramanRensselaer Polytechnic Institute
62
REM (Athuraliya & Low 2000)
Congestion measure: price
pl(t+1) = [pl(t) + (l bl(t)+ xl (t) - cl )]+
Embedding: exponential probability function
0 2 4 6 8 10 12 14 16 18 200
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
Link congestion measure
Lin
k m
arkin
g probability
Shivkumar KalyanaramanRensselaer Polytechnic Institute
63
Match rate
Clear buffer and match rate
Clear buffer
Key features
)] )(ˆ )( ()([ )1( ll
llll ctxtbtptp
)()( 1 1 tptp sl
Sum prices
Theorem (Paganini 2000)
Global asymptotic stability for general utility function (in the absence of delay)
Shivkumar KalyanaramanRensselaer Polytechnic Institute
64
AQM Summary
pl(t) G(p(t), x(t))
DropTail loss [1 - cl/xl (t)]+ (?)
RED queue [pl(t) + xl(t) - cl]+
Vegas delay [pl(t) + xl (t)/cl - 1]+
REM price [pl(t) + lbl(t)+ xl (t) - cl )]
+
x(t+1) = F( p(t), x(t) )
p(t+1) = G( p(t), x(t) )
Reno, Vegas
DropTail, RED, REM
Shivkumar KalyanaramanRensselaer Polytechnic Institute
65
)()(2
)(
))(1)(( tptx
tw
w
tptxtw s
s
s
ss
x(t+1) = F( p(t), x(t) )
p(t+1) = G( p(t), x(t) )
Reno: F
Primal-dual algorithm:Reno, Vegas
DropTail, RED, REM
for every ack (ca){ W += 1/W }for every loss{ W := W/2 }
)(2
)(
))(1( )()(),(
2
2tp
tx
D
tptxtxtpF s
sss
Shivkumar KalyanaramanRensselaer Polytechnic Institute
66
Reno Implications Equilibrium characterization
Duality
Congestion measure p = loss Implications
Reno equalizes window wi = i xi
inversely proportional to delay i
dependence for small p DropTail fills queue, regardless of queue capacity
2tan
2)( 1 ii
is
renos
xxU
p1
2
ii
iq
x
i
i
i
i qxq
2
)1( 2
2
Shivkumar KalyanaramanRensselaer Polytechnic Institute
67
Reno & gradient algorithm
Gradient algorithm
))(( )1( : source 1' tqUtx iii
)])(()([ )1( :link llll ctytptp
)(2
)(
))(1( )()(),(
2
2tq
txtqtxtxtqF i
i
i
iiiii
TCP approximate version of gradient algorithm
Shivkumar KalyanaramanRensselaer Polytechnic Institute
68
Reno & gradient algorithm Gradient algorithm
))(( )1( : source 1' tqUtx iii
)])(()([ )1( :link llll ctytptp
TCP approximate version of gradient algorithm
))()((
2
)( )(1 22 txtx
tqtxtx ii
iii
))(( 1' tqU ii
Shivkumar KalyanaramanRensselaer Polytechnic Institute
69
queue size
for every RTT
{ if W/RTTmin – W/RTT < then W ++
if W/RTTmin – W/RTT > then W -- }
for every loss
W := W/2
Vegas
ssssss
ss dtxdtwD
txtx
)()( if 1
)(12
else )(1 txtx ss
ssssss
ss dtxdtwD
txtx
)()( if 1
)(12
F:
pl(t+1) = [pl(t) + xl (t)/cl - 1]+G:
Shivkumar KalyanaramanRensselaer Polytechnic Institute
70
ATM ABR Explicit Rate Feedback
Sources regulate transmission using a “rate” parameter Feedback scheme:
Every (n+1)th cell is an RM (control) cell containing current cell rate, allowed cell rate, etc
Switches adjust the rate using rich information about congestion to calculate explicit, multi-bit feedback
Destination returns the RM cell to the source Control policy: Sources adjust to the new rate
DestinationDestinationSourceSource
RM Cell
Shivkumar KalyanaramanRensselaer Polytechnic Institute
71
ERICA: Design Goals Allows utilization to be 100% (better tracking) Allows operation at any point between the knee and the cliff
The queue length can be set to any desired value (tracking). Max-min fairness (fairness)
LinkUtilization
TimeQueueLength
50
Thr
ough
put
Load
Del
ay
Load
100%
Shivkumar KalyanaramanRensselaer Polytechnic Institute
72
Efficiency vs Fairness: OSU Scheme
Efficiency = high utilization Fairness = Equal allocations for contending sources Worry about fairness after utilization close to 100%
utilization . Target Utilization (U) and Target Utilization Band (TUB).
TotalLoad
Time
99%95%91%
overload region
underload region
worry about fairness here
U=TUB
Shivkumar KalyanaramanRensselaer Polytechnic Institute
73
ERICA Switch Algorithm
Overload = Input rate/Target rate Fair Share = Target rate/# of active VCs This VC’s Share = VC’s rate /Overload ER = Max(Fair Share, This VC’s Share) ER in Cell = Min(ER in Cell, ER)
This is the basic algorithm. Has more steps for improved fairness, queue
management, transient spike suppression, averaging of metrics.
Shivkumar KalyanaramanRensselaer Polytechnic Institute
74
TCP Rate Control Step 1: Explicit control of window:
Time
Congestion window(CWND)
Actual Window =Min(Cwnd, Wr)
Step 2: Control rate of acks (ack-bucket): Tradeoff ack queues in reverse path for fewer packets in forward path
r
R
pkts
acks
W
W
Shivkumar KalyanaramanRensselaer Polytechnic Institute
75
Summary
Active Queue Management (AQM): RED, REM etc Alternative models:
Accumulation-based schemes: Monaco, Vegas Explicit Rate-based Schemes
TCP stochastic modeling: Static (Duality) Optimization Framework