Lectured by Alexander Pyattaev - Tiedekunnat · 2012-03-05 · Outline 1 Introduction 2 Performance...
Transcript of Lectured by Alexander Pyattaev - Tiedekunnat · 2012-03-05 · Outline 1 Introduction 2 Performance...
QoS metrics and requirements
Lectured by Alexander Pyattaev
Department of Communications EngineeringTampere University of [email protected]
March 5, 2012
Outline
1 Introduction
2 Performance metrics definition
3 Performance metrics used in QoSMetrics for traffic flowsMetrics for service performanceService availability
4 Requirements for different servicesBest Effort serviceCBR (voice) serviceReal-Time (interactive) serviceNear real-time (video-on-demand) serviceOther services
5 Conclusions
Lectured by Alexander Pyattaev (TUT) TLT-2727 March 5, 2012 2 / 29
Outline
1 Introduction
2 Performance metrics definition
3 Performance metrics used in QoSMetrics for traffic flowsMetrics for service performanceService availability
4 Requirements for different servicesBest Effort serviceCBR (voice) serviceReal-Time (interactive) serviceNear real-time (video-on-demand) serviceOther services
5 Conclusions
Lectured by Alexander Pyattaev (TUT) TLT-2727 March 5, 2012 3 / 29
Definition of QoS
Yet another definition for QoS:
Quality - assurance, that the service happens exactly as promised
All performance metrics are within limitsService is available when customer needs it
Service - the thing we do for which we are getting paid
In our case serving requestsIn most cases those are network packets or connections
Standards - ITU-T E.800 (outdated badly, suitable for telephony only)You are free to find your own as long as it makes sense.
Lectured by Alexander Pyattaev (TUT) TLT-2727 March 5, 2012 4 / 29
Performance metrics?
What are those? Let us consider telephony (following ITU ideas)
Signal to noise ratio? - Yes
Presence of echo? - Yes
Signal strength? - Yes
BUTThose are not interesting for us now!
In modern networks we transfer digital data
Only several metrics related to losses and timings are of interest
Let us address those in more details.
Lectured by Alexander Pyattaev (TUT) TLT-2727 March 5, 2012 5 / 29
Outline
1 Introduction
2 Performance metrics definition
3 Performance metrics used in QoSMetrics for traffic flowsMetrics for service performanceService availability
4 Requirements for different servicesBest Effort serviceCBR (voice) serviceReal-Time (interactive) serviceNear real-time (video-on-demand) serviceOther services
5 Conclusions
Lectured by Alexander Pyattaev (TUT) TLT-2727 March 5, 2012 6 / 29
Primary metrics
For any queuing system, we can easily define some primary performancemetrics of interest:
Total time spent by request in the system (sojourn time)
Probability of loss
Maximum service rate
As you can see, we are not interested in the details of system operation,only in the main metrics.
Arrivals Service
?Queuing system
100 pktsover 10 sec
78 pkts,delay of 3 sec/pkt
Lectured by Alexander Pyattaev (TUT) TLT-2727 March 5, 2012 7 / 29
Do we need more metrics?
Is it enough if we would like to provide service to the customers?The answer is it depends on the service.
Best-effort service - provide some serviceNo care for the user’s data getting lostPromise some non-zero average service rateThis is what most smaller ISP’s provideThis is what Internet was originally built on
Service with defined quality - provide exact specificationsWhat kind of service discipline is usedWhat is the service rateCapability to handle burstsList goes on...This is what most cellular and telephone networks provideThis is what serious businesses are built on
Arrivals ServiceQueuing system
N pkts bufferService rate,distribution
Lectured by Alexander Pyattaev (TUT) TLT-2727 March 5, 2012 8 / 29
How many metrics do we really need?
To promise something, one need to define clearly the following:
What he/she will do/make, what it would do
The working conditions, in which the promise holds
What happens when those conditions are not met
How long this promise holds
Same logic applies to QoS support:
We promise that our queuing system will work according to somemathematical model
We clearly state that our promise holds only when the arrival flow fitsinto some other mathematical model
We clearly state what happens if the arrival flow restrictions are notmet
e.g. extra packets are dropped/delayed/billed 10 times extra...
We define the reliability of our service
Therefore, we need statistical metrics to define all of the above pointsLectured by Alexander Pyattaev (TUT) TLT-2727 March 5, 2012 9 / 29
Outline
1 Introduction
2 Performance metrics definition
3 Performance metrics used in QoSMetrics for traffic flowsMetrics for service performanceService availability
4 Requirements for different servicesBest Effort serviceCBR (voice) serviceReal-Time (interactive) serviceNear real-time (video-on-demand) serviceOther services
5 Conclusions
Lectured by Alexander Pyattaev (TUT) TLT-2727 March 5, 2012 10 / 29
Traffic flow metrics - scientist’s solution
To promise handling of a given traffic flow, one defines its statisticalpropertiesUnfortunately,
Customers and lawyers do not wish to understand what does”variance” mean
It is difficult to prove that given observation fits/does not fit certaindistribution
One has to monitor the metrics continuously, which is challenging fornon-stationary flows (try measuring variance of a non-stationary flow)
We are trying to define a set of limiting conditions, not give anexample of conditions where our system works
So, the common metrics like distribution and its parameters (mean,variance...) do not fit our requirements and can not usually be used forQoS dimensioning
Lectured by Alexander Pyattaev (TUT) TLT-2727 March 5, 2012 11 / 29
Traffic flow metrics - engineer’s solution
So we can not usually define or measure statistical properties; weimprovise:
We can always define maximum/minimum sustained rate (Mean)
Limit the burst size in duration and “amplitude“ (Variance anddistribution)
Limit the amount of traffic over long period (Non-stationarity)
Let us consider an example in more detail:
0 24 time,h
Flow, Gb/s
5
12
8
b
Lectured by Alexander Pyattaev (TUT) TLT-2727 March 5, 2012 12 / 29
Sustained rate
The mean of the arrival rate over a small time window of duration t.
Can be easily computed via sliding window algorithm
Ignores minor fluctuations if t is large enough
Handles non-stationarity well (finite-memory system)
0 24 time,h
Flow, Gb/s
5
12
8
b
Black line r - actual measurements (noisy and unreliable)Red line R- filtered measurements (show when something really happens)Thresholds Rmax and Rmin are set for overload and underloaded conditions
Lectured by Alexander Pyattaev (TUT) TLT-2727 March 5, 2012 13 / 29
Burst detection
The system is dimensioned in such a way that it can be stable at themaximum sustained rate R < Rmax . When R > Rmax , we detect a burst
Peaks ”unexpectedly” fill queues over their normal loading n
The queue capacity N should be large enough to handle the extraburst
The actual peak size is its integral above the Rmax (shown in blue)
Normally, the peak immediate rate rmax is hard-limited by channelbandwidth.
All samples above Rmax are bursts, but we are only interested in thosethat cause R to go above Rmax (interval b)
0 24 time,h
Flow, Gb/s
5
12
8
b
b
rmax
Rmax
Lectured by Alexander Pyattaev (TUT) TLT-2727 March 5, 2012 14 / 29
Load limitation
Sometimes we want to limit the total amount of carried traffic:
Throttle users hogging resources
Detect connections that have got more resources then others
Fit into some agreement specifying total amount of carried traffic
The approach is similar to sustained rate, but with much larger t. Luckily,on large scale the bursts are unlikely, so normally those are not consideredon this scale.
Lectured by Alexander Pyattaev (TUT) TLT-2727 March 5, 2012 15 / 29
Special case - jitter
In some cases we may wish to define the allowed limits for service delaysWe could use the metrics above, or we can do worse. RFC-3393 definesJitter, or packet delay variation (PDV) as the first derivative of thepacket delay. It is not variance, but is strongly correlated with it!.
Normally, average jitter is measured (with a sliding window) to get asingleton value instead of a vector
No jitter is a good jitter. Multimedia applications can usually adaptto nearly any delay, but do not tolerate jitter very well
It is extremely hard to compute jitter analytically, and in ATMnetworks delay standard deviation is used instead
Lectured by Alexander Pyattaev (TUT) TLT-2727 March 5, 2012 16 / 29
Serving side view
Again, we do not specify the exact service discipline (in packet networkswe usually do not know it anyway). Instead, we specify performancemetrics in cases when arrival flows are according to our specifications
Probability of packet loss
Mean packet delay d , 95% packet delay d95
95% of packets have delay d < d95
The remaining 5% can have arbitrary delays
What happens with packets that violate the arrival flow requirements
No delay guarantees are given in this caseThose packets can usually be dropped
Therefore, the critical part is to specify the arrival flow, and then systemperformance specification is somewhat simpler task
Lectured by Alexander Pyattaev (TUT) TLT-2727 March 5, 2012 17 / 29
Client side view
What if we are representing the client and are requesting the service?
We have to specify the flows we will be sending
Also the flows we will be receiving (if necessary)
We have to specify the service quality we would like to get
For example, loss rate below 0.0001 and 95% delay of 30 ms.
Lectured by Alexander Pyattaev (TUT) TLT-2727 March 5, 2012 18 / 29
Availability in networking
Availability = probability that the service is available with claimed qualityat an given moment of time = 1 − downtime
uptime+downtime
If the service is working, but slower then allowed - it is not available
Dropped connections in connection-oriented systems are typicallycounted separately
Most telecoms operators have to guarantee availability of 0.99999 (5min downtime/year) to get a license
At the same time up to 0.5% of calls can be dropped during anygiven hour
Lectured by Alexander Pyattaev (TUT) TLT-2727 March 5, 2012 19 / 29
Outline
1 Introduction
2 Performance metrics definition
3 Performance metrics used in QoSMetrics for traffic flowsMetrics for service performanceService availability
4 Requirements for different servicesBest Effort serviceCBR (voice) serviceReal-Time (interactive) serviceNear real-time (video-on-demand) serviceOther services
5 Conclusions
Lectured by Alexander Pyattaev (TUT) TLT-2727 March 5, 2012 20 / 29
Level of service
The level of service(class of service) summarizes the performance metricsthat some abstract service would require
One-way delays and round-trip times
Throughput, sustained and burst
Other relevant parameters
Those are also deeply connected with the use-case, so they deserve abetter look at
Lectured by Alexander Pyattaev (TUT) TLT-2727 March 5, 2012 21 / 29
Best Effort service
Best Effort(BE) service means that all free network resources will beused to perform service.
If the network is fully reserved for other service classes, nothing willbe done
No guarantees are given on delays
The packet loss is limited, i.e. it works reliably, but slowly
BE service is suitable primarily for data transfers, especially non-interactiveones. It is assumed that the transfer protocol employs some way ofadapting the transfer rate to the available network speed, like TCP does.
Lectured by Alexander Pyattaev (TUT) TLT-2727 March 5, 2012 22 / 29
Best Effort requirements
Although it seems that BE service does not require any QoS, it is not true:
Packets should not be lost (at least not too often), otherwise usermay assume that service is not available
Delays should be reasonable (below 2 sec for TCP), same reasons
Average long-term speed should be assured, or the users will questionvalue-for-money ratio you promise
The Internet is suited mostly to handle BE traffic, but true BE serviceexists only in logistics. For example, some parcels may have BE priority,i.e. those are delivered only with other items going same direction.
Lectured by Alexander Pyattaev (TUT) TLT-2727 March 5, 2012 23 / 29
CBR service
Constant bit rate(CBR) service means that a fixed deterministic flow canbe served, with guarantees on delay, delay variance and jitter
Usually this implies voice or teleconference connections
The most expensive kind of service (the most strict requirements)
In most cases requires switched circuit (MPLS, ATM, Frame Relay...)
One can never guarantee CBR service over Internet, however a ”goodenough” approximation can be reached (Skype)
Lectured by Alexander Pyattaev (TUT) TLT-2727 March 5, 2012 24 / 29
Real-Time interactive services
Real-time(RT) service requires minimal possible delay, but can survivejitter and packet loss. In fact, for RT services packet loss is preferred overextra delays. Limited bursts in arrivals are expected.
RT services include games, remote desktops, telemetry
Bandwidth is usually not a big issue
In most cases requires switched circuit (MPLS, ATM, Frame Relay...)
One can never guarantee quality for RT service over Internet, however a”good enough” approximation can be reached (any proper multiplayergame)
Lectured by Alexander Pyattaev (TUT) TLT-2727 March 5, 2012 25 / 29
Near Real-Time services
Near Real-Time(nRT) service typically requires fast response, but doesnot require a very stable connection. Such profile is typical for webapplications, that generate large bursts of traffic with long waiting periods.Video-on-demand and web radio systems also fit the profile, as the clientcache can compensate rather large jitter or even losses, but cachingprocess itself is annoying to users
Video on demand, web radio, any sort of streaming
High bandwidth, fast responses, no stability requirements
Can be implemented in Internet
Such services are expected to occupy a significant portion of the Internetlinks (after file transfers, of course), and therefore should always be takeninto account
Lectured by Alexander Pyattaev (TUT) TLT-2727 March 5, 2012 26 / 29
Other services
One may define other classes of service as needed. There is no universalstandard, but the above ones are commonly used when talking aboutQoS-related topics.
Lectured by Alexander Pyattaev (TUT) TLT-2727 March 5, 2012 27 / 29
Outline
1 Introduction
2 Performance metrics definition
3 Performance metrics used in QoSMetrics for traffic flowsMetrics for service performanceService availability
4 Requirements for different servicesBest Effort serviceCBR (voice) serviceReal-Time (interactive) serviceNear real-time (video-on-demand) serviceOther services
5 Conclusions
Lectured by Alexander Pyattaev (TUT) TLT-2727 March 5, 2012 28 / 29
Summary
Definition of QoS - a formalized way to specify service performance
Generic ideas about performance metrics used in QoS area
Methods to measure metrics of interest
Typical classes of service that are needed in the Internet
Relations between classes and applications
Lectured by Alexander Pyattaev (TUT) TLT-2727 March 5, 2012 29 / 29