Peformance models of TCP

 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
TCP 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?
congested router drops packets
 want to understand
(quantify) this interaction
 Generic TCP behavior
 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
receiver

W
sender
Generic TCP behavior
 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
receiver

TD

sender
Generic TCP Behavior
 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
 receiver

sender
TO
Generic TCP Behavior
 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
 TCP throughput/loss relationship
loss occurs
Idealized model:
 W is maximum supportable
W
window size (then loss
TCP occurs)
window  TCP window starts at W/2
size
grows to W, then halves,
W/2 then grows to W, then
halves…
 one window worth of
packets each RTT
 to find: throughput as
time (rtt)
function of loss, RTT
 TCP throughput/loss relationship
# packets sent per “period” =

TCP
window
size

W/2
period

time (rtt)
 TCP throughput/loss relationship
# packets sent per “period” =
W W  W /2
W
W    1  ...  W   (  n)
2 2  n 0 2
TCP
W  W W /2
window    1   n
size 2  2 n 0
W/2 W  W W / 2(W / 2  1)
   1 
period 2  2 2
3 3
 W2  W
8 4
3 2
time (rtt)  W
8
 TCP throughput/loss relationship
3 2
# packets sent per “period”  W
8
W
1 packet lost per “period” implies:
TCP
window
8 8
ploss  or: W 
size 3W 2 3 ploss
W/2
3 packets
period B  avg._thruput  W
4 rtt
1.22 packets
B  avg._thruput 
ploss rtt
time (rtt)
B throughput formula can be extended
to model timeouts and slow start (PFTK)
Recall RED queue management
 dropping/marking
packets depends
on average queue
length -> p = p(x)

Marking probability p
 More generally:
active queue
management pmax

(AQM) 0 tmin tmax

2tmax
Average queue length x
Bottleneck behavior
bottleneck router:
 capacity fully utilized
 all interfering sessions
see same loss prob.
 do all sessions see
same thruput?

i Bi (RTTi ,p) = C
C - router bandwidth
Bi - throughput of flow i
 Single bottleneck: infinite flows
 N infinite TCP sessions
 two way propagation
delay Ai, i = 1,…,N
 throughput Bi(p,RTTi)

 one bottleneck router

 RED queue management

• avg. queue length x ; dropping probability p(x)

 to discover
 B: TCP sessions’ throughput,
i
 router behavior, e.g., drop prob. avg. queue len.
Model and solution
 model

p = p(x) (AQM)
RTTi =B
Ai(+x)x =/CC, for j =1trip
(round ,…,Ntime)
i
i B (p , RTT i) = C, for j =1 ,…,N
 solve a fixed point problem for x
 unique solution provided B is monotonic and
continuous on x
 resulting x can be used to obtain RTTi and p
 Model versus simulation: single
bottleneck, infinite flows
• fixed router capacity 4 Mbps and RED parameters
• 10-120 TCP flows
• two-way prop. delay 20+2i ms, i = 1,…,N

throughput router loss

 New and improved TCP

• new/improved, BUMass(p) BUMass(p)

thruput
• TCP, BTCP(p)
BTCP(p)

BUMass(p) > BTCP(p)

p

19
 Sharing bottleneck with TCP

C
NUM

NTCP

NUM BUM(p) + NTCP Bni(p) = C

 BUM(p) > BTCP(p)

• a win! friendly? p
20
 Replacing TCP with TCP UMass

N BUM(pUM) = C C
vs N

N BTCP(pTCP) = C
 pUM > pTCP

• a loss!

pTCP pUM
21
 simple model for TCP B c ,c ≈ 1.2
T p
 bottleneck principle

 multiple bottlenecks
 fluid models
 14

12

10

B 6

0
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

p
Use of FEC
C
 10% pkt loss  poor thruput

use packet level FEC! 10%

TCP p TCP
encoder decoder rcvr
source
Use of FEC
C
 10% pkt loss  poor thruput

use packet level FEC! 10%

pFEC

TCP p TCP
encoder decoder rcvr
source
ACKs
• pFEC << p
Use of FEC

 available bandwidth, CFEC < Cwo

B
FEC () = Bwo( ) = BTCP( )
 N B (p ) = C
wo wo wo

NB (pFEC) = CFEC

FEC

 pFEC > pwo

 FEC reduces performance!
Multiple Bottleneck: infinite flows
 N TCP flows
 throughputs B = <Bi (Ri,pi)>
 V congested AQM routers
 capacities C = <Cv >
 avg. queue lengths x = <xv >
 discard prob. p = <pv (xv )>

bottleneck router model

i Bi (x ) = Cv , v =1,…,V

V equations, V unknowns
 Results: multiple bottleneck, infinite flows

• tandem network core, 5 -

10 routers
• 2-way propagation delay
20-120 ms
• bandwidth, 2-6 Mbps
throughput
• PFTK model error
• throughput < 10%
• loss rate < 10%
• avg. queue length < 15%
• similar results for cyclic
networks
router loss
Comments
 what about UDP / non-TCP flows?
 If there are “non-responsive” flows, just
decrease bottleneck capacity by non-responsive
flow rate
 what about short lived flows?
 Hard (some work in sigcomm 2001 – massoulie)
 note: throughout, assumption that time to
send packets in window is less that RTT
Dynamic (transient) analysis of TCP fluids

 model TCP traffic as fluid

 describe behavior of flows and queues using
Ordinary Differential Equations
 solve resulting ODEs numerically
 Loss Model
AQM Router
B(t)
Packet Drop/Mark p(t)

Sender Receiver

Round Trip Delay ()

Loss Rate as seen by Sender: (t = B(t-p(t-

A Single Congested Router

 focus on single
bottlenecked router
TCP flow i  capacity {C (packets/sec) }
 queue length q(t)
 discard prob. p(t)
 N TCP flows thru router
 window sizes Wi(t)
AQM
 round trip time
router Ri(t) = Ai+q(t)/C
C, p
 throughputs
Bi (t) = Wi(t)/Ri(t)
 Adding RED to the model

RED: Marking/dropping based on average queue length x(t)

1
Marking probability p

pmax

tmin tmax 2tmax

Average queue length x

- q(t)
- x(t)
x(t): smoothed, time averaged q(t)

t ->
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 + vVi qv(t)

Loss/marking probability - cumulative prob

pi (t) = 1-v Vi (1 - pv(qv(t)))

Link bandwidth constraints

Queue equations
How well does it work?
 OC-12 – OC-48 links
 RED with target delay
5msec OC-12
 2600 TCP flows
OC-48

 decrease to 1300 at
30 sec. 2600  j 2600  j
1300  j
 increase to 2600 at 90
sec.
t=30 t=90
 simulation
fluid model
instantaneous delay

time (sec)

Good queue length match

 average window size
simulation
fluid model
window
size

simulation
fluid model

time (sec)

time (sec)
matches average window size
Scaling Properties

OC-12 OC-12  j

OC-48 OC-48  j

2600 1300 2600 2600  j 2600  j

1300  j

t=30 t=90 t=30 t=90

Wk(t) = Wj k(t)

qv(t) = qjv(t)/100
 Summary: TCP flows as fluids
What have we seen?
 model TCP as constant rate fluid flows
 rate sensitive to congestion via:
 capacities C = <C >
v

 avg. queue lengths x = <xv >

 discard prob. p = <pv (xv )>
 dynamic (transient) behavior of TCP modeled as
system of differential equations

ability to predict performance of

system of TCP flows using fluid models