1 / 36

Modelling and Stability of TCP

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.

kalin
Télécharger la présentation

Modelling and Stability of TCP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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 • Multipathrouting • 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 (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

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

  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 xsron 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 xsron route sR(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

  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 (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

  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???

More Related