1. Insensitivity in IP network performance
IPAM Workshop
18-19 March 2002
Insensitivity in IP network performance
Jim Roberts (et al.)

2. Traffic theory: the fundamental three-way relationship
traffic engineering relies on understanding the relationship between demand, capacity and performance
demand
volume
characteristics
capacity
performance
bandwidth
how it is shared
response time
loss, delay

3. Outline characterizing demand statistical bandwidth sharing
performance of elastic traffic
integrating streaming traffic
extensions for an integrated network

4. Characterizing traffic demand
systematic traffic variations
hour of the day, day of the week,...
subject to statistical variations and growth trends
stochastic variations
model traffic as a stationary stochastic process
at the intensity of a representative demand
prefer a characterization at flow level (not packets or aggregates)
"appliflow": a set of packets from one instance of an application
two kinds of flow: streaming and elastic
50 Mb/s
50 Mb/s
0 Mb/s
0 Mb/s
one week
one day

5. Streaming and elastic traffic
elastic traffic is closed-loop controlled
digital documents ( Web pages, files, ...)
rate and duration are measures of performance
QoS  adequate throughput (response time)

6. Streaming and elastic traffic
elastic traffic is closed-loop controlled
digital documents ( Web pages, files, ...)
rate and duration are measures of performance
QoS  adequate throughput (response time)
streaming traffic is open-loop controlled
audio and video, real time and playback
rate and duration are intrinsic characteristics
QoS  negligible loss, delay, jitter

7. A generic traffic model
a session consists of a succession of flows separated by "think times"
flows are streaming or elastic
think times begin at the end of each flow
sessions are mutually independent
think times
start of
session
end of
flow
arrivals

8. A generic traffic model
a session consists of a succession of flows separated by "think times"
flows are streaming or elastic
think times begin at the end of each flow
sessions are mutually independent
assume each flow is transmitted as an entity
eg, multiple TCP connections of one Web page constitute one flow
think times
start of
session
flow
arrivals
end of
session

9. A generic traffic model
a session consists of a succession of flows separated by "think times"
flows are streaming or elastic
think times begin at the end of each flow
sessions are mutually independent
assume each flow is transmitted as an entity
eg, multiple TCP connections of one Web page constitute one flow
sessions occur as a homogeneous Poisson process
an Internet "invariant": [Floyd and Paxson, 2001]
think times
start of
session
flow
arrivals
end of
session

10. Outline characterizing demand statistical bandwidth sharing
performance of elastic traffic
integrating streaming traffic
extensions for an integrated network

11. Statistical bandwidth sharing
reactive control (TCP, scheduling) shares bottleneck bandwidth unequally
depending on RTT, protocol implementation, etc.
there are no persistent flows in the Internet
utility is not a function of instantaneous rate
performance is measured by response time for finite flows
response time depends more on the traffic process than on the static sharing algorithm

12. Performance of an isolated bottleneck
consider an isolated bottleneck of capacity C bits/s
shared by many users independently accessing many servers
performance is measured by
flow response time...
...or realized throughput (= size / response time)
users
servers
C bits/s

13. Performance of an isolated bottleneck
consider an isolated bottleneck of capacity C bits/s
shared by many users independently accessing many servers
performance is measured by
flow response time...
...or realized throughput (= size / response time)
assume (for now) Poisson flow arrivals
arrival rate l
consider a fluid model
assuming packet level dynamics realize bandwidth sharing objectives
users
servers
C bits/s

14. A fluid model of statistical bandwidth sharing
the number of flows in progress is a stochastic process
N(t) = number of flows in progress at time t
ratei(t) = rate of flow i
ratei(t)  max_ratei(t) (due to other throughput limits)
users
servers
external rate limits, max_ratei(t)
C bits/s

15. A fluid model of statistical bandwidth sharing
the number of flows in progress is a stochastic process
N(t) = number of flows in progress at time t
ratei(t) = rate of flow i
ratei(t)  max_ratei(t) (due to other throughput limits)
assume instant max-min fair sharing...
rate of flow i, ratei(t) = min {max_ratei (t), fairshare}
where fairshare is such that S ratei(t)= min {S max_ratei (t), C}
users
servers
C bits/s
external rate limits, max_ratei(t)

16. A fluid model of statistical bandwidth sharing
the number of flows in progress is a stochastic process
N(t) = number of flows in progress at time t
ratei(t) = rate of flow i
ratei(t)  max_ratei(t) (due to other throughput limits)
assume instant max-min fair sharing...
rate of flow i, ratei(t) = min {max_ratei (t), fairshare}
where fairshare is such that S ratei(t)= min {S max_ratei (t), C}
... realized approximately by TCP...
...or more accurately by Fair Queuing
users
servers
C bits/s
external rate limits, max_ratei(t)

17. Three link bandwidth sharing models
1. a fair sharing bottleneck
external limits are ineffective: max_ratei (t)  C, ratei(t) = C/N(t)
e.g., an access link
2. a fair sharing bottleneck with common constant rate limit
flow bandwidth cannot exceed r: max_ratei (t)  r, ratei(t) = min {r,C/N(t)}
e.g., r represents the modem rate
3. a transparent backbone link
max_ratei(t) << C and link is unsaturated: S max_ratei(t) < C, ratei(t) = max_ratei (t)
users
servers 1
external rate limits max_ratei(t)

18. Example: a fair sharing bottleneck (case 1)
an M/G/1 processor sharing queue
Poisson arrival rate l
mean flow size s
load r = ls/C (assume r < 1) ls
offered
traffic C
max_ratei(t) > C
ratei(t) = C/N(t)

19. Example: a fair sharing bottleneck (case 1)
an M/G/1 processor sharing queue
Poisson arrival rate l
mean flow size s
load r = ls/C (assume r < 1)
stationary distribution of number of flows in progress
p(n) = Pr [N(t) = n]
p(n) = rn (1 – r)
offered
traffic ls C
max_ratei(t) > C
ratei(t) = C/N(t)

20. Example: a fair sharing bottleneck (case 1)
an M/G/1 processor sharing queue
Poisson arrival rate l
mean flow size s
load r = ls/C (assume r < 1)
stationary distribution of number of flows in progress
p(n) = Pr [N(t) = n]
p(n) = rn (1 – r)
expected response time of flows of size s
mean throughput = s/R(s) = C(1 – r)
offered
traffic ls C
max_ratei(t) > C
ratei(t) = C/N(t)

21. ns simulation of TCP bandwidth sharing
Poisson flow
arrivals
1 Mbit/s
Pareto size
distribution
load 0.5
throughput
of "mice":
Pr[th'put=C/n]
 p(n)
throughput
of "elephants":
 mean
= C(1 - r)
1000
800
600
Throughput
(Kbit/s)
C(1-r)
400
200
500
1000
1500
2000
Size (Kbytes)

22. Impact of max_rate: mean throughput as a function of load
load, r C 1
E[throughput] ()
fair sharing:  = C(1 – r)
fair sharing with rate limit:
  min {max_rate, C(1 – r)}
max_rate

23. Accounting for non-Poisson flow arrivals
a stochastic network representation (cf. BCMP 1975, Kelly 1979)
sessions are customers arriving from the outside
the link is a processor sharing station
think-time is an infinite server station
...
Poisson
session
arrivals
flows
end of
session
link
think-time

24. Accounting for non-Poisson flow arrivals
...
a network of "symmetric queues" (e.g., PS, infinite server):
customers successively visit the stations a certain number of times before leaving the network
customers change "class" after each visit - class determines service time distribution, next station and class in that station
customers arrive as a Poisson process
Poisson
session
arrivals
end of
link
flows
think-time

25. Accounting for non-Poisson flow arrivals
...
performance of the stochastic network:
a product form occupancy distribution, insensitive to service time distributions
Poisson
session
arrivals
flows
end of
session
link
think-time

26. Accounting for non-Poisson flow arrivals
...
bandwidth sharing performance is as if flow arrivals were Poisson
same distribution of flows in progress, same expected response time
Poisson
session
arrivals
flows
end of
session
link
think-time

27. Accounting for non-Poisson flow arrivals
...
bandwidth sharing performance is as if flow arrivals were Poisson
same distribution of flows in progress, same expected response time
class: a versatile tool to account for correlation in flow arrivals
different kinds of session
distibution of number of flows per session,...
Poisson
session
arrivals
flows
end of
session
link
think-time

28. Accounting for non-Poisson flow arrivals
...
bandwidth sharing performance is as if flow arrivals were Poisson
same distribution of flows in progress, same expected response time
class: a versatile tool to account for correlation in flow arrivals
different kinds of session
distibution of number of flows per session,...
a general performance result for any mix of elastic applications
Poisson
session
arrivals
flows
end of
session
link
think-time

29. Accounting for unfair sharing
slight impact of unequal per flow shares
e.g., green flows get 10 times as much bandwidth as red flows
approximate insensitivity A C
premium class
best effort class
throughput

30. Extension for statistical bandwidth sharing in networks
insensitivity in PS stochastic networks with state dependent service rates
theory of Whittle networks (cf. Serfoso, 1999)...
...applied to statistical bandwidth sharing (Bonald and Massoulié, 2001; Bonald and Proutière, 2002)
session
arrivals
end of
1 station per route
think time

31. Underload and overload: the meaning of congestion
in normal load (i.e., r < 1):
performance is insensitive to all details of session structure
response time is mainly determined by external bottlenecks (i.e, max_rate << C)
but overloads can (and do) occur (i.e., r > 1):
due to bad planning, traffic surges, outages,...
the queuing models are then unstable, i.e., E[response time]  
number of
flows
throughput

32. Underload and overload: the meaning of congestion
in normal load (i.e., r < 1):
performance is insensitive to all details of session structure
response time is mainly determined by external bottlenecks (i.e, max_rate << C)
but overloads can (and do) occur (i.e., r > 1):
due to bad planning, traffic surges, outages,...
the queuing models are then unstable, i.e., E[response time]  
to preserve stability: flow based admission control!
number of
flows
throughput

33. Outline characterizing demand statistical bandwidth sharing
performance of elastic traffic
integrating streaming traffic
extensions for an integrated network

34. Fluid queueing models for streaming traffic
assume flows "on" at rate p, or "off"
by shaping to rate p (e.g., isolated packet of size L = burst of length L/p)
packets
L/p
bursts
arrival rate

35. Fluid queueing models for streaming traffic
assume flows "on" at rate p, or "off"
by shaping to rate p (e.g., isolated packet of size L = burst of length L/p)
bufferless or buffered multiplexing?
Pr [arrival rate > service rate] < e
Pr [buffer overflow] < e
packets
bursts
arrival rate
L/p
bufferless
buffered

36. Sensitivity of buffered multiplexing performance
for a superposition of N independent on/off sources
log Pr [overflow]
buffer size
The basis of traffic engineering is understanding the three-way relation between traffic characteristics, realized performance and network capacity.
In the following slides we consider the qualitative behaviour of a multiplexer offered a superposition of on/off traffic sources. The sources are assumed to offer bursts of cells at the same peak rate. Burst and silence durations are random.
service rate
input rate

37. Sensitivity of buffered multiplexing performance
for a superposition of N independent on/off sources
performance depends on:
mean lengths
log Pr [overflow]
buffer size
burst length
shorter
longer
The basis of traffic engineering is understanding the three-way relation between traffic characteristics, realized performance and network capacity.
In the following slides we consider the qualitative behaviour of a multiplexer offered a superposition of on/off traffic sources. The sources are assumed to offer bursts of cells at the same peak rate. Burst and silence durations are random.
service rate
input rate

38. Sensitivity of buffered multiplexing performance
for a superposition of N independent on/off sources
performance depends on:
mean lengths
distributions
buffer size
burst length
less variable
more variable
The basis of traffic engineering is understanding the three-way relation between traffic characteristics, realized performance and network capacity.
In the following slides we consider the qualitative behaviour of a multiplexer offered a superposition of on/off traffic sources. The sources are assumed to offer bursts of cells at the same peak rate. Burst and silence durations are random.
log Pr [overflow]
service rate
input rate

39. Sensitivity of buffered multiplexing performance
for a superposition of N independent on/off sources
performance depends on:
mean lengths
distributions
correlation
buffer size
burst length
short range
dependence
long range dependence
The basis of traffic engineering is understanding the three-way relation between traffic characteristics, realized performance and network capacity.
In the following slides we consider the qualitative behaviour of a multiplexer offered a superposition of on/off traffic sources. The sources are assumed to offer bursts of cells at the same peak rate. Burst and silence durations are random.
log Pr [overflow]
service rate
input rate

40. Sensitivity of buffered multiplexing performance
for a superposition of N independent on/off sources
performance depends on:
mean lengths
distributions
correlation
sensitivity precludes precise control
prefer bufferless multiplexing
buffer size
long range dependence
burst length
The basis of traffic engineering is understanding the three-way relation between traffic characteristics, realized performance and network capacity.
In the following slides we consider the qualitative behaviour of a multiplexer offered a superposition of on/off traffic sources. The sources are assumed to offer bursts of cells at the same peak rate. Burst and silence durations are random.
short range
dependence
log Pr [overflow]
service rate
input rate

41. Bufferless multiplexing (alias rate envelope multiplexing)
ensure negligible probability of rate overload
Pr[input rate > service rate] < 
by provisioning
accounting for session/flow process and rate fluctuations within each flow
and using admission control to preserve transparency
measurement-based admission control (e.g. Gibbens et al., 1995)
service rate
input rate

42. Insensitive performance of bufferless multiplexing
assuming Poisson session arrivals and peak rate p:
traffic offered = a bit/s, capacity = C bit/s
Poisson
session
arrivals
bursts
end of
session
link
silence/
think-time

43. Insensitive performance of bufferless multiplexing
assuming Poisson session arrivals and peak rate p:
traffic offered = a bit/s, capacity = C bit/s
i.e., loss depends only on load (a/C) and link/peak rate ratio (C/p)
for any mix of streaming applications
Poisson
session
arrivals
bursts
end of
session
link
silence/
think-time

44. Efficiency of bufferless multiplexing
small amplitude of rate variations ...
peak rate << link rate (eg, 1%)
e.g., C/p = 100  Pr [overflow] < 10-6 for a/C < 0.6
... or low utilisation
overall mean rate << link rate

45. Efficiency of bufferless multiplexing
small amplitude of rate variations ...
peak rate << link rate (eg, 1%)
e.g., C/p = 100  Pr [overflow] < 10-6 for a/C < 0.6
... or low utilisation
overall mean rate << link rate
we may have both in an integrated network
priority to streaming traffic
residue shared by elastic flows

46. Integrating streaming and elastic flows
scheduling required to meet QoS requirements
priority to streaming flows
fair sharing of residual capacity by elastic flows (TCP or FQ?)

47. Integrating streaming and elastic flows
scheduling required to meet QoS requirements
priority to streaming flows
fair sharing of residual capacity by elastic flows (TCP or FQ?)
realizing a performance synergy
very low loss for streaming data
efficient use of residual bandwidth by elastic flows

48. Integrating streaming and elastic flows
scheduling required to meet QoS requirements
priority to streaming flows
fair sharing of residual capacity by elastic flows (TCP or FQ?)
realizing a performance synergy
very low loss for streaming data
efficient use of residual bandwidth by elastic flows
complex performance analysis
a PS queue with varying capacity (cf. Delcoigne, Proutière, Régnié, 2002)
exhibits local instability and sensitivity (in heavy traffic with high stream peak rate)...
... but a quasi-stationary analysis is accurate when admission control is used

49. Conclusion: we need to account for the statistical nature of traffic
a Poisson session arrival process
fair sharing for insensitive elastic flow performance
slight impact of unfairness (cf. Bonald and Massoulié, 2001)
fair sharing in a network (cf. Bonald and Proutière, 2002)
bufferless multiplexing for insensitive streaming performance
choosing a common maximum peak rate (C/p > 100 for efficiency)
packet scale performance (jitter accumulation)?
synergistic integration of streaming and elastic traffic
quasi-insensitivity with admission control (cf. Delcoigne et al., 2002, Benameur et al., 2001)

50. Conclusion: we need to account for the statistical nature of traffic
a Poisson session arrival process
fair sharing for insensitive elastic flow performance
slight impact of unfairness (cf. Bonald and Massoulié, 2001)
fair sharing in a network (cf. Bonald and Proutière, 2002)
bufferless multiplexing for insensitive streaming performance
choosing a common maximum peak rate (C/p > 100 for efficiency)
packet scale performance (jitter accumulation)?
synergistic integration of streaming and elastic traffic
quasi-insensitivity with admission control (cf. Delcoigne et al., 2002, Benameur et al., 2001)
required congestion control mechanisms
implicit measurement-based admission control
shaping and priority queuing and reliance on TCP...
... or per-flow fair queuing for all?