Modelling and Stability of TCP: Insights for Design and Fairness

1. Modelling and Stability of TCP Peter Key MSR Cambridge

2. 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

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

4. 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)

5. 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:

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

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

8. 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

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

10. 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

11. Fairness Examples, eg ½ ½ 2/3 2/3 ½ 1/3 Max-min Proportional 1 1 0.6 0.6 0 0.4 Max load TCP approx

12. 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

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

14. mark information Router/gateway Wide Area Dynamic Resource Allocation

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

16. 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

17. 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

18. TCP-like rate control algorithm • cwnd T, rate x cwnd / T • For route r : • Increase cwnd by ar cwnd nper 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

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

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

21. 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

22. 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 rin progress • Allocate xr to flow r • Stable if • Per resource stability sufficient (eg with TCP )  • Not true if priorities ….

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

24. 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)?

25. Receiver Driven Multipath • Kazaa – manual route selection • Skype – fixed , “automatic” best choice • BitTorrent – dynamic best 4 with reselection Peer Peer Receiver Peer

26. Coordinated multipath controller • Users of type r can use a set of routes R(r) • Send xsr 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 Ur) per user across all routes. Single RTT dependence • Implies cannot have RTT bias per route

27. Uncoordinated multipath controller • Users of type r can use a set of routes R(r) • Send xsr 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

28. 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

29. a 2C a C c b c b Eg Performance with coordination: • Example network: sharp link capacity constraints • Schedulable region with coordination: so stable provided

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

31. 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

32. A B C 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”

33. 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

34. Scheduling File Tansfers • Most flows are short (mice) • Most volume in a few long flows (elephants) • Currently, bias against mice • If use weights winversely related to (remaining) file size, can improve response dramatically Capacity

35. Weighted shares • We know how to design simple, robust, scalable sharing algorithms …eg generically • Weight is like a “willingness to pay” … but why cooperate Price Pr{Mark} weight

36. Questions???