The statistical nature of traffic and its impact on the realisability of QoS guarantees

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

([email protected])


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


Outline

What is “Quality of Service” ? Characterising IP traffic Performance for stream applications Performance for elastic applications QoS and pricing


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


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?


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


Outline

What is Quality of Service? Characterising IP traffic Performance for stream applications Performance for elastic applications QoS and pricing


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


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


Traffic on a US backbone link (Thomson et al, 1997)

traffic intensity is predictable ... ... and stationary in the busy hour


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


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


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


Outline



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



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


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)


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


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


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


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


Outline



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 ?


network-networkinterface



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


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


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


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


Admission control can be useful


Admission control can be useful ...

... to prevent disasters at sea !


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


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


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


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


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


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


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)


Outline



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


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


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 !


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

The statistical nature of traffic and its impact on the realisability of QoS guarantees

Documents

Transcript of The statistical nature of traffic and its impact on the realisability of QoS guarantees