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




5 Conclusions


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.


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.


Outline

1 Introduction




5 Conclusions


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


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


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




5 Conclusions


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


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


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


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


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.


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


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


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.


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


Outline

1 Introduction




5 Conclusions


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


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.


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.


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)


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)


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


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.


Outline

1 Introduction




5 Conclusions


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 - tiedekunnat · 2012-03-05 · outline 1 introduction 2 performance...

Documents