0% found this document useful (0 votes)
43 views44 pages

ELE539A: Optimization of Communication Systems Lecture 9: NUM and TCP Congestion Control

The document discusses TCP congestion control protocols and network utility maximization. It introduces TCP congestion control, including algorithms like Tahoe and Reno. It also covers network utility maximization and how TCP congestion control can be modeled as solving an implicit convex optimization problem.

Uploaded by

Minh Q. Nguyen
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
43 views44 pages

ELE539A: Optimization of Communication Systems Lecture 9: NUM and TCP Congestion Control

The document discusses TCP congestion control protocols and network utility maximization. It introduces TCP congestion control, including algorithms like Tahoe and Reno. It also covers network utility maximization and how TCP congestion control can be modeled as solving an implicit convex optimization problem.

Uploaded by

Minh Q. Nguyen
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 44

ELE539A: Optimization of Communication Systems

Lecture 9: NUM and TCP Congestion Control

Professor M. Chiang
Electrical Engineering Department, Princeton University

February 24, 2006


Lecture Outline

• TCP congestion control protocol

• Network utility maximization

• Reverse engineering

Acknowledgement: Steven Low


Last Lecture

• How to derive subgradient: Danskin’s Theorem

• How to choose step size: diminishing and constant step size rules
Network Utility Maximization

Basic NUM:
P
maximize s Us (xs )
subject to Rx  c
x0

• Extension of LP-based Network Flow Problem

• TCP congestion control protocols reverse engineered: they solve the


basic NUM for different utility functions
Dual-based Distributed Algorithm

Basic NUM with concave smooth utility functions:

Convex optimization (Monotropic Programming) with zero duality gap

Lagrangian decomposition:
0 1
X X X
L(x, λ) = Us (xs ) + λl @cl − xs A
s l s:l∈L(s)
2 0 1 3
X X X
= 4Us (xs ) − @ λl A xs 5 + cl λl
s l∈L(s) l
X X
s
= Ls (xs , λ ) + cl λl
s l

Dual problem:
minimize g(λ) = L(x∗ (λ), λ)
subject to λ0
Dual-based Distributed Algorithm

Source algorithm:

x∗s (λs ) = argmax [Us (xs ) − λs xs ] , ∀s

• Selfish net utility maximization locally at source s

Link algorithm (gradient or subgradient based):


2 0 13+
X
λl (t + 1) = λl (t) − α(t) cl −
4 @ xs (λs (t))A5 , ∀l
s:l∈L(s)

• Balancing supply and demand through pricing

Certain choices of step sizes α(t) of distributed algorithm guarantee


convergence to globally optimal (x∗ , λ∗ )
TCP Congestion Control

• Window-based end-to-end flow control, where destination sends ACK


for correctly received packets and source updates window size (which is
proportional to allowed transmission rate)

• Several versions of TCP congestion control distributively dissolve


congestion in bottleneck link by reducing window sizes

• Sources update window sizes and links update (sometimes implicitly)


congestion measures that are feed back to sources using the link

Optimization-theoretic model: TCP congestion control carries out a


distributed algorithm to solve an implicit, global convex optimization
(network utility maximization), where source rates are primal variables
updated at sources, and congestion measures are dual variables (shadow
prices) updated at links
TCP/IP Protocol Stack

Applications (e.g. Telnet, HTTP)


TCP UDP ICMP
IP ARP
Link Layer (e.g. Ethernet, ATM)
Physical Layer (e.g. Wireless, DSL)
Packet Terminology

Application Message
MSS
TCP Segment
TCP hdr TCP data
IP Packet 20 bytes

IP hdr IP data
Ethernet Frame 20 bytes

Ethernet Ethernet data


14 bytes MTU 1500 bytes 4 bytes
Success of TCP/IP

WWW, Email, Napster, FTP, …

Applications Simple/Robust
„ Robustness against failure
TCP/IP „ Robustness against technological
evolutions
Transmission „ Provides a service to applications
„ Doesn’t tell applications what to do
Ethernet, ATM, POS, WDM, …
TCP Protocol
„End-to-end control
„Session initiation and termination
„In-order recovery of packets
„Flow control / congestion control
„…
Why Congestion Control

Oct. 1986, Internet had its first congestion collapse (LBL to UC


Berkeley)

• 400 yards, 3 hops, 32 kbps

• throughput dropped by a factor of 1000 to 40 bps

1988, Van Jacobson proposed TCP congestion control

• Window based with ACK mechanism

• End-to-end
Window Flow Control

RTT

Source 1 2 W 1 2 W
time

data ACKs

Destination 1 2 W 1 2 W
time

„~ W packets per RTT


„Lost packet detected by missing ACK
TCP Congestion Control
„ 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
„ Others…
Window-based Congestion Control

Limit number of packets in network to window size W


W ×Message Size
Source rate allowed (bps) =
RTT
Too small W : under-utilization of link capacities

Too large W : link congestion occurs

Effects of congestion:

• Packet loss

• Retransmission and reduced throughput

• Congestion may continue after the overload


Basics of Congestion Control

• Goals: achieve high utilization without congestion or unfair sharing

• Receiver control (awnd): set by receiver to avoid overloading receiver


buffer

• Network control (cwnd): set by sender to avoid overloading network

• W = min(cwnd, awnd)

• Congestion window cwnd usually the bottleneck

Different algorithms for short and long-lived flows


TCP Tahoe (Jacobson 1988)

window

time
SS CA

SS: Slow Start


CA: Congestion Avoidance
Slow Start

„Start with cwnd = 1 (slow start)


„On each successful ACK increment cwnd
cwnd ← cnwd + 1
„Exponential growth of cwnd
each RTT: cwnd ← 2 x cwnd
„Enter CA when cwnd >= ssthresh
Slow Start
sender receiver
cwnd
1
data packet
1 RTT
ACK
2

3
4

5
6
7
8

cwnd ← cwnd + 1 (for each ACK)


Congestion Avoidance

„Starts when cwnd ≥ ssthresh


„On each successful ACK:
cwnd ← cwnd + 1/cwnd
„Linear growth of cwnd
each RTT: cwnd ← cwnd + 1
Congestion Avoidance
sender receiver
cwnd
1
data packet

ACK
2 1 RTT

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 6 7

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++ (SS)
else W += 1/W (CA)
}
for every loss {
ssthresh = W/2
W = 1
}
TCP Reno (Jacobson 1990)

window

time
SS CA

SS: Slow Start


CA: Congestion Avoidance Fast retransmission/fast recovery
TCP Vegas (Brakmo & Peterson 1994)

window

time
SS CA

„ Converges, no retransmission
„ … provided buffer is large enough
Vegas CA algorithm
for every RTT
{ if W/RTTmin – W/RTT < α then W ++
if W/RTTmin – W/RTT > β then W -- }
for every loss
W := W/2 queue size
Queue Buffer Processes

At intermediate links:

• FIFO buffer process updates queuing delay as measure of congestion


for Vegas and feeds back to sources

• Drop tail updates packet loss as measure of congestion for Reno and
feeds back to sources

• RED: instead of dropping only at full buffer, drops packets with a


probability that increases with (exponentially weighted) average queue
length (example of Active Queue Management)
Analytic Model

Communication network with L links, each with fixed capacity cl


packets per second, shared by N sources, each using a set Li of links

R: 0 − 1 routing matrix with Rli = 1 iff l ∈ Li

Deterministic flow model: xi (t) at each source i at discrete time t

Aggregate flow on link l:


f
X
yl (t) = Rli xi (t − τli )
i

f
where τli is forward transmission delay

Each link updates congestion measure (shadow price) pl (t). Each source
has access to aggregate price along its route (end-to-end):
X
b
qi (t) = Rli pl (t − τli )
l

b is backward delay in feedback path


where τli
Generic Source and Link Algorithms

Each source updates rate (zi is a local state variable):

zi (t + 1) = Fi (zi (t), qi (t), xi (t))


xi (t + 1) = Gi (zi (t), qi (t), xi (t))

Often xi (t + 1) = Gi (qi (t), xi (t))

Each link updates congestion measure:

vl (t + 1) = Hl (yl (t), vl (t), pl (t))


pl (t + 1) = Kl (yl (t), vl (t), pl (t))

Notice access only to local information (distributed)


Goals and Limitations

Goals: To characterize

• Throughput, delay, loss

• Fairness

• Reverse engineering: start with a given protocol

• Forward engineering: start with a desired equilibrium

Limitations:

• Congestion avoidance phase only (long-lived flows)

• Deterministic fluid model

• Average behavior

• Equilibrium properties
Utility Maximization and Equilibrium Properties

b and τ f set to 0.
At equilibrium: y ∗ = Rx∗ , q ∗ = RT p∗ . τli li

Let x∗i = fi (qi∗ ) where fi is a positive, decreasing function

Construct source utility function Ui such that Ui′ (xi ) = fi−1 (xi ) (thus
increasing and concave)

Equilibrium solves the local profit maximization problem over xi :

maximize [Ui (xi ) − xi qi∗ ]

Need local profit-seeking to align with social welfare

Use duality-based pricing to solve basic NUM (last lecture)


Link Algorithm

One possibility: apply gradient algorithm to the Lagrangian:


X X
L(x, p) = [Ui (xi ) − qi xi ] + pl cl
i l

Congestion price updates by gradient methods:


   +
X
λl (t + 1) = λl (t) − α(t) cl −
  xs (λs (t))  , ∀l
s:l∈L(s)

In general: complementary slackness condition for dual optimality

p∗l > 0 indicates yl∗ = cl (link saturation) and

yl∗ < cl indicates p∗l = 0 (buffer clearance)

Any link algorithm satisfying complementary slackness defines an


equilibrium, but may not converge
TCP Reno

RTT τi assumed constant. Loss probabilities assumed to be small:


X
qi (t) ≈ pl (t)
l∈Li

Since (1 − qi (t))xi (t) of ACK are positive, each incrementing window size
by 1/wi (t), and qi (t)xi (t) are negative, each halfing the window, using
xi (t) = wi (t)/τi , we have

1 − qi (t) 1 2
ẋi = − qi (t)xi (t)
τi2 2

At equilibrium:
2
qi∗ =
2 + (τi x∗i )2
Using Ui′ (x∗i ) = qi∗ , utility function for TCP Reno
√  
2 τ x
i i
Ui (xi ) = tan−1 √
τi 2
TCP Vegas

Window size ws
ws (t)
Propagation delay ds . Expected rate ds
ws (t)
Queuing delay qs and total delay Ds . Actual rate Ds

Source algorithm:

ws (t) ws (t)

1
w (t) + if − < αs
 s Ds (t) ds Ds (t)


1 ws (t) ws (t)
ws (t + 1) = ws (t) − Ds (t)
if ds
− Ds (t)
> αs


ws (t) else.

Equilibrium round-trip time and window size satisfy:


ws∗ ws∗
− ∗ = αs
ds Ds
TCP Vegas: Log Utility Function

Us (xs ) = αs ds log xs

Complementary slackness satisfied. For KKT, need to also check


′ ∗ αs ds X

Us (xs ) = = p l
x∗s l∈s

Let b∗l be equilibrium backlog at link l. Window size equals


bandwidth-delay product plus total backlog:
X x∗
∗ ∗ s ∗
ws = xs ds + bl
c
l∈s l

Using xs = ws /Ds , we have


 
ws∗ ws∗ 1 ∗ ∗ 1  X x∗s ∗ 
αs = − ∗ = (ws − xs ds ) = b
ds Ds ds ds l∈s cl l

b∗
since p∗l = l
cl
(dual variable is queuing delay)
TCP Vegas: Source-Link Algorithms

Primal variable is source rate, updated by source algorithm:

ws (t + 1) = [ws (t) + vs (t)]+


1
vs (t) = [1(xs (t)qs (t) < αs ds ) − 1(xs (t)qs (t) > αs ds )]
ds + qs (t)
ws (t)
xs (t) =
ds + qs (t)

Dual variable is queuing delay, updated by link algorithm:


 +
1
pl (t + 1) = pl (t) + (yl (t) − cl )
cl

αs ds
Equilibrium: x∗s = qs

TCP Reno and Vegas

TCP Reno (with Drop Tail or RED):

• Source utility: arctan

• Link price: packet loss

TCP Vegas (with FIFO)

• Source utility: weighted log

• Link price: queuing delay


Implications: Delay, Loss, Fairness

• TCP Reno: equilibrium loss probability is independent of link


algorithms and buffer sizes. Increasing buffer sizes alone does not
decrease equilibrium loss probability (buffer just fills up)

• TCP Reno: discriminates against connections with large propagation


delays

• Desirable to decouple link pricing from loss

• TCP Vegas: bandwidth-queuing delay product equals number of


packets buffered in the network x∗s qs∗ = αs ds

• TCP Vegas: achieves proportional fairness

• TCP Vegas: gradient method for updating dual variable. Converges


with the right scaling (γ small enough)

• Persistent congestion, TCP-friendly protocols ...


Numercal Example: Single Bottleneck
Average Sending Rate for Class 1a (rtt: 15 ms) PF Average Sending Rate for Class 3a (rtt: 20 ms) PF
2000 2000
TCP Vegas Sending Rate (KB/s)

TCP Vegas Sending Rate (KB/s)


1800 1800
1600 1600
1400 1400
1200 1200
1000 1000
800 800
600 600
400 400
200 theoretical optimal rate 200 theoretical optimal rate
actual rate actual rate
0 0
0 2 4 6 8 10 12 14 16 18 20 0 2 4 6 8 10 12 14 16 18 20
Time (second) Time (second)

Average Sending Rate for Class 4a (rtt: 30 ms) PF Average Sending Rate for Class 5a (rtt: 40 ms) PF
2000 2000
TCP Vegas Sending Rate (KB/s)

TCP Vegas Sending Rate (KB/s)

1800 1800
1600 1600
1400 1400
1200 1200
1000 1000
800 800
600 600
400 400
200 theoretical optimal rate 200 theoretical optimal rate
actual rate actual rate
0 0
0 2 4 6 8 10 12 14 16 18 20 0 2 4 6 8 10 12 14 16 18 20
Time (second) Time (second)
Numercal Example: General Cases
Average Window Size for Class 2a (rtt: 15 ms) WPF Average Window Size for Class 3a (rtt: 20 ms) WPF
25 50
45
TCP Vegas cwnd Size (KB)

TCP Vegas cwnd Size (KB)


20 40
35
15 30
25
10 20
15
5 10
theoretical optimal window 5 theoretical optimal window
actual window actual window
0 0
0 2 4 6 8 10 12 14 16 18 20 0 2 4 6 8 10 12 14 16 18 20
Time (second) Time (second)

Average Window Size for Class 4a (rtt: 30 ms) WPF Average Window Size for Class 5a (rtt: 40 ms) WPF
60 90
80
TCP Vegas cwnd Size (KB)

TCP Vegas cwnd Size (KB)

50
70
40 60
50
30
40
20 30
20
10
theoretical optimal window 10 theoretical optimal window
actual window actual window
0 0
0 2 4 6 8 10 12 14 16 18 20 0 2 4 6 8 10 12 14 16 18 20
Time (second) Time (second)
Stability and Dynamics

• Optimization theoretic analysis has focused on equilibrium state

• TCP congestion control may oscillates

• Use control theoretic ideas to stabilize TCP

• FAST TCP implemented in real networks, increasing bandwidth


utilization efficiency from 20% to 90%
92%
2G

48%
Average
utilization
95%
1G

27%
16%
19%

txq= 100 txq= 10000 txq= 100 txq= 10000

Linux TCP Linux TCP FAST Linux TCP Linux TCP FAST
Three Meanings of the Course Title

• Forward engineering: Formulate a communication systems problem as


an optimization problem and solve it

Example: information theory, physical layer signal processing, routing ...

• Reverse engineering: Given a network protocol, interpret it as a


distributed algorithm solving an implicit optimization problem

Example: TCP congestion control (can also go the reverse direction:


start with Us and find out Fi )

• Extension: Extend the underlying theory by generalizing using


optimization theory

Example: detection and estimation


Lecture Summary

• TCP congestion control is implicitly maximizing network utility over


linear flow constraints, where each source updates source rate (primal
variable) and each link updates congestion measure (dual variable)

• NUM solution algorithm approximated by TCP window update and


queue management

• Models, understands and improves TCP congestion control protocols

Readings: S. H. Low, F. Paganini, J. C. Doyle, “Internet congestion


control,” IEEE Control Systems Magazine, Feb. 2002.

S. H. Low, “A duality model of TCP and queue management


algorithms,” IEEE/ACM Trans. Networking, August 2003.

You might also like