Modelling and Stability of TCP Peter Key MSR Cambridge.

Modelling and Stability of TCP

Peter KeyMSR Cambridge

Outline

• Simple TCP models• Utility Maximisation - a framework for

fairness– General Framework– TCP examples

• Stability, Delay and Stochastic Stability• Stochastic arrivals• Multipath routing• Startup / slow start

Outline

• Simple TCP models• Utility Maximisation - a framework for

fairness– General Framework– TCP examples

• Stability, Delay and Stochastic Stability• Stochastic arrivals• Multipath routing

Modelling TCP

• Why? Insight, understanding better design• Mainly focussed on CA phase

– But transients/slow start may be as/more important!• Typically convert behaviour to a deterministic limit (an ODE)

• Issues– Going from stochastic to deterministic makes (several) assumptions

• Eg. Large number of flows– Window halving causes problems (non-smooth function), can justify

with a lot of hard maths (& get v. slightly different results)– Feedback (eg loss) often assumed stochastic / uncorrelated. May

be badly inaccurate (eg small flows, with drop tail)

Simple TCP model for CA• Window increases by (1/W ) per ACK, and decrease by (Wp/ 2)

where p is packet loss• But if T is the RTT, then this occurs in time (T/W ), hence

• Gives steady state:

• Throughput:

212

W pdWdt T T

2W

p

1 2WT T p

Rate model TCP model

• Rate of packet send, is x=W/T

• As if user is trying to maximise net utility =utility – cost where • Utility:

• Cost (penalty) = px

211 2

2

pxTdt

dWTdt

dx

xTxU 2

2)(

Outline

• Simple TCP models• Utility Maximisation - a framework for

fairness– General Framework– TCP examples

• Stability, Delay and Stochastic Stability• Stochastic arrivals• Multipath routing

Theorem

• If each user independently updates their rates/window, then system converges to the unique equilibrium, where each user has mean rate

• Hence have can think of TCP as performing an implicit optimisation

• Equivalently system is maximising

2rr

r r

mx

T p

( ) Congestion_costusers resources

Utility user

Service Requirements & Bandwidth sharing (Shenker)

RejectionOr randomise

Limited capacityShare out bandwidth

Limited capacity

Utility U(x)

Rate x

Utility U(x)

Real TimeElastic / Data

Game theoretic properties

• User has Utility Ur(x) with allocation x• Then Proportional fairness = Nash

Bargaining scheme with

• Nash Bargaining is the only arbitration scheme to satisfy certain axioms of – Pareto optimality– Linearity– “Irrelevant alternatives” (contentious)– Symmetry

logr r r rU x w x

Fairness Examples, eg

Max-min

½

½ ½

Proportional

1/3

2/32/3

0

1 1

TCP approx

0.4

0.6 0.6

Max load

xxU Log

xxU

or

xxU

1Log)( 2

2 arctan ( )2

xU x or U x

x

xxU Log

Utility functions, rate control & TCP

• Can map utility functions /utility maximisation problem rate control algorithms– Eg, TCP and TCP-like controllers

• Gives rate control as an ODE– Rates reacts to signals / prices

• “Primal” algorithms : end-systems aggregate information

• (appropriate for long RTTs and simple )

• “Dual” algorithms : resources (eg routers) adjust prices and send more explicit feedback

• Primal – dual mix both

Outline

• Simple TCP models• Utility Maximisation - a framework for

fairness– General Framework– TCP examples

• Stability, Delay and Stochastic Stability• Stochastic arrivals• Multipath routing

time

load

mark

loss

time

load

mark

loss

load

mark

loss

Router/gateway

mark information

Wide Area Dynamic Resource Allocation

Generic Primal algorithm

)(tptxwtxdtd

rrrr

sjssjr txptp

:

Gain: tune for convergence / stability

))((')( txUtxw rrrr generalise: eg

Global Stability

• Theorem:– Above dynamical system has a unique stable

fixed point to which all trajectories converge. The fixed point is weighted proportionally fair

• Based on Lyapunov functions

What’s missing

• Effect of time delays– Feedback to sender delayed (by RTT)– Can use ideas from control theory (eg Nyquist) to

prove end to end stability

• Stochastic effects– Rate control only gives mean rates– Stochastic analysis can provide variances

• Small systems / dependent feedback (eg drop tail)/- discrete time / simple models give insight

TCP-like rate control algorithm

• cwnd T, rate x cwnd / T• For route r :

– Increase cwnd by ar cwnd n per positive ACK

– Decrease cwnd by br cwnd m per loss/congestion notification (m > n )

• Eg, For TCP Reno m=1, n=-1, a=1, b=1/2

)())(())(1())(()(

)( tpTtxbtpTtxaT

Ttxtx

dtd

rm

rrrrn

rrrr

rrr

Stability

• Equilibrium point (thruput)

• Can derive a (local) stability condition that depends only on e-t-e path and local resources. Equilibrium is stable if there is a global constant s.t

nm

r

r

r

r

rr b

aT

x

/111

2

)(),()( nrrrjj Txaxpxpx

Per resource (price) sensitivity Per route increase (“aggressiveness)”

Variance (Ott ‘99)

• But feedback signals are noisy

• Stability depends on the decrease (m and b)

)1)((2))((Var

11

r

mr

mrr

r pnmTxb

tx

Choice of congestion controllers?

• Delay stability affected by increase behaviour (n)– For Reno, instability for small windows– Slow to react for large windows– Putting n=0 (eg scalable TCP) can make stability

independent of congestion window

• Stochastic stability depends on decrease (m)– Scale invariance (for coeff of variation) if m=1– m=-1 gives scale invariance for variance

• BUT … trade-off with convergence speed and BEWARE model limitations

Dynamic/Flow level stability

• More realistic model: stochastic arrivals– Demands (eg sessions) are as a stochastic process

• Eg arrive as Poisson process, rate • Mean file size

• N r in progress

• Allocate xr to flow r

• Stable if

• Per resource stability sufficient (eg with TCP ) • Not true if priorities ….

load rr

r

r1

r rF

lrlr

rr CxN :

lrlr

r C:

Outline

• Simple TCP models• Utility Maximisation - a framework for

fairness– General Framework– TCP examples

• Stability, Delay and Stochastic Stability• Stochastic arrivals• Multipath routing

Multipath routing

• Can combine with congestion control: multipath congestion control

• Gives– Efficiency / performance gains– Robustness

• Can implement in two ways– Coordinated (single controller per multipath set)– Uncoordinated (eg parallel TCP)

• At what layer (s)?

Receiver Driven Multipath

Receiver

Peer

Peer

Peer

• Kazaa – manual route selection• Skype – fixed , “automatic” best choice• BitTorrent – dynamic best 4 with reselection

Coordinated multipath controller

• Users of type r can use a set of routes R(r)– Send xsr on route sR(r)

–

• Sends traffic on “least cost” route (eg, lowest loss)– Splits if several

• Stable & Efficient: routes traffic to minimise total cost, independent of rate control used (utility function)

• Single rate-control (utility function Ur) per user across all routes. Single RTT dependence– Implies cannot have RTT bias per route

jj

rRsxrr

rr pxUNMaximise )(

)(

x

Uncoordinated multipath controller

• Users of type r can use a set of routes R(r)– Send xsr on route sR(r)

• Controller (rate control/utility) per route s chosen by user, eg parallel TCP

• Easier to implement … but lose efficiency • Need to modify to be fair to single flows

jj

r s rRssrsrr pxUNMaximise )(

)(

x

Coordination – does it matter?

• Some recent results (Infocom 07, ICASSP) for static demand complement dynamic results

• Static route choices, even when users greedily choose best from a set (cf Kazaa, Skype) can lose efficiency – Eg , ½ throughput in a simple (contrived) example– Even when no loss of efficiency, can give worse performance or

fairness

• For dynamic route choices (eg BitTorrent), where periodically other routes chosen /sampled and higher thruput route chosen– Coordinated is “optimal” (maximises social welfare)– Uncoordinated performs as well only if no RTT bias in controllers

Eg Performance with coordination:

• Example network: sharp link capacity constraints

• Schedulable region with coordination:

Ca

bc

2C

a

bc

2

2

2

A B

B C

AC

so stable provided

1

Schedulable region depends on utility function

a loss of 30% efficiency.

Ca

bc

For TCP, stable provided

10.7

2

Performance without coordination

Uncoordinated controllers & efficiency

• Example:• Long fat links (delay T),

short-thin links ()• Flows aa’, bb’,cc’• If

• Users choose short-long-short:

• Lose 50% of coordinated thruput

a b

a’

c

b’

c’

12

22

TT T

Selecting relay or access points

• Coordinated and uncoordinated have same stability region

• But uncoordinated can have higher “cost”, depends on fairness condition

• Can show in the static case, for coordinated gives “max-min” fairness wrt load, uncoordinated “unfair”

AA BB CC

What about slow start?

• Current slow-start can be viewed as an example of “risk-averse behaviour” (ISQE, Key / Massoulie)

• Mice vs elephants:– Optimal strategy is to let mice go as quickly as

possible (blast away)• Like SRPT• Doesn’t hurt the elephants

– Slow start (and CA?) does the reverse

• Most flows are short (mice)• Most volume in a few long flows (elephants)• Currently, bias against mice• If use weights w inversely related to

(remaining) file size, can improve response dramatically

Capacity

Scheduling File Tansfers

Weighted shares

• We know how to design simple, robust, scalable sharing algorithms …eg generically

• Weight is like a “willingness to pay” … but why cooperate

( )(1 ) ( )d

x w x tt p px tdt

weightPrice Pr{Mark}

Questions???