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

France Télécom R&D

Tequila WorkshopJan 2001

Jim Roberts, France Telecom R&D

(james.roberts@francetelecom.com)

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

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

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

“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

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

0 20 40 60 80 100

utilization (=a/m) for E(m,a) = 0.01

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

congestionavoidance

0321833132

ppppTpRTT

> small for)(/,min/

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

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

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

E [Response time]/size

0 100 200 N

Blocking probability

backbone link(rate C)

access links(rate<<C)

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

throughputC

accessrate

1 st class

3 rd class

2 nd class

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

1 = 2 = 1.2

0 100N2

1 = 2 = 0.6

0 100N2

B2B100

1 = 2 = 0.4

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

utilization () for B = 0.01

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

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

Chapter 20: Multimedia SystemsCineBlitz provides hard QoS guarantees to realtime clients using an admission control algorithm The disk scheduler orders requests using C-SCAN order

Consumer guarantees guarantees...A guide for businesses and legal practitioners 7 Consumer guarantees: who guarantees what? Suppliers and manufacturers automatically provide guarantees

Seamless QoS Guarantees with SARAH in Mobile Networks

Engineering Internet QoS QoS Fundamentals. Engineering Internet QoS QoS Framework Static Functions oTraffic and QoS specifications (traffic types/parameters)

Improving QOS in IP Networks Thus far: “making the best of best effort” Future: next generation Internet with QoS guarantees m RSVP: signaling for resource.

ECE6609 10. IP QoS Service The current Internet: IP Protocol n Best-Effort Service – no Quality of Service (QoS) guarantees are provided. n Connectionless.

An STDMA-Based Framework for QoS Provisioning in Wireless Mesh Networks · 2009. 1. 2. · Providing strong QoS guarantees for wireless multi-hop networks is very challenging, due

QoS Guarantees

QoS Guarantees for Real Time Applications in 802.11 WLANs

QoS Guarantees introduction call admission traffic specification link-level scheduling call setup protocol required reading: text, 393-395,

Research Article Fairness Time-Slot Allocation and Scheduling with QoS Guarantees …downloads.hindawi.com/journals/mpe/2013/293962.pdf · 2019. 7. 31. · Guarantees in Multihop

Providing QoS in IP Networks Future: next generation Internet with QoS guarantees m Differentiated Services: differential guarantees m Integrated Services:

QoS, QoS Baby

Branch Router QoS Design · Branch Router QoS Design ... application requiring explicit bandwidth guarantees ; they might instead prefer to use the bandwidth to increase the service-levels

Analysis of Traffic Engineering capabilities for SDN-based ......Service (QoS) guarantees (bandwidth, latency, on-demand resource scaling, speed of failure recovery, etc.). As a result,

QoS Guarantees for Real Time Applications in 802.11 WLANs Kiran P Diwakar Guide: Prof. Sridhar Iyer.

France Télécom R&D Tequila Workshop Jan 2001 The statistical nature of traffic and its impact on the realisability of QoS guarantees Jim Roberts, France.

EUBra-BIGSEA: Cloud services with QoS guarantees for Big Data analytics

PERFORMANCE MODEL DRIVEN QOS GUARANTEES AND OPTIMIZATION IN CLOUDS

EUBra-BIGSEA- cloud services with QoS guarantees for Big ... · ona cloud IaaS, automatically managing Quality of Service. ― The BigDataAnalytics services willrun on the cloud infrastructure.