QoS metrics and requirements - PDF Free Download

QoS metrics and requirements Lectured by Alexander Pyattaev Department of Communications Engineering Tampere University of Technology alexander.pyattaev@tut.fi March 5, 2012

Outline 1 Introduction 2 Performance metrics definition 3 Performance metrics used in QoS Metrics for traffic flows Metrics for service performance Service availability 4 Requirements for different services Best Effort service CBR (voice) service Real-Time (interactive) service Near real-time (video-on-demand) service Other services 5 Conclusions Lectured by Alexander Pyattaev (TUT) TLT-2727 March 5, 2012 2 / 29

Definition of QoS Yet another definition for QoS: Quality - assurance, that the service happens exactly as promised All performance metrics are within limits Service is available when customer needs it Service - the thing we do for which we are getting paid In our case serving requests In 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 BUT Those 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

Primary metrics For any queuing system, we can easily define some primary performance metrics 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 100 pkts over 10 sec Queuing system? Service 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 service No care for the user s data getting lost Promise some non-zero average service rate This is what most smaller ISP s provide This is what Internet was originally built on Service with defined quality - provide exact specifications What kind of service discipline is used What is the service rate Capability to handle bursts List goes on... This is what most cellular and telephone networks provide This is what serious businesses are built on Queuing system Arrivals Service Service rate, N pkts buffer 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 some mathematical model We clearly state that our promise holds only when the arrival flow fits into some other mathematical model We clearly state what happens if the arrival flow restrictions are not met 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 points Lectured by Alexander Pyattaev (TUT) TLT-2727 March 5, 2012 9 / 29

Traffic flow metrics - scientist s solution To promise handling of a given traffic flow, one defines its statistical properties Unfortunately, Customers and lawyers do not wish to understand what does variance mean It is difficult to prove that given observation fits/does not fit certain distribution One has to monitor the metrics continuously, which is challenging for non-stationary flows (try measuring variance of a non-stationary flow) We are trying to define a set of limiting conditions, not give an example 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 for QoS 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; we improvise: We can always define maximum/minimum sustained rate (Mean) Limit the burst size in duration and amplitude (Variance and distribution) Limit the amount of traffic over long period (Non-stationarity) Let us consider an example in more detail: Flow, Gb/s 8 5 b 0 12 24 time,h 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) 8 Flow, Gb/s 5 b 0 12 24 time,h Black line r- actual measurements (noisy and unreliable) Red line R- filtered measurements (show when something really happens) Thresholds R m ax and R min 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 the maximum sustained rate R < R max. When R > R max, we detect a burst Peaks unexpectedly fill queues over their normal loading n The queue capacity N should be large enough to handle the extra burst The actual peak size is its integral above the R max (shown in blue) Normally, the peak immediate rate r m ax is hard-limited by channel bandwidth. All samples above R max are bursts, but we are only interested in those that cause R to go above R max (interval b) Flow, Gb/s r max 8 5 R max 0 12 24 time,h b b 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 considered on 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 delays We could use the metrics above, or we can do worse. RFC-3393 defines Jitter, or packet delay variation (PDV) as the first derivative of the packet delay. It is not variance, but is strongly correlated with it!. Normally, average jitter is measured (with a sliding window) to get a singleton value instead of a vector No jitter is a good jitter. Multimedia applications can usually adapt to nearly any delay, but do not tolerate jitter very well It is extremely hard to compute jitter analytically, and in ATM networks 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 networks we usually do not know it anyway). Instead, we specify performance metrics in cases when arrival flows are according to our specifications Probability of packet loss Mean packet delay d, 95% packet delay d 95 95% of packets have delay d < d 95 The remaining 5% can have arbitrary delays What happens with packets that violate the arrival flow requirements No delay guarantees are given in this case Those packets can usually be dropped Therefore, the critical part is to specify the arrival flow, and then system performance 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 quality downtime at an given moment of time = 1 uptime+downtime If the service is working, but slower then allowed - it is not available Dropped connections in connection-oriented systems are typically counted separately Most telecoms operators have to guarantee availability of 0.99999 (5 min downtime/year) to get a license At the same time up to 0.5% of calls can be dropped during any given hour Lectured by Alexander Pyattaev (TUT) TLT-2727 March 5, 2012 19 / 29

Level of service The level of service(class of service) summarizes the performance metrics that 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 a better 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 be used to perform service. If the network is fully reserved for other service classes, nothing will be 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-interactive ones. It is assumed that the transfer protocol employs some way of adapting 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 user may 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 question value-for-money ratio you promise The Internet is suited mostly to handle BE traffic, but true BE service exists 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 can be 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 good enough 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 survive jitter and packet loss. In fact, for RT services packet loss is preferred over extra 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 multiplayer game) 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 does not require a very stable connection. Such profile is typical for web applications, that generate large bursts of traffic with long waiting periods. Video-on-demand and web radio systems also fit the profile, as the client cache can compensate rather large jitter or even losses, but caching process 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 Internet links (after file transfers, of course), and therefore should always be taken into 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 universal standard, but the above ones are commonly used when talking about QoS-related topics. Lectured by Alexander Pyattaev (TUT) TLT-2727 March 5, 2012 27 / 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