Transcript TCP Flow Control Tutorial

Acknowledgments
S. Athuraliya, D. Lapsley, V. Li, Q. Yin
(UMelb)
J. Doyle (Caltech), K.B. Kim (SNU/Caltech),
F. Paganini (UCLA), J. Wang (Caltech), Z.
Wang (UCLA)
L. Peterson, L. Wang (Princeton)
Matthew Roughan (AT&T Labs)
TCP Congestion Control:
Algorithms & Models
Steven Low
netlab.caltech.edu
IPAM, 2002
Copyright, 1996 © Dale Carnegie & Associates, In
Outline
Introduction
Algorithms
Window flow control
TCP algorithm: Tahoe, Reno, Vegas
AQM algorithm: RED, REM, variants
Models
Duality model
Linear dynamic model
Part 0
Introduction
TCP/IP Protocol Stack
Applications (e.g. Telnet, HTTP)
TCP
UDP
IP
ICMP
ARP
Link Layer (e.g. Ethernet, ATM)
Physical Layer (e.g. Ethernet, SONET)
Packet Terminology
Application Message
MSS
TCP Segment
TCP hdr
IP Packet
IP hdr
Ethernet Frame
TCP data
20 bytes
IP data
20 bytes
Ethernet
Ethernet data
14 bytes
MTU 1500 bytes
4 bytes
IP
Packet switched
Datagram service
Unreliable (best effort)
Simple, robust
Heterogeneous
Dumb network, intelligent terminals
Compare with PSTN
TCP
Packet switched
End-to-end
Reliable, in order delivery of a packet stream
Reliability through ACKs
Flow control: use bandwidth efficiently
Success of IP
Simple/Robust
WWW, Email, Napster, FTP, …
Applications
IP
Transmission
Ethernet, ATM, POS, WDM, …
 Robustness against failure
 Robustness against technological
evolutions
TCP versions
TCP is not perfectly homogenous (200+)
4.2 BSD first widely available release of TCP/IP (1983)
Windows 95
4.3 BSD (1986)
Windows NT
4.3 BSD Tahoe (1988)
4.3 BSD Reno (1990)
SunOS 4.1.3,4.1.4
Solaris 2.3,2.4
IRIX
Digital OSF
HP/UX
4.4 BSD (1993)
Vegas (1994)
NewReno (1999)
.....
Linux 1.0
Part I
Algorithms
TCP & AQM
pl(t)
xi(t)
Example congestion measure pl(t)
Loss (Reno)
Queueing delay (Vegas)
TCP & AQM
pl(t)
xi(t)
TCP:
 Reno
 Vegas
AQM:
 DropTail
 RED
 REM,PI,AVQ
Outline
Introduction
Algorithms
Window flow control
TCP algorithm: Tahoe, Reno, Vegas
AQM algorithm: RED, REM, variants
Models
Duality model
Linear dynamic model
Early TCP
Pre-1988
Go-back-N ARQ
Detects loss from timeout
Retransmits from lost packet onward
Receiver window flow control
Prevent overflows at receive buffer
Flow control: self-clocking
Why Flow Control?
October 1986, Internet had its first
congestion collapse
Link LBL to UC Berkeley
400 yards, 3 hops, 32 Kbps
throughput dropped to 40 bps
factor of ~1000 drop!
1988, Van Jacobson proposed TCP flow
control
Effect of Congestion




Packet loss
Retransmission
Reduced throughput
Congestion collapse due to
 Unnecessarily retransmitted packets
 Undelivered or unusable packets
 Congestion may continue after the overload!
throughput
load
Window Flow Control
RTT
Source
1 2
W
W
time
ACKs
data
Destination
1 2
1 2
W
1 2
W
time
~ W packets per RTT
Lost packet detected by missing ACK
Window flow control
 Limit the number of packets in the network to
window W
W  MSS
 Source rate =
RTT
bps
 If W too small then rate « capacity
If W too big then
rate > capacity
=> congestion
 Adapt W to network (and conditions)
W = BW x RTT
TCP Window Flow Controls
 Receiver flow control
 Avoid overloading receiver
 Set by receiver
 awnd: receiver (advertised) window
 Network flow control
 Avoid overloading network
 Set by sender
 Infer available network capacity
 cwnd: congestion window
 Set W = min (cwnd, awnd)
Receiver Flow Control
Receiver advertises awnd with each ACK
Window awnd
closed when data is received and ack’d
opened when data is read
Size of awnd can be the performance limit
(e.g. on a LAN)
sensible default ~16kB
Network Flow Control
Source calculates cwnd from indication of
network congestion
Congestion indications
Losses
Delay
Marks
Algorithms to calculate cwnd
Tahoe, Reno, Vegas, RED, REM …
Outline
Introduction
Algorithms
Window flow control
TCP algorithm: Tahoe, Reno, Vegas
AQM algorithm: RED, REM, variants
Models
Duality model
Linear dynamic model
TCP Congestion Controls
 Tahoe (Jacobson 1988)
 Slow Start
 Congestion Avoidance
 Fast Retransmit
 Reno (Jacobson 1990)
 Fast Recovery
 Vegas (Brakmo & Peterson 1994)
 New Congestion Avoidance
 RED (Floyd & Jacobson 1993)
 Probabilistic marking
 REM (Athuraliya & Low 2000)
 Clear buffer, match rate
Variants
Tahoe & Reno
NewReno
SACK
Rate-halving
Mod.s for high performance
AQM
RED, ARED, FRED, SRED
BLUE, SFB
REM, PI, AVQ
TCP Tahoe
(Jacobson 1988)
window
SS
CA
SS: Slow Start
CA: Congestion Avoidance
time
Slow Start
sender
receiver
cwnd
1
1 RTT
2
data packet
ACK
3
4
5
6
7
8
cwnd  cwnd + 1 (for each ACK)
Congestion Avoidance
sender
receiver
cwnd
1
2
data packet
ACK
1 RTT
3
4
cwnd  cwnd + 1 (for each cwnd ACKS)
Packet Loss
Assumption: loss indicates congestion
Packet loss detected by
Retransmission TimeOuts (RTO timer)
Duplicate ACKs (at least 3)
Packets
1
2
3
4
5
7
6
Acknowledgements
1
2
3
3
3
3
Fast Retransmit
Wait for a timeout is quite long
Immediately retransmits after 3 dupACKs
without waiting for timeout
Adjusts ssthresh
flightsize = min(awnd, cwnd)
ssthresh  max(flightsize/2, 2)
Enter Slow Start (cwnd = 1)
Summary: Tahoe
 Basic ideas
 Gently probe network for spare capacity
 Drastically reduce rate on congestion
 Windowing: self-clocking
 Other functions: round trip time estimation, error
recovery
for every ACK {
if (W < ssthresh) then W++
else W += 1/W
}
for every loss {
ssthresh = W/2
W = 1
}
(SS)
(CA)
Fast recovery
 Motivation: prevent `pipe’ from emptying after
fast retransmit
 Idea: each dupACK represents a packet having
left the pipe (successfully received)
 Enter FR/FR after 3 dupACKs
 Set ssthresh  max(flightsize/2, 2)
 Retransmit lost packet
 Set cwnd  ssthresh + ndup (window inflation)
 Wait till W=min(awnd, cwnd) is large enough;
transmit new packet(s)
 On non-dup ACK (1 RTT later), set cwnd  ssthresh
(window deflation)
 Enter CA
Example: FR/FR
S 1 2 3 4 5 6 7 8
1
9 10 11
time
Exit FR/FR
R
0 0 0 0 0 0 0
cwnd 8
ssthresh
7
4
time
8
9
4
11
4
4
4
Fast retransmit
Retransmit on 3 dupACKs
Fast recovery
Inflate window while repairing loss to fill pipe
Summary: Reno
Basic ideas
Fast recovery avoids slow start
dupACKs: fast retransmit + fast recovery
Timeout: fast retransmit + slow start
dupACKs
congestion
avoidance
FR/FR
timeout
slow start
retransmit
NewReno: Motivation
FR/FR
S 1 2 3 4 5 6 7 8 9 0
D
0
0
0
1
0
3
0
8
2
9
time
time
5
timeout
8 unack’d pkts
 On 3 dupACKs, receiver has packets 2, 4, 6, 8, cwnd=8,
retransmits pkt 1, enter FR/FR
 Next dupACK increment cwnd to 9
 After a RTT, ACK arrives for pkts 1 & 2, exit FR/FR,
cwnd=5, 8 unack’ed pkts
 No more ACK, sender must wait for timeout
NewReno
Fall & Floyd ‘96, (RFC 2583)
 Motivation: multiple losses within a window
 Partial ACK acknowledges some but not all packets
outstanding at start of FR
 Partial ACK takes Reno out of FR, deflates window
 Sender may have to wait for timeout before proceeding
 Idea: partial ACK indicates lost packets
 Stays in FR/FR and retransmits immediately
 Retransmits 1 lost packet per RTT until all lost packets
from that window are retransmitted
 Eliminates timeout
SACK
Mathis, Mahdavi, Floyd, Romanow ’96 (RFC 2018, RFC 2883)
 Motivation: Reno & NewReno retransmit at most
1 lost packet per RTT
 Pipe can be emptied during FR/FR with multiple losses
 Idea: SACK provides better estimate of packets
in pipe
 SACK TCP option describes received packets
 On 3 dupACKs: retransmits, halves window, enters FR
 Updates pipe = packets in pipe
 Increment when lost or new packets sent
 Decrement when dupACK received
 Transmits a (lost or new) packet when pipe < cwnd
 Exit FR when all packets outstanding when FR was
entered are acknowledged
Outline
Introduction
Algorithms
Window flow control
TCP algorithm: Tahoe, Reno, Vegas
AQM algorithm: RED, REM, variants
Models
Duality model
Linear dynamic model
TCP Vegas
(Brakmo & Peterson 1994)
window
SS
CA
time
 Reno with a new congestion avoidance algorithm
 Converges (provided buffer is large) !
Congestion avoidance
Each source estimates number of its own
packets in pipe from RTT
Adjusts window to maintain estimate
between ad and bd
for every RTT
{
if W/RTTmin – W/RTT < a
then W ++
if W/RTTmin – W/RTT > b
then W --
}
for every loss
W := W/2
Implications
Congestion measure = end-to-end queueing
delay
At equilibrium
Zero loss
Stable window at full utilization
Approximately weighted proportional fairness
Nonzero queue, larger for more sources
Convergence to equilibrium
Converges if sufficient network buffer
Oscillates like Reno otherwise
Outline
Introduction
Algorithms
Window flow control
TCP algorithm: Tahoe, Reno, Vegas
AQM algorithm: RED, REM, variants
Models
Duality model
Linear dynamic model
Active queue management
Idea: provide congestion information by
probabilistically marking packets
Issues
How to measure congestion?
How to embed congestion measure?
How to feed back congestion info?
RED
(Floyd & Jacobson 1993)
 Congestion measure: average queue length
bl(t+1) = [bl(t) + yl(t) - cl]+
 Embedding: p-linear probability function
marking
1
Avg queue
 Feedback: dropping or ECN marking
Variant: ARED
(Feng, Kandlur, Saha, Shin 1999)
Motivation: RED extremely sensitive to
#sources
Idea: adapt maxp to load
If avg. queue < minth, decrease maxp
If avg. queue > maxth, increase maxp
No per-flow information needed
Variant: FRED
(Ling & Morris 1997)
 Motivation: marking packets in proportion to flow
rate is unfair (e.g., adaptive vs unadaptive flows)
 Idea
 A flow can buffer up to minq packets without 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
Variant: SRED
(Ott, Lakshman & Wong 1999)
Motivation: wild oscillation of queue in RED
when load changes
Idea:
Estimate number N of active flows
An arrival packet is compared with a randomly
chosen active flows
N ~ prob(Hit)-1
cwnd~p-1/2 and Np-1/2 = Q0 implies p = (N/Q0)2
Marking prob = m(q) min(1, p)
No per-flow information needed
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
RED
(Floyd & Jacobson 1993)
 Congestion measure: average queue length
bl(t+1) = [bl(t) + yl(t) - cl]+
 Embedding: p-linear probability function
marking
1
Avg queue
 Feedback: dropping or ECN marking
REM
(Athuraliya & Low 2000)
 Congestion measure: price
pl(t+1) = [pl(t) + g(al bl(t)+ xl (t) - cl )]+
 Embedding:
 Feedback: dropping or ECN marking
REM
(Athuraliya & Low 2000)
 Congestion measure: price
pl(t+1) = [pl(t) + g(al bl(t)+ xl (t) - cl )]+
 Embedding: exponential probability function
1
0.9
Link marking probability
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0
0
2
4
6
8
10
12
Link congestion measure
14
16
18
20
 Feedback: dropping or ECN marking
Key features
Clear buffer and match rate
pl (t  1)  [ pl (t )  g ( al bl (t )  xˆ l (t )  cl )]
Clear buffer
Match rate
Sum prices
1
 pl (t )
 1
 p s (t )
Theorem (Paganini 2000)
Global asymptotic stability for general utility
function (in the absence of delay)
Summary
pl(t)
xi(t)
TCP:
 Reno
 Vegas
AQM:
 DropTail
 RED
 REM,PI,AVQ
Application: Wireless TCP
Reno uses loss as congestion measure
In wireless, significant losses due to
Fading
Interference
Handover
Not buffer overflow (congestion)
Halving window too drastic
Small throughput, low utilization
Proposed solutions
Ideas
Hide from source noncongestion losses
Inform source of noncongestion losses
Approaches
Link layer error control
Split TCP
Snoop agent
SACK+ELN (Explicit Loss Notification)
Third approach
Problem
Reno uses loss as congestion measure
Two types of losses
Congestion loss: retransmit + reduce window
Noncongestion loss: retransmit
Previous approaches
Hide noncongestion losses
Indicate noncongestion losses
Our approach
Eliminates congestion losses (buffer overflows)
Third approach
 Router
REM capable
 Host
Do not use loss as congestion measure
Vegas
REM
 Idea
 REM clears buffer
 Only noncongestion losses
 Retransmits lost packets without reducing window
Performance
Goodput
Performance
Goodput
Part II
Models
Congestion Control
Heavy tail  Mice-elephants
Internet
Elephant
efficient & fair sharing
Mice
small delay
queueing + propagation
Congestion control
CDN
TCP
xi(t)
TCP & AQM
pl(t)
xi(t)
Example congestion measure pl(t)
Loss (Reno)
Queueing delay (Vegas)
Outline
Protocol
(Reno, Vegas, RED, REM/PI…)
x(t  1)  F ( p(t ), x(t ))
p(t  1)  G ( p(t ), x(t ))
Equilibrium
 Performance
 Throughput, loss, delay
 Fairness
 Utility
Dynamics
 Local stability
 Cost of stabilization
Outline
Introduction
Algorithms
Window flow control
TCP algorithm: Tahoe, Reno, Vegas
AQM algorithm: RED, REM, variants
Models
1 p
Duality model
Linear dynamic model
Flow control
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)

Model
Sources s
L(s) - links used by source s
Us(xs) - utility if source rate = xs
 Network
 Links l of capacities cl
x1
x1  x3  c2
x1  x2  c1
c1
c2
x2
x3
Primal problem
max
U ( x )
subject to
x c,
xs  0
s
s
s
l
l
Assumptions
Strictly concave increasing Us
 Unique optimal rates xs exist
 Direct solution impractical
l  L
History
Formulation
Kelly 1997
Penalty function approach
Kelly, Maulloo and Tan 1998
Kunniyur and Srikant 2000
Duality approach
Low and Lapsley 1999
Athuraliya and Low 2000, Low 2000
Many extensions…
History
Formulation
Kelly 1997
Penalty function approach
Kelly, Maulloo and Tan 1998
Kunniyur and Srikant 2000
Duality approach
Low and Lapsley 1999
Athuraliya and Low 2000, Low 2000
Many extensions…
Duality Approach
Primal : max
xs  0
Dual :
 U s ( xs )
subject to x l  cl , l  L
s

min D( p)   max
p 0
 xs  0
l 
U
(
x
)

p
(
c

x
s s s l l l ) 
Primal-dual algorithm:
x(t  1)  F ( p(t ), x(t ))
p(t  1)  G ( p(t ), x(t ))
Duality Model of TCP/AQM
 Source algorithm iterates on rates
 Link algorithm iterates on prices
 With different utility functions
Primal-dual algorithm:
x(t  1)  F ( p(t ), x(t ))
p(t  1)  G ( p(t ), x(t ))
Reno, Vegas
DropTail, RED, REM
Example
 Basic algorithm
source :
x (t  1)  U ( p (t ))
link :
p (t  1)  [ p (t )  g ( x (t )  c )]
' 1
s
s
s
l
l
l

l
Theorem (ToN’99)
Converge to optimal rates in asynchronous
environment
TCP schemes are smoothed versions of source
algorithm …
Summary
 Flow control problem
U s ( xs )

max
x 0
s
s
subject to
x c,
l
l
l  L
 Primal-dual algorithm
x(t  1)  F ( p(t ), x(t ))
p(t  1)  G ( p(t ), x(t ))
 Major TCP schemes
 Maximize aggregate source utility
 With different utility functions
Outline
Protocol
(Reno, Vegas, RED, REM/PI…)
x(t  1)  F ( p(t ), x(t ))
p(t  1)  G ( p(t ), x(t ))
Equilibrium
 Performance
 Throughput, loss, delay
 Fairness
 Utility
Dynamics
 Local stability
 Cost of stabilization
Reno: F
for
{
for
{
every ack (ca)
W += 1/W
}
every loss
W := W/2
}
ws t  
xs (t )(1  p(t ))
ws (t )

xs (t ) p(t )
ws
2
Primal-dual algorithm:
x(t+1) = F( p(t), x(t) )
p(t+1) = G( p(t), x(t) )
Reno, Vegas
DropTail, RED, REM
Reno: F
for
{
for
{
every ack (ca)
W += 1/W
}
every loss
W := W/2
}
ws t  
xs (t )(1  p(t ))
ws (t )

xs (t ) p(t )
ws
2
Primal-dual algorithm:
x(t+1) = F( p(t), x(t) )
p(t+1) = G( p(t), x(t) )
Reno, Vegas
DropTail, RED, REM
Reno: F
for
{
for
{
every ack (ca)
W += 1/W
}
every loss
W := W/2
}
ws t  
xs (t )(1  p(t ))
ws (t )

xs (t ) p(t )
ws
2
(1  p(t )) xs2 (t )
Fs  p(t ), x(t )   xs (t ) 

p(t )
2
Ds
2
Primal-dual algorithm:
x(t+1) = F( p(t), x(t) )
p(t+1) = G( p(t), x(t) )
Reno, Vegas
DropTail, RED, REM
Reno: Utility Function
(1  p(t )) xs2 (t )
Fs  p(t ), x(t )   xs (t ) 

p(t )
2
Ds
2
xs  Fs  p, x 
(1  p)
Ds2

xs2
p
2
2
 p
2
2
2  xs Ds
U sreno ( xs ) 
2
x D 
t an1  s s 
Ds
 2 
Reno: summary
 Equilibrium characterization
2
 p
2
2
2  xs Ds
Duality
 xs 
 U sreno ( xs )
 Congestion measure p = loss
 Implications
 Reno equalizes window w = Dsxs
 inversely proportional to delay Ds
 1 p dependence for small p
2
Ds p
Validation - Reno
 30 sources, 3 groups with RTT = 3, 5, 7ms + 6ms (queueing delay)
Link capacity = 64 Mbps, buffer = 50 kB
 Measured windows equalized, match well with theory (black line)
Reno & gradient algorithm
 Gradient algorithm
source :
xi (t 1)  Ui'1 (qi (t ))
link:
pl (t 1)  [ pl (t )  g ( yl (t )  cl )]
 TCP approximate version of gradient algorithm
Fi qi (t ), xi (t )   xi (t ) 
(1  qi (t ))
 i2
xi2 (t )

qi (t )
2
Reno & gradient algorithm
 Gradient algorithm
source :
xi (t 1)  Ui'1 (qi (t ))
link:
pl (t 1)  [ pl (t )  g ( yl (t )  cl )]
 TCP approximate version of gradient algorithm
qi (t ) 2


xi t  1   xi (t ) 
( xi (t )  xi2 (t ))
2


Ui'1 (qi (t ))

Active Queue Management
DropTail
DropTail
RED
REM
pl(t)
loss
delay
queue
price
G(p(t), x(t))
[1 - cl/xl (t)]+ (?)
[pl(t) + xl (t)/cl - 1]+
[pl(t) + xl(t) - cl]+
[pl(t) + gal bl(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
Queue
REM
queue = 1.5 pkts
utilization = 92%
p = Lagrange multiplier!
DropTail
queue = 94%
g = 0.05, a = 0.4,  = 1.15
p decoupled from queue
p increasing in queue!
RED
min_th = 10 pkts
max_th = 40 pkts
max_p = 0.1
Vegas
for every RTT
{
if W/RTTmin – W/RTT < a then W ++
if W/RTTmin – W/RTT > a then W --
}
for every loss
W := W/2
F:

1
xs t  1   xs (t )  2
Ds


1
xs t  1   xs (t )  2
Ds

xs t  1  xs (t )
G:
queue size
if ws (t )  d s xs (t )  a s d s
if ws (t )  d s xs (t )  a s d s
else
pl(t+1) = [pl(t) + xl (t)/cl - 1]+
Performance
Delay
Congestion measures: end to end queueing
delay
ds
Sets rate xs (t )  a s
qs (t )
Equilibrium condition: Little’s Law
Loss
No loss if converge (with sufficient buffer)
Otherwise: revert to Reno (loss unavoidable)
Vegas Utility
Equilibrium (x, p) = (F, G)
U
reno
s
( x )  a d log x
s
s
s
s
Proportional fairness
Vegas & Basic Algorithm
 Basic algorithm
source :
xs (t 1)  Us'1 ( p(t ))
 TCP smoothed version of Basic Algorithm …
Vegas & Gradient Algorithm
 Basic algorithm
source :
xs (t 1)  Us'1 ( p(t ))
 TCP smoothed version of Basic Algorithm …
 Vegas

1
xs t  1   xs (t )  2
Ds


1
xs t  1   xs (t )  2
Ds

xs t  1  xs (t )
if xs (t )  xs (t )
if xs (t )  xs (t )
else
U s'1 ( p(t ))
Validation
Source 1
RTT (ms)
Rate (pkts/s)
Window (pkts)
Avg backlog (pkts)
Source 3
17.1 (17)
1205 (1200)
20.5 (20.4)
9.8 (10)
meausred
21.9 (22)
1228 (1200)
27 (26.4)
Source 5
41.9 (42)
1161 (1200)
49.8 (50.4)
theory
Single link, capacity = 6 pkts/ms
5 sources with different propagation delays, as = 2 pkts/RTT
Persistent congestion
 Vegas exploits buffer process to compute prices
(queueing delays)
 Persistent congestion due to
 Coupling of buffer & price
 Error in propagation delay estimation
 Consequences
 Excessive backlog
 Unfairness to older sources
Theorem
A relative error of es in propagation delay estimation
distorts the utility function to
Uˆ s ( xs )  (1  e s )a s ds log xs  e s ds xs
Evidence
Without estimation error
With estimation error
 Single link, capacity = 6 pkt/ms, as = 2 pkts/ms, ds = 10 ms
 With finite buffer: Vegas reverts to Reno
Evidence
Source rates (pkts/ms)
# src1
src2
1 5.98 (6)
2 2.05 (2)
3.92 (4)
3 0.96 (0.94) 1.46 (1.49)
4 0.51 (0.50) 0.72 (0.73)
5 0.29 (0.29) 0.40 (0.40)
#
1
2
3
4
5
queue (pkts)
19.8 (20)
59.0 (60)
127.3 (127)
237.5 (238)
416.3 (416)
src3
src4
3.54 (3.57)
1.34 (1.35)
0.68 (0.67)
3.38 (3.39)
1.30 (1.30)
baseRTT (ms)
10.18 (10.18)
13.36 (13.51)
20.17 (20.28)
31.50 (31.50)
49.86 (49.80)
src5
3.28 (3.34)
Vegas/REM
 To preserve Vegas utility function & rates
 REM
xs  a
ds
s qs
end2end queueing delay
 Clear buffer : estimate of ds
 Sum prices : estimate of ps
 Vegas/REM

1
xs t  1   xs (t )  2
Ds


1
xs t  1   xs (t )  2
Ds

xs t  1  xs (t )
if xs (t )  xˆ s (t )
if xs (t )  xˆ s (t )
else
Vegas/REM
 To preserve Vegas utility function & rates
 REM
xs  a
ds
s qs
end2end queueing delay
xs :  a
 Clear buffer
 Sum prices : estimate of ps
ds
s Ds of
d s ds
estimate
 Vegas/REM

1
xs t  1   xs (t )  2
Ds


1
xs t  1   xs (t )  2
Ds

xs t  1  xs (t )
if xs (t )  xˆ s (t )
if xs (t )  xˆ s (t )
else
Vegas/REM
 To preserve Vegas utility function & rates
 REM
xs  a s
ds
end2end price
ps
 Clear buffer : estimate of ds
 Sum prices : estimate of ps
 Vegas/REM

1
xs t  1   xs (t )  2
Ds


1
xs t  1   xs (t )  2
Ds

xs t  1  xs (t )
if xs (t )  xˆ s (t )
if xs (t )  xˆ s (t )
else
Vegas/REM
 To preserve Vegas utility function & rates
 REM
xs  a s
ds
end2end price
ps
 Clear buffer : estimate of ds
 Sum prices : estimate of ps
 Vegas/REM

1
xs t  1   xs (t )  2
Ds


1
xs t  1   xs (t )  2
Ds

xs t  1  xs (t )
if xs (t )  xˆ s (t )
if xs (t )  xˆ s (t )
else
Performance
peak = 43 pkts
utilization : 90% - 96%
Vegas/REM
Vegas
Conclusion
Duality model of TCP: (F, G, U)
x(t  1)  F ( p(t ), x(t ))
p(t  1)  G ( p(t ), x(t ))
Reno, Vegas
 Maximize aggregate utility
 With different utility functions
DropTail, RED, REM
 Decouple congestion & performance
 Match rate, clear buffer
 Sum prices
Outline
Protocol
(Reno, Vegas, RED, REM/PI…)
x(t  1)  F ( p(t ), x(t ))
p(t  1)  G ( p(t ), x(t ))
Equilibrium
 Performance
 Throughput, loss, delay
 Fairness
 Utility
Dynamics
 Local stability
 Cost of stabilization
Model structure
Multi-link multi-source network
Rf(s)
F1
G1
FN
GL
Rb’(s)
TCP
Network
AQM
Duality model - AIMD
AI
MD
xi (t )
1
xi  xi (t   i )(1  qi (t )) 2
 xi (t   i )qi (t )
 i xi (t )
2
source rate
e2e prob
qi (t )   ml (t   lib )
l
Linear model - AIMD
AI
MD
xi (t )
1
xi  xi (t   i )(1  qi (t )) 2
 xi (t   i )qi (t )
 i xi (t )
2
Linearize around equilibrium
1
xi   xi qi xi(t)  2 qi (t )
τ i qi
In Laplace domain
1
1
xi ( s)   2
qi ( s)
τ i qi s  xi qi
Duality model - AIMD
p l  yl (t )  cl
ml (t )  ml ( pl (t ))
congestion
measure
marking
prob
Linear model - AIMD
p l  yl (t )  cl
ml (t )  ml ( pl (t ))
Linearize around equilibrium
p l  yi(t)
 l  ml' ( pl ) yl (t)
m
In Laplace domain
'
ml (s)  ml ( pl ) yl(s)
Aggregate rate
yl (t )   xi (t   i )
f
i
Linear Model - Network
Multi-link multi-source model
x
F1
Rf(s)
y
L(s)  R f (s)F (s)RbT (s)G(s)
G1
FN
GL
q
TCP
RbT(s)
p
Network
Closed loop system is stable if and only if
det (I + L(s)) = 0
for no s in closed RHP
AQM
Linearized system
x
y
Rf(s)
F1
G1
FN
GL
q
Rb
p
’(s)
1
ac
1
 i s
L( s ) 



e
*
* *
xn  b n s

p
(

s

p
w ) s  ac s  1
i
i
i
e

c n n
TCP
RED
queue
delay
Papers
netlab.caltech.edu
 Scalable laws for stable network congestion
control (CDC2001)
 A duality model of TCP flow controls (ITC, Sept 2000)
 Optimization flow control, I: basic algorithm &
convergence (ToN, 7(6), Dec 1999)
 Understanding Vegas: a duality model (J. ACM, 2002)
 REM: active queue management (Network, May/June 2001)