(Redirected from Quality of Service)
'Quality of service', or 'QoS', in the field of
telephony, was defined in the
ITU standard X.902 as "A set of quality requirements on the collective behavior of one or more objects."
In the fields of
packet-switched networks and
computer networking, the
traffic engineering term Quality of Service refers to resource reservation control mechanisms. Quality of Service can provide different priority to different users or data flows, or guarantee a certain level of performance to a data flow in accordance with requests from the application program or the internet service provider policy. Quality of Service guarantees are important if the network capacity is limited, for example in cellular data communication, especially for real-time
streaming multimedia applications, for example
voice over IP and
IP-TV, since these often require fixed bit rate and are delay sensitive.
A network or protocol that supports Quality of Service may agree on a
traffic contract with the application software and reserve capacity in the network nodes, for example during a session establishment phase. During the session it may monitor the achieved level of performance, for example the data rate and delay, and dynamically control scheduling priorities in the network nodes. It may release the reserved capacity during a tear down phase.
Quality of Service comprises all the aspects of a connection, such as time to provide service, voice quality, echo, loss, reliability and so on. A subset of telephony QoS is
Grade of Service (GOS), which comprises aspects of a connection relating to the capacity of a network.
[1]
A
best-effort network or service does not support Quality of Service.
The term Quality of Service is sometimes used as a quality measure, with many alternative definitions, rather than referring to the ability to reserve resources. Quality of Service sometimes refers to the 'level of Quality of service', i.e. the guaranteed service quality. High QoS is often confused with a high 'level of performance' or achieved service quality, for example high
bit rate, low
latency and low
bit error probability. See also
Relation to subjective quality measures below.
Relation to subjective quality measures
An alternative and disputable definition of QoS used especially in telephony and
streaming video is a metric that reflects or predicts the subjectively experienced quality, for example the "user perceived performance"
[2], the "degree of satisfaction of the user", the "number of happy customers", the
Mean Opinion Score (MOS) value, or the
Quality of Experience (QoE) subjective business concept. In this context, QoS is the cumulative effect on subscriber satisfaction of all imperfections affecting the service. This definition includes the application and the human in the assessment, and demands an appropriate weighting of diverse objective measures such as response time, interrupts, noise, cross-talk, loudness levels, frequency response, noticeable echos, etc., and also includes
grade of service.
Problems
When the Internet was first deployed many years ago, it lacked the ability to provide Quality of Service guarantees due to limits in router computing power. It therefore ran at default QoS level, or "best effort". There were four "Type of Service" bits and three "Precedence" bits provided in each message, but they were ignored. These bits were later re-defined as
DiffServ Code Points (DSCP) and are largely honored in peered links on the modern Internet.
When looking at circuit-switched networks, Quality of service is affected by various factors, which can be divided into "human" and "technical" factors. Human factors include: stability of service, availability of service, delays, user information. Technical factors include: reliability, scalability, effectiveness, maintainability, Grade of Service, etc.
[3]
Many things can happen to packets as they travel from origin to destination, resulting in the following problems as seen from the point of view of the sender and receiver:
; Dropped packets : The routers might fail to deliver (''drop'') some packets if they arrive when their buffers are already full. Some, none, or all of the packets might be dropped, depending on the state of the network, and it is impossible to determine what will happen in advance. The receiving application may ask for this information to be retransmitted, possibly causing severe delays in the overall transmission.
; Delay : It might take a long time for a packet to reach its destination, because it gets held up in long queues, or takes a less direct route to avoid congestion. In some cases, excessive delay can render an application, such as VoIP, unusable.
; Jitter : Packets from source will reach the destination with different delays. A packet's delay varies with its position in the queues of the routers along the path between source and destination and this position can vary unpredicably. This variation in delay is known as
jitter and can seriously affect the quality of streaming audio and/or video.
; Out-of-order delivery : When a collection of related packets is routed through the Internet, different packets may take different routes, each resulting in a different delay. The result is that the packets arrive in a different order than they were sent. This problem necessitates special additional protocols responsible for rearranging out-of-order packets to an
isochronous state once they reach their destination. This is especially important for video and VoIP streams where quality is dramatically affected by both latency or lack of isochronicity.
; Error : Sometimes packets are misdirected, or combined together, or corrupted, while ''en route''. The receiver has to detect this and, just as if the packet was dropped, ask the sender to repeat itself.
Applications requiring QoS
A defined Quality of Service may be required for certain types of network traffic, for example:
★ streaming
multimedia may require guaranteed throughput to insure that a minimum level of quality is maintained.
★
IP telephony or Voice over IP (VOIP) may require strict limits on jitter and delay
★ Video Teleconferencing (VTC) requires low jitter and latency
★ Alarm signalling (eg.
Burglar alarm)
★
dedicated link emulation requires both guaranteed throughput and imposes limits on maximum delay and jitter
★ a
safety-critical application, such as
remote surgery may require a guaranteed level of
availability (this is also called ''hard QoS'').
★ a remote system administrator may want to prioritize variable, and usually small, amounts of SSH traffic to ensure a responsive session even over a heavily-laden link.
These types of service are called ''inelastic'', meaning that they require a certain level of bandwidth and a certain maximum latency to function.
By contrast, ''elastic'' applications can take advantage of however much or little bandwidth is available.
Obtaining QoS
★ Per call
★ In call
★ In advance: When the expense of mechanisms to provide QoS is justified, network customers and providers typically enter into a contractual agreement termed an 'SLA' ('
Service Level Agreement') which specifies guarantees for the ability of a network/protocol to give guaranteed performance/throughput/latency bounds based on mutually agreed measures, usually by prioritizing traffic.
★ Reserving resources: Resources are reserved at each step on the network for the call as it is set up. An example is RSVP,
Resource Reservation Protocol.
QoS mechanisms
Quality of Service (QoS) can be provided by generously over-provisioning a network so that interior links are considerably faster than access links. This approach is relatively simple, and may be economically feasible for broadband networks with predictable and light traffic loads. The performance is reasonable for many applications, particularly those capable of tolerating high jitter, such as deeply-buffered video downloads.
Commercial VoIP services are often competitive with traditional telephone service in terms of call quality even though QoS mechanisms are usually not in use on the user's connection to his ISP and the VoIP provider's connection to a different ISP. Under high load conditions, however, VoIP quality degrades to cell-phone quality or worse. The mathematics of packet traffic indicate that a network with QoS can handle four times as many calls with tight jitter requirements as one without QoS. The amount of over-provisioning in interior links required to replace QoS depends on the number of users and their traffic demands. As the Internet now services close to a billion users, there is little possibility that over-provisioning can eliminate the need for QoS when VoIP becomes more commonplace.
For narrowband networks more typical of enterprises and local governments, however, the costs of bandwidth can be substantial and over provisioning is hard to justify.
[4] In these situations, two distinctly different philosophies were developed to engineer preferential treatment for packets which require it.
Early work used the "
IntServ" philosophy of reserving network resources. In this model, applications used the
Resource reservation protocol (RSVP) to request and reserve resources through a network. While IntServ mechanisms do work, it was realized that in a broadband network typical of a larger service provider, Core routers would be required to accept, maintain, and tear down thousands or possibly tens of thousands of reservations. It was believed that this approach would not scale with the growth of the Internet, and in any event was antithetical to the notion of designing networks so that Core routers do little more than simply switch packets at the highest possible rates.
The second and currently accepted approach is "
DiffServ" or differentiated services. In the DiffServ model, packets are marked according to the type of service they need. In response to these markings, routers and switches use various queuing strategies to tailor performance to requirements. (At the IP layer, differentiated services code point (
DSCP) markings use the 6 bits in the IP packet header. At the MAC layer,
VLAN IEEE 802.1Q and
IEEE 802.1D can be used to carry essentially the same information)
Routers supporting DiffServ use multiple queues for packets awaiting transmission from bandwidth constrained (e.g., wide area) interfaces. Router vendors provide different capabilities for configuring this behavior, to include the number of queues supported, the relative priorities of queues, and bandwidth reserved for each queue.
In practice, when a packet must be forwarded from an interface with queuing, packets requiring low jitter (e.g.,
VoIP or
VTC) are given priority over packets in other queues. Typically, some bandwidth is allocated by default to network control packets (e.g.,
ICMP and routing protocols), while best effort traffic might simply be given whatever bandwidth is left over.
Additional
bandwidth management mechanisms may be used to further engineer performance, to include:
★
Traffic shaping (
rate limiting):
★
★
token bucket
★
★
leaky bucket
★
Scheduling algorithms:
★
★
weighted fair queuing (WFQ)
★
★
class based weighted fair queuing
★
★
weighted round robin (WRR)
★
★
deficit weighted round robin (DWRR)
★ congestion avoidance:
★
★
RED,
WRED - Lessens the possibility of
port queue buffer tail-drops and this lowers the likelihood of
TCP global synchronization
★
★ Policing (marking/dropping the packet in excess of the committed traffic rate and burst size)
★
★
explicit congestion notification
★
★ buffer tuning
As mentioned, while
DiffServ is used in many sophisticated enterprise networks, it has not been widely deployed in the Internet. Internet
peering arrangements are already complex, and there appears to be no enthusiasm among providers for supporting QoS across peering connections, or agreement about what policies should be supported in order to do so.
One compelling example of the need for QoS on the Internet relates to this issue of
congestion collapse. The Internet relies on congestion avoidance protocols, as built in to TCP, to reduce traffic load under conditions that would otherwise lead to Internet Meltdown. QoS applications such as
VoIP and
IPTV, because they require largely constant bitrates and low latency cannot use
TCP, and cannot otherwise reduce their traffic rate to help prevent meltdown either. QoS contracts limit traffic that can be offered to the Internet and thereby enforce traffic shaping that can prevent it from becoming overloaded, hence they're an indispensable part of the Internet's ability to handle a mix of real-time and non-real-time traffic without meltdown.
Asynchronous Transfer Mode (ATM)
network protocol has an elaborate framework to plug in QoS mechanisms of choice. Shorter data units and built-in QoS were some of the
unique selling points of ATM in the
telecommunications applications such as
video on demand,
voice over IP.
QoS Priority Levels
| Priority Level | Traffic Type |
|---|
| 3 | Excellent Load(Business Critical) |
|---|
| 4 | Controlled Load(Streaming Multimedia) |
|---|
| 5 | Video(Interactive Media)[Less than 100ms latency and jitter] |
|---|
| 6 | Voice(Interactive Voice)[Less than 10ms latency and jitter] |
|---|
| 7 | Network Control Reserved Traffic [Lowest latency and jitter] |
|---|
QoS problems
★
Internet2 QoS Working Group concluded that increasing bandwidth is probably more practical than implementing QoS.
[1][2]
Protocols that provide Quality of Service
★
Differentiated services (DiffServ)
★
Frame relay
★
X.25
★ Some
ADSL modems
★
Integrated services (IntServ)
★
Resource reSerVation Protocol (RSVP)
★
RSVP-TE
★
Asynchronous Transfer Mode (ATM)
★
Multiprotocol Label Switching (MPLS) provides eight QoS classes
★
IEEE 802.1p
★
IEEE 802.11e
★
IEEE 802.11p
★ The
Type of Service (TOS) field in the IP header
QoS Solutions
The research project
MUSE defined a QoS concept which was further worked out in another research project
PLANETS. The new idea of this solution is to agree on a discrete jitter value per QoS class which is imposed on network nodes. Including best effort four QoS classes were defined, two elastic and two inelastic. The solution has several benefits:
★ End-to-end delay and packet loss rate can be predicted
★ It is easy to implement with simple scheduler and queue length given in
PLANETS
★ Nodes can be easily verified for compliance
★ End users do notice the difference in quality
See also
★
BSSGP
★
Best-effort
★
Class of Service
★
Grade of service (GOS)
★
Mean Opinion Score (MOS)
★
Network neutrality
★
Quality of Experience (QoE)
★
Series of tubes
★
Streaming media
★
Subjective video quality
★
Tiered Internet
★
Traffic shaping
★
QPPB
Books
★ "Deploying IP and MPLS QoS for Multiservice Networks: Theory and Practice" by John Evans, Clarence Filsfils (Morgan Kaufmann, 2007, ISBN 0-12-370549-5)
External links
★
QoS Tutorial
★
Quality of Service Networking
★
Network QoS
Notes
1. ITU-T Study Group 2, Teletraffic Engineering Handbook (350 pages, 2.7 MB)(It uses abbreviation GoS instead of GOS) http://www.com.dtu.dk/teletraffic/handbook/telenook.pdf
2. Leonard Franken. Quality of Service Management: A Model-Based Approach. PhD thesis, Centre for Telematics and Information Technology, 1996.
3. Peuhkuri M., IP Quality of Service, Helsinki University of Technology, Laboratory of Telecommunications Technology, 1999.
4. http://bennett.com/blog/index.php/archives/2006/08/17/how-much-bandwidth-is-enough/
العربية
中国
Français
Deutsch
Ελληνική
हिन्दी
Italiano
日本語
Português
Русский
Español
