Modelling and Stability of TCP Peter Key MSR 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

TCP in one slide Slow Start (exponential) Slow Start (exponential) Congestion Avoidance (Linear) Congestion Avoidance (Linear) Time (in round-trip times) Packets per RTT (window) Loss Window Halved on Packet Loss

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:

Simple models of TCP (CA) Single resource, lose pkts with prob. p, x is window in MSS Strictly periodic loss (Sawtooth) Random loss,...

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

Refined 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

Outline Simple TCP models Utility Maximisation - a framework for fairness –General Framework –TCP examples Stability, Delay and Stochastic Stability Stochastic arrivals Multipath routing

Different Users Suppose a number of different users, indexed by r, round trip times T r utility functions becomes More generally, users can increase window at rate m r per RTT, decrease window by 2m r equivalently

Different Users Network: number of resources J, feedback signal p j, aggregate feedback to user r is Example: – p j represents packet loss, loss approximately additive for small p j and losses are independent –p j represents a marking signal with additive marks

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

Service Requirements & Bandwidth sharing (Shenker) Rejection Or randomise Limited capacity Share out bandwidth Limited capacity Utility U(x) Rate x Utility U(x) Real Time Elastic / Data

Game theoretic properties User has Utility U r (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

Fairness Examples, eg Max-min ½ ½ ½ Proportional 1/31/3 2/32/3 2/32/ TCP approx Max load

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

Router/gateway mark information Wide Area Dynamic Resource Allocation

Generic Primal algorithm Gain: tune for convergence / stability generalise: eg

Interpretation of primal algorithm Resource j generates feedback signals at rate p j (t) signals sent to each user r whose route passes through resource j multiplicative decrease in flow x r at rate proportional to stream of feedback signals received linear increase in flow x r at rate proportional to w r

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

Whats 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 a r cwnd n per positive ACK –Decrease cwnd by b r cwnd m per loss/congestion notification (m > n ) Eg, For TCP Reno m=1, n=-1, a=1, b=1/2

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 Per resource (price) sensitivity Per route increase (aggressiveness)

Variance (Ott 99) But feedback signals are noisy Stability depends on the decrease (m and b)

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 x r to flow r Stable if Per resource stability sufficient (eg with TCP ) Not true if priorities ….

Outline Simple TCP models Utility Maximisation - a framework for fairness –General Framework –TCP examples Stability, Delay and Stochastic Stability Stochastic arrivals 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 Kazaa – manual route selection Skype – fixed, automatic best choice BitTorrent – dynamic best 4 with reselection

Framework Network: capacited graph –G=[X,J] Edges have capacity C j Routes s S, sets of edges Demands type r, associated source – destination, can use a set of routes R(r)

Coordinated multipath controller Users of type r can use a set of routes R(r) –Send x sr on route s R(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 U r ) per user across all routes. Single RTT dependence –Implies cannot have RTT bias per route

Uncoordinated multipath controller Users of type r can use a set of routes R(r) –Send x sr on route s R(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

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: C a bc 2C a b c so stable provided

Schedulable region depends on utility function a loss of 30% efficiency. C a bc For TCP, stable provided Performance without coordination

Uncoordinated controllers & efficiency Example: Long fat links (delay T), short-thin links ( ) Flows a a, b b,c c If Users choose short-long- short: Lose 50% of coordinated thruput 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 A B C

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 Doesnt 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 weight Price Pr{Mark}

Questions???