Quality of service

From Free net encyclopedia

In the fields of packet-switched networks and computer networking, the traffic engineering term Quality of Service (QoS, pronounced "que-oh-ess") 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.

In the field of telephony, telephony quality of service refers to lack of noise and tones on the circuit, appropriate loudness levels etc., and includes grade of service.

1 Problems
2 Applications requiring QoS
3 Obtaining QoS
4 QoS mechanisms
5 QoS problems with some technologies
6 See also
7 External links

[edit]

Problems

When the Internet was first being created, there was no perceived need for a QoS application. So in fact the entire internet ran on a "best effort" system. There were four "type of service" bits and three "precedence" bits provided in each message, but they were largely unused. There are many things that can happen to packets as they travel from origin to destination and they result 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 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.

[edit]

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
IP telephony or Voice over IP (VOIP) may require strict limits on jitter and delay
Video Teleconferencing (VTC) requires low jitter
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).

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.

[edit]

Obtaining QoS

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 prioritising traffic.

[edit]

QoS mechanisms

Quality of Service can be provided by generously over provisioning a network so that all packets get a quality of service sufficient to support QoS-sensitive applications. This approach is relatively simple, and is economically feasible for many broadband networks. The performance is reasonable, particularly if the user is willing to sometimes accept some degradation. For example, commercial VOIP services are increasingly replacing traditional telephone service even though no QoS mechanisms are usually operating between the user's connection to his ISP and the VOIP provider's connection to a different ISP.

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. 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 IntServe 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 diffserve model, packets are marked according to the type of service they need. In response to these markings, routers and switches use various queueing 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.1p and IEEE 802.1D can be used to carry essentially the same information)

Routers supporting diffserve 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 queueing, 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 mechanisms may be used to further engineer performance, to include:

queueing
- fair-queueing
- first in first out (FIFO)
- weighted round robin, WRR
- class based weighted fair queueing
- weighted fair queuing
buffer tuning
congestion avoidance
- RED, WRED - Lessens the possibility of port queue buffer tail-drops and this lowers the likelihood of TCP global synchronization
policing and Traffic shaping

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.

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.

[edit]

QoS problems with some technologies

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 full duplex instead of 100 Mbit/s half duplex (60 with collisions to 100 Mbit/s no collisions - one way traffic) removes the collision domain. The link can transmit and receive at the full 100 megabits/s or in combination 200 megabits/s.

[edit]