the statistical nature of traffic and its impact on the realisability of qos guarantees
DESCRIPTION
Tequila Workshop Jan 2001. The statistical nature of traffic and its impact on the realisability of QoS guarantees. Jim Roberts, France Telecom R&D ([email protected]). Quality of service: a commodity?. Example SLS: Scope: N/N - PowerPoint PPT PresentationTRANSCRIPT
France Télécom R&D
Tequila WorkshopJan 2001
The statistical nature of traffic and its impact on the realisability of QoS guarantees
Jim Roberts, France Telecom R&D
France Télécom R&D
Quality of service: a commodity?
Example SLS:Scope: N/NFlow identification: EF-valued DSCP, set of destination prefixesTraffic conformance: token bucket (r,b)Excess treatment: dropService schedule: Oct 3, 9:00 - 11:00Performance parameters: 0% loss
The role of traffic engineering:What is the relation between (r,b) and user traffic characteristics ?How can the network guarantee 0% loss ?How much does this service cost ?
Maybe these questions don’t have a satisfactory answer...depending on the statistical nature of traffic and the realisability of QoS
guarantees
France Télécom R&D
Outline
What is “Quality of Service” ? Characterising IP traffic Performance for stream applications Performance for elastic applications QoS and pricing
France Télécom R&D
QoS and reservation
users express their demand in terms of aggregatesdifferent classes (EF, AF1-4, ...)different scopes : point to point,..., point to world, (world to point?)e.g., 2 Mb/s “class 1” from A to B, 5 Mb/s “class 3” from A to C or D,...
network filters traffic at ingresspackets are “in” or “out” ... or “nearly in”e.g., token bucket, sliding window,...
network “reserves” bandwidthadmission control / traffic engineeringusing policy servers, signalling,...
resource provisioning relies on “adequate provisioning”e.g., service differentiation through different overbooking factors
France Télécom R&D
Doubts about aggregates
traffic characterizationcan a user choose its filter parameters?how can the network reserve enough resources?what about the small user?
end-to-end performancewhat absolute quality of service?what relative quality of service?
pricingpricing for value......or pricing for cost?
France Télécom R&D
QoS and end-to-end performance
transparency for streaming applicationsaudio and video: interactive or playbackQoS low packet loss and delayscope for differentiation: real time/non-real time, hi-fi / lo-fi,...
response time for elastic applicationsWeb, e-mail, file transfer, MP3,...QoS high throughputscope for differentiation: interactive/background, large flows/small flows,...
QoS is a statistical phenomenonprobabilities, averages,......depending on available capacity...and traffic demand
QoS is often binary“good enough”......or “too bad” !
France Télécom R&D
Outline
What is Quality of Service? Characterising IP traffic Performance for stream applications Performance for elastic applications QoS and pricing
France Télécom R&D
Internet traffic is self-similar
a self-similar processvariability at all time scales
due to:infinite variance of flow sizeTCP induced burstiness
Ethernet traffic, Bellcore 1989
France Télécom R&D
Internet traffic is self-similar
a self-similar processvariability at all time scales
due to:infinite variance of flow sizeTCP induced burstiness
a practical consequencedifficult to characterise a traffic
aggregate
Ethernet traffic, Bellcore 1989
10 s
France Télécom R&D
Traffic on a US backbone link (Thomson et al, 1997)
traffic intensity is predictable ... ... and stationary in the busy hour
France Télécom R&D
Traffic on a French backbone link
traffic intensity is predictable ... ... and stationary in the busy hour
12h 18h 00h 06h
tue wed thu fri sat sun mon
France Télécom R&D
IP flows
a flow = one instance of a given applicationa "continuous flow" of packets basically two kinds of flow, stream and elastic
stream flowsaudio and video, real time and playbackrate and duration are intrinsic characteristicshighly variable rate and duration Poisson arrival process (?)
elastic flowsdigital documents ( Web pages, files, ...)rate and duration are measures of performancehighly variable sizePoisson arrivals (?)
95% of packets are in elastic flows
France Télécom R&D
Modelling traffic demand
stream traffic demandarrival rate x bit rate x duration
elastic traffic demand arrival rate x size
a stationary process in the "busy hour"e.g., Poisson flow arrivals, independent flow size
busy hour
trafficdemand
Mbit/s
time of day
France Télécom R&D
Outline
What is Quality of Service? Characterising IP traffic Performance for stream applications Performance for elastic applications QoS and pricing
France Télécom R&D
Open loop control for stream traffic
buffered of bufferless multiplexing ? jitter control ? admission control or adaptive applications ? reservation or implicit admission control ? scope for service differentiation ?
user-networkinterface
network-networkinterface
user-networkinterface
France Télécom R&D
Buffered multiplexing performance
less variable
more variable
log Pr[saturation]
buffer size0
0
a buffer to absorb rate overloadadmission control to ensure
Pr[buffer overflow]< but performance depends on complex
traffic characteristicse.g., self-similarity
QoS of buffered multiplexing is uncontrollable
NB. token bucket is a virtual queuedifficult choice of r and b parameters? no satisfactory descriptor for variable
rate flows or aggregates
France Télécom R&D
outputrate C
combinedinput
rate t
time
“Bufferless” multiplexing: alias rate envelope multiplexing
admission control to ensure Pr [t>C] < performance depends only on stationary rate distribution
loss rate E [(t -C)+] / E [t]
performance is insensitive to self-similarity (and other correlation) “negligible jitter” for flows shaped at the ingress (cf. INFOCOM 2001)
France Télécom R&D
Efficiency of bufferless multiplexing
low loss imposes small amplitude of rate variations ...peak rate << link rate (eg, 1%)
... or low utilisationoverall mean rate << link rate
we may have both in an integrated networkpriority to streaming trafficresidue shared by elastic flows
France Télécom R&D
Implicit admission control
accept new flow only if transparency preservedgiven flow peak rateand estimated available bandwidth
reject new flow if necessaryby discarding first packets (probes)
uncritical decision threshold if streaming traffic is lightin an integrated network
France Télécom R&D
Differentiation for stream traffic
different delays? priority queues, WFQ, ... but what guarantees?
different loss? different utilisation (WFQ, ...) "spatial queue priority"
partial buffer sharing, push out or negligible loss and delay for all
elastic-stream integration ... ... and low stream utilisation
lossdelay
delay
delay
loss loss
France Télécom R&D
Provisioning for negligible blocking
"classical" teletraffic theory; assume Poisson arrivals, rate constant rate per flow rmean duration 1/ mean demand, A = r bits/s
blocking probability for capacity C B = E(C/r,A/r)E(m,a) is Erlang's formula:
E(m,a)= scale economies
generalizations exist: for different ratesfor variable rates
mi ia
ma im
!! /
0 20 40 60 80 100
0.2
0.4
0.6
0.8
utilization (=a/m) for E(m,a) = 0.01
m
France Télécom R&D
Outline
What is Quality of Service? Characterising IP traffic Performance for stream applications Performance for elastic applications QoS and pricing
France Télécom R&D
Closed loop control for elastic traffic
impact of packet scale on flow scale response time? performance of statistical bandwidth sharing ? need for admission control ? scope for service differentiation ?
user-networkinterface
network-networkinterface
user-networkinterface
France Télécom R&D
a multi-fractal arrival processbut loss and bandwidth related by TCP (cf. Padhye et al.)
thus, p = p(B): i.e., loss rate depends on bandwidth share
B(p) loss rate
p
congestionavoidance
1
641
0321833132
1
0
0
20
pT
ppppTpRTT
pRTTW
pB
for
> small for)(/,min/
= for
)(
max
Bandwidth and packet loss rate
France Télécom R&D
Bandwidth sharing
reactive control (TCP, scheduling) shares bottleneck bandwidth unequally
depending on RTT, protocol implementation, etc.and differentiated services parameters
optimal sharing in a network: objectives and algorithms...max-min fairness, proportional fairness, maximal utility,...
... but response time depends more on traffic process than the static sharing algorithm!
route 0
route 1 route L
Example: a linear network
France Télécom R&D
Flow level performance of a bottleneck link
assume perfect fair shareslink rate C, n elastic flows each flow served at rate C/n
assume Poisson flow arrivals an M/G/1 processor sharing queueload, = arrival rate x size / C
performance insensitive to size distributionPr [n transfers] = n(1-)E [response time] = size / C(1-)
instability if > 1i.e., unbounded response timestabilized by aborted transfers...... or by admission control
100
throughputC
a processor sharing queue
fair shares
link capacity C
France Télécom R&D
Generalizations of PS model
non-Poisson arrivalsPoisson sessionsgeneral session structure
discriminatory processor sharingweight i for class i flowsservice rate i
rate limitations (same for all flows)maximum rate per flow (eg, access rate)minimum rate per flow (by admission control)
Poissonsessionarrivals
flows
think time
transfer
processor sharing
infiniteserver
France Télécom R&D
Admission control can be useful
France Télécom R&D
Admission control can be useful
France Télécom R&D
Admission control can be useful ...
... to prevent disasters at sea !
France Télécom R&D
Admission control can also be useful for IP flows
improve efficiency of TCPreduce retransmissions overhead ...... by maintaining throughput
implicit admission controldiscard packets of new flowswhen available capacity is low
prevent instabilitydue to overload ( > 1)......and retransmissions
avoid aborted transfersuser impatience"broken connections"
a means for service differentiation...
France Télécom R&D
Choosing an admission control threshold
N = the maximum number of flows admitted negligible blocking when <maintain quality when >
M/G/1/N processor sharing system bandwidth C/N; bandwidth C/N for> Pr [blocking] = N(1 - )/(1 - N+1) (1 - 1/for>
uncritical choice of threshold eg, 1% of link capacity (N=100)
0 100 200 N
300
200
100
0
E [Response time]/size
= 0.9
= 1.5
0 100 200 N
1
.8
.6
.4
.2
0
Blocking probability
= 0.9
= 1.5
France Télécom R&D
backbone link(rate C)
access links(rate<<C)
100
throughput C
accessrate
Impact of access rate on backbone sharing
TCP throughput is limited by access rate...modem, DSL, cable
... and by server performance, TCP receive window, other links,...
backbone link transparent unless saturated!ie, unless > 1 (or > 0.9...)
France Télécom R&D
Differentiation for elastic traffic
different utilizationseparate pipesclass based queuing
different per flow sharesWFQimpact of RTT,...
discrimination in overloadimpact of aborts (?)or by admission control
100
throughputC
accessrate
1 st class
3 rd class
2 nd class
100
throughputC
accessrate
France Télécom R&D
Integrating streaming and elastic traffic
priority to packets of streaming flowslow utilization negligible loss and delayusing EF ?
elastic flows use all remaining capacitybetter response timesper flow fair queuing (?)
to prevent overload implicit admission control......and adaptive routing
an identical admission criterion for streaming and elastic flowsavailable rate > R
France Télécom R&D
Differentiation by accessibility
block class 1 when 100 flows in progress - block class 2 when N2 flows in progress
in underload: both classes have negligible blocking (B1 B2 0) in overload: discrimination is effective
if 1 < 1 < 1 + 2, B1 0, B2 (1+2-1)/2
if 1 < 1, B1 (1-1)/1, B2 1
B1
B21
.17
1 = 2 = 1.2
0 100N2
B2
B1
.33
0
1 = 2 = 0.6
0 100N2
1
B2B100
1 = 2 = 0.4
0 N2
1
France Télécom R&D
Provisioning for negligible blocking for elastic flows
"elastic" teletraffic theory; assume Poisson arrivals, rate mean size s
blocking probability for capacity Cutilization = s/Cm = admission control limit B(,m) = m(1-)/(1-m+1)
impact of access rateC/access rate = mB(,m) E(m,m)
0 20 40 60 80 100
0.2
0.4
0.6
0.8
utilization () for B = 0.01
m
E(m,m)
France Télécom R&D
Outline
What is Quality of Service? Characterising IP traffic Performance for stream applications Performance for elastic applications QoS and pricing
France Télécom R&D
Service differentiation and pricing
different QoS requires different prices...or users will always choose the best
...but streaming and elastic applications are qualitatively different choose streaming class for transparencychoose elastic class for throughput
no need for streaming/elastic price differentiation
different prices exploit different "willingness to pay"... bringing greater economic efficiency
...but QoS is not stable or predictable depends on route, time of day,.. and on factors outside network control: access, server, other networks,...
network QoS is not a sound basis for price discrimination
France Télécom R&D
Pricing to pay for the network
fix a price per byteto cover the cost of infrastructure and operation
estimate demandat that price
provision network to handle that demandwith excellent quality of service
demand
time of day
$$$
capacity
$$$
demand
time of day
capacity
optimal price revenue = cost
France Télécom R&D
Price differentiation
maximise value by exploiting different “willingness to pay”business, professional, residential
price componentsflat rate subscriptionper byte charge ( 0)time of day variations
price differences based on stable criteriae.g., access rate, available services
pay for differentiated accessibility... e.g., flat rate payment for guaranteed reliability
...but not for congestioni.e., pay more for worse quality !
France Télécom R&D
Conclusions a statistical characterisation of demand
a stationary random process in the busy perioda flow level characterisation (streaming and elastic flows)
transparency for streaming flowsrate envelope ("bufferless") multiplexingthe "negligible jitter conjecture"
response time for elastic flowsa "processor sharing" flow scale model instability in overload (i.e., E[demand]>capacity)
service differentiationdistinguish streaming and elastic classes limited scope for within-class differentiationflow admission control in case of overload
pricingper byte + flat rate charges
100
C