Modelling and Stability of TCP

1 / 36

# Modelling and Stability of TCP - PowerPoint PPT Presentation

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.

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

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

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

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

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
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)?
• Kazaa – manual route selection
• Skype – fixed , “automatic” best choice
• BitTorrent – dynamic best 4 with reselection

Peer

Peer

Peer

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

• 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:
• Flows aa’, bb’,cc’
• 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”
• 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