modelling and stability of tcp n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Modelling and Stability of TCP PowerPoint Presentation
Download Presentation
Modelling and Stability of TCP

Loading in 2 Seconds...

play fullscreen
1 / 36

Modelling and Stability of TCP - PowerPoint PPT Presentation


  • 79 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Modelling and Stability of TCP' - liora


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
modelling and stability of tcp

Modelling and Stability of TCP

Peter Key

MSR Cambridge

outline
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
outline1
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
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
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 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
outline2
Outline
  • Simple TCP models
  • Utility Maximisation - a framework for fairness
    • General Framework
    • TCP examples
  • Stability, Delay and Stochastic Stability
  • Stochastic arrivals
  • Multipath routing
theorem
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
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
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
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
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
outline3
Outline
  • Simple TCP models
  • Utility Maximisation - a framework for fairness
    • General Framework
    • TCP examples
  • Stability, Delay and Stochastic Stability
  • Stochastic arrivals
  • Multipath routing
generic primal algorithm
Generic Primal algorithm

Gain: tune for convergence / stability

generalise: eg

global stability
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
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
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
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
Variance (Ott ‘99)
  • But feedback signals are noisy
  • Stability depends on the decrease (m and b)
choice of congestion controllers
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
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 ….
outline4
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
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 Driven Multipath
  • Kazaa – manual route selection
  • Skype – fixed , “automatic” best choice
  • BitTorrent – dynamic best 4 with reselection

Peer

Peer

Receiver

Peer

coordinated multipath controller
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
uncoordinated multipath controller
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
coordination does it matter
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
eg performance with coordination

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

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