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 Telecom R&D

France Télécom R&D Quality of service: a commodity? è Example SLS: ‡ Scope: N/N ‡ Flow identification: EF-valued DSCP, set of destination prefixes ‡ Traffic conformance: token bucket (r,b) ‡ Excess treatment: drop ‡ Service schedule: Oct 3, 9: :00 ‡ Performance 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 aggregates ‡ different 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 ingress ‡ packets are “in” or “out”... or “nearly in” ‡ e.g., token bucket, sliding window,... è network “reserves” bandwidth ‡ admission control / traffic engineering ‡ using 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 characterization ‡ can a user choose its filter parameters? ‡ how can the network reserve enough resources? ‡ what about the small user? è end-to-end performance ‡ what absolute quality of service? ‡ what relative quality of service? è pricing ‡ pricing for value... ‡...or pricing for cost?

France Télécom R&D QoS and end-to-end performance è transparency for streaming applications ‡ audio and video: interactive or playback  QoS  low packet loss and delay ‡ scope for differentiation: real time/non-real time, hi-fi / lo-fi,... è response time for elastic applications ‡ Web, , file transfer, MP3,...  QoS  high throughput ‡ scope for differentiation: interactive/background, large flows/small flows,... è QoS is a statistical phenomenon ‡ probabilities, 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 process ‡ variability at all time scales è due to: ‡ infinite variance of flow size ‡ TCP induced burstiness Ethernet traffic, Bellcore 1989

France Télécom R&D Internet traffic is self-similar è a self-similar process ‡ variability at all time scales è due to: ‡ infinite variance of flow size ‡ TCP induced burstiness è a practical consequence ‡ difficult to characterise a traffic aggregate Ethernet traffic, Bellcore 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 application ‡ a "continuous flow" of packets ‡ basically two kinds of flow, stream and elastic è stream flows ‡ audio and video, real time and playback ‡ rate and duration are intrinsic characteristics ‡ highly variable rate and duration ‡ Poisson arrival process (?) è elastic flows ‡ digital documents ( Web pages, files,...) ‡ rate and duration are measures of performance ‡ highly variable size ‡ Poisson arrivals (?) è 95% of packets are in elastic flows

France Télécom R&D Modelling traffic demand è stream traffic demand ‡ arrival 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 traffic demand 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-network interface network-network interface user-network interface

France Télécom R&D Buffered multiplexing performance less variable more variable log Pr[saturation] buffer size 0 0 è a buffer to absorb rate overload  admission control to ensure Pr[buffer overflow]<  è but performance depends on complex traffic characteristics ‡ e.g., self-similarity   QoS of buffered multiplexing is uncontrollable è NB. token bucket is a virtual queue ‡ difficult choice of r and b parameters?   no satisfactory descriptor for variable rate flows or aggregates

France Télécom R&D output rate C combined input 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 utilisation ‡ overall mean rate << link rate è we may have both in an integrated network ‡ priority to streaming traffic ‡ residue shared by elastic flows

France Télécom R&D Implicit admission control è accept new flow only if transparency preserved ‡ given flow peak rate ‡ and estimated available bandwidth è reject new flow if necessary ‡ by discarding first packets (probes) è uncritical decision threshold if streaming traffic is light ‡ in 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 loss delay loss

France Télécom R&D Provisioning for negligible blocking è "classical" teletraffic theory; assume  Poisson arrivals, rate ‡ constant rate per flow r  mean 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 rates ‡ for variable rates  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-network interface network-network interface user-network interface

France Télécom R&D è a multi-fractal arrival process ‡ but 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 congestion avoidance 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 1route L Example: a linear network

France Télécom R&D Flow level performance of a bottleneck link è assume perfect fair shares ‡ link rate C, n elastic flows  ‡ each flow served at rate C/n è assume Poisson flow arrivals ‡ an M/G/1 processor sharing queue  load,  = arrival rate x size / C è performance insensitive to size distribution  Pr [n transfers] =  n (1-  )  E [response time] = size / C(1-  )  instability if  > 1 ‡ i.e., unbounded response time ‡ stabilized by aborted transfers... ‡... or by admission control throughput C   a processor sharing queue fair shares link capacity C

France Télécom R&D Generalizations of PS model è non-Poisson arrivals ‡ Poisson sessions ‡ general session structure è discriminatory processor sharing  weight  i for class i flows  service rate   i è rate limitations (same for all flows) ‡ maximum rate per flow (eg, access rate) ‡ minimum rate per flow (by admission control) Poisson session arrivals flows think time transfer processor sharing infinite server

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 TCP ‡ reduce retransmissions overhead... ‡... by maintaining throughput è implicit admission control ‡ discard packets of new flows ‡ when available capacity is low è prevent instability  due to overload (  > 1)... ‡...and retransmissions è avoid aborted transfers ‡ user 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   è 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) N E [Response time]/size  = 0.9  = N Blocking probability  = 0.9  = 1.5

France Télécom R&D backbone link (rate C) access links (rate<<C) throughput C  access rate 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  > )

France Télécom R&D Differentiation for elastic traffic è different utilization ‡ separate pipes ‡ class based queuing è different per flow shares ‡ WFQ ‡ impact of RTT,... è discrimination in overload ‡ impact of aborts (?) ‡ or by admission control throughput C access rate  1 st class 3 rd class 2 nd class throughput C access rate 

France Télécom R&D Integrating streaming and elastic traffic è priority to packets of streaming flows ‡ low utilization  negligible loss and delay ‡ using EF ? è elastic flows use all remaining capacity ‡ better response times ‡ per flow fair queuing (?) è to prevent overload ‡ implicit admission control... ‡...and adaptive routing è an identical admission criterion for streaming and elastic flows ‡ available rate > R

France Télécom R&D Differentiation by accessibility è block class 1 when 100 flows in progress - block class 2 when N 2 flows in progress  in underload: both classes have negligible blocking (B 1  B 2  0) è in overload: discrimination is effective  if  1 < 1 <  1 +  2, B 1  0, B 2  (  1 +  2 -1)/  2  if 1 <  1, B 1  (  1 -1)/  1, B 2  1 B1B1 B2B  1 =  2 = N2N2 B2B2 B1B  1 =  2 = N2N2 1 B2B10B2B10 0  1 =  2 = N2N2 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 C  utilization  = s/C ‡ m = admission control limit  B( ,m) =  m (1-  )/(1-  m+1 ) è impact of access rate ‡ C/access rate = m  B( ,m)  E(m,  m)  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 transparency ‡ choose 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 byte ‡ to cover the cost of infrastructure and operation è estimate demand ‡ at that price è provision network to handle that demand ‡ with 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 components ‡ flat rate subscription ‡ per byte charge (  0) ‡ time of day variations è price differences based on stable criteria ‡ e.g., access rate, available services è pay for differentiated accessibility... ‡ e.g., flat rate payment for guaranteed reliability è...but not for congestion ‡ i.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 period ‡ a flow level characterisation (streaming and elastic flows) è transparency for streaming flows ‡ rate envelope ("bufferless") multiplexing ‡ the "negligible jitter conjecture" è response time for elastic flows ‡ a "processor sharing" flow scale model ‡ instability in overload (i.e., E[demand]>capacity) è service differentiation ‡ distinguish streaming and elastic classes ‡ limited scope for within-class differentiation ‡ flow admission control in case of overload è pricing ‡ per byte + flat rate charges C 