What is Quality of Service (QoS)?
Generally, any product or service can be appraised to realize its performance, quality or the degree to which it satisfies its design requirements. In the field of telephony, the traffic engineering term Quality of Service (QoS) refers to the lack of noise and tones on the circuit, appropriate loudness levels etc., and includes grade of service. It encompasses all the aspects of a connection, such as time to provide service, voice quality, echo, loss, reliability and so on. In the fields of packet-switched networks and computer networking, QoS refers to the probability of the telecommunication network meeting a given traffic contract, or in many cases is used informally to refer to the probability of a packet succeeding in passing between two points in the network.
What problems are associated with QoS?
When the Internet was first created, there was no perceived need for a QoS application; as a result the entire internet ran on a "best effort" system. Each packet (data unit) consisted of a series of meaningful bits, which included bits representing "type of service" and "precedence" respectively, but these bits were largely unused. There are many factors, expected or unexpected, that can affect a packet en route. For example, a broken link could mean a reduction in the number of transmission links resulting in delay or denial of service; or an unusually high number of packets transmitted could trigger congestion or a bottleneck, thereby causing the sender and/or receiver to view the quality of service as having declined. From the point of view of the sender and receiver, some of the problems that result when packets are affected in en route are:
- 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 happened in advance. The receiving application must 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. Alternatively, it might follow a fast, direct route. Thus delay is very unpredictable.
- jitter - packets from source will reach the destination with different delays. 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 are 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 to the one with which they were sent. This problem necessitates special additional protocols responsible for rearranging out-of-order packets once they reach their destination.
- 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.
What types of applications require QoS?
A traffic contract (SLA, Service Level Agreement) specifies guarantees for the ability of a network/protocol to give guaranteed performance/throughput/latency bounds based on mutually agreed measures, usually by prioritising traffic. A defined Quality of Service may be required for certain types of network traffic, for example:
- streaming multimedia may require guaranteed throughput
- IP telephony may require strict limits on jitter and delay
- dedicated link emulation requires both guaranteed throughput and imposes limits on maximum delay
- a safety-critical application, such as remote surgery may require a guaranteed level of availability (this is also called hard QoS).
These types of service are called inelastic, meaning that they require a certain level of bandwidth to function - any more than required is unused, and any less will render the service non-functioning. By contrast, elastic applications can take advantage of however much or little bandwidth is available.
How can QoS be Obtained?
There are essentially two ways to provide QoS guarantees. The first is simply to provide lots of resources, enough to meet the expected peak demand with a substantial safety margin. This is nice and simple, but some people believe it to be expensive in practice, and can't cope if the peak demand increases faster than predicted: deploying the extra resources takes time. The second one is to require people to make reservations, and only accept the reservations if the routers are able to serve them reliably. Naturally, you can then charge people money for making reservations! There are two popular variations on this:
- Integrated Services (IntServ): Briefly described, IntServ is a model used for providing traffic forwarding service levels in networks. It allows for microflows to be created with reserved resources (such as bandwidth) and other traffic handling characteristics (maximum packet size, maximum burst size, etc.). Traffic is pushed into these microflows in the direction of the required destination.
- Differentiated ServicesDiffServ: Briefly described, DiffServ is an architecture for providing different types or levels of service for network traffic. One key characteristic of diffserv is that flows are aggregated in the network, so that core routers only need to distinguish a comparably small number of aggregated flows, even if those flows contain thousands or millions of individual flows.
DiffServ are typically used with:
- weighted round robin, WRR.
- RED, WRED - Lessens the possibility of port queue buffer tail-drops and this lowers the likelihood of TCP global synchronization.
- Traffic shaping
- A number of port queue buffers.
- VLAN IEEE 802.1p and IEEE 802.1D.
Network equipment, that supports DiffServ and perhaps IntServ, are called multilayer network equipment. A switch that supports DiffServ and perhaps IntServ is called a multilayer switch. However, the market has not yet favoured QoS services. Some people believe that this is because a "dumb" network that offers sufficient bandwidth for most applications, most of the time, is already economically stable, with little incentive to deploy non-standard stateful QoS-based applications. 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. QoS skeptics further point out that if you are dropping many packets on elastic low-QoS connections, you are already dangerously close to the point of congestion collapse on your inelastic high-QoS applications, without any way of further dropping traffic without violating traffic contracts.
The following properties may only be used on end ports, but not on server, backbone or other ports that mediate many concurrent flows.
- half duplex - link collisions make delay variations (jitter), because the packets are delayed with each collision by the backoff-time.
- Port queue buffer IEEE 802.3x "flow"-control.
IEEE 802.3x "flow"-control does not really specify a flow control protocol, but rather a kind of queue-control. An example of an IEEE 802.3x problem is "head of Line"-blocking. Many of today's switches have IEEE 802.3x on as default - even on uplink/backbone ports. Quote from Network World, 09/13/99, 'Flow control feedback': "...Hewlett-Packard points out that quality of service is a better way to handle potential congestion, and Cabletron and Nortel note that QoS features can't operate properly if a switch sends [IEEE 802.3x] pause frames...." This quote suggests that QoS and IEEE 802.3x are incompatible. An ethernet connection with 100 Mbit/s full duplex instead of 100 Mbit/s half duplex increases the effective speed from ca. 60-100 Mbit/s half duplex to 200 Mbit/s (100 Mbit/s transmit + 100 Mbit/s receive).
Exercise:
Consider the fact that QoS can be viewed from the network user's (sender and receiver) point and from the service provider's point. How has technological development affected the QoS from both the user's and the provider's reference point?
References
- Web definitions : authors.phptr.com/morris/glossary.html
- homepages.uel.ac.uk/u0110214/PacketStruckture.htm
- Oodan A. P.,Ward K. E., Mullee A. W., Quality of Service in Telecommunications, Institute of Electrical Engineers, London, 1997
Retrieved and edited from "http://en.wikipedia.org/wiki/Quality_of_service" ___________________________________________________________
Comments, questions, feedback, criticisms?
Send feedback
- E-mail the author of the module, What is Quality of Service (QoS)?
Footer
More about this content: Metadata | Version History
This work is licensed by Mookho Tsilo under a Creative Commons Attribution License (CC-BY 2.0).
Last edited by Mookho Tsilo on Feb 17, 2006 6:24 am US/Central.