Create Presentation
Download Presentation

Download Presentation
## Modelling and Stability of TCP

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -

**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 • Multipathrouting • 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:**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**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)**Utility U(x) Utility U(x) Rate x Real Time Elastic / Data Share out bandwidth Limited capacity Limited capacity Rejection Or randomise**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**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**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**mark information**Router/gateway Wide Area Dynamic Resource Allocation**Generic Primal algorithm**Gain: tune for convergence / stability 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 (egNyquist) 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 cwndby arcwndnper positive ACK • Decrease cwndby brcwndm 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 route increase (“aggressiveness)” Per resource (price) sensitivity**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 rin progress • Allocate xr 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**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**• Kazaa – manual route selection • Skype – fixed , “automatic” best choice • BitTorrent – dynamic best 4 with reselection Peer Peer Receiver Peer**Coordinated multipath controller**• Users of type r can use a set of routes R(r) • Send xsron 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**Uncoordinated multipath controller**• Users of type r can use a set of routes R(r) • Send xsron route sR(r) • Controller (rate control/utility) per route schosen 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 (cfKazaa, 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 (egBitTorrent), 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**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**Performance without coordination**a C c b Schedulable region depends on utility function a loss of 30% efficiency. For TCP, stable provided**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 T**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”**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**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**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