Quality of Service

In the fields of telecommunications and computer networking, the traffic engineering term Quality of Service (QoS) can mean two related but distinct things.

In circuit-switched networks it refers to the probability of being able to initiate a call to another party. In packet-switched networks it refers to the probability of the network meeting a given traffic contract, or in many cases is used informally to refer the probability of a packet passing between two points in the network.

Table of contents

1 Problems
2 Applications requiring QoS
3 Obtaining QoS
4 QoS problems with some technologies
5 External addresses

Problems

Back when the Internet was created, nobody saw the need or the feasability of QoS applications, so the whole thing runs on a "best effort" system. There were 4 "type of service" bits and three "precedence" bits provided in each message, but they were largely unused. There are many nasty things that can happen to packets as they wing their way from place to place, 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. All of the packets might be dropped, or none of them, depending on the state of the network, and there's no way to tell which in advance. The receiving application must ask for this information to be retransmitted, and this will often cause a severe hiccup in transmission.
delay - it might take a long time for your packet to reach it's destination, because it gets held up in long queues, or takes a more indirect route to avoid congestion. Alternatively, it might be very fast, there is no way to predict which in advance.
out-of-order delivery - the Internet often delivers packets in a different order to the order that they were sent, because they get sent on different routes, which requires special protocols to avoid having your website displayed upside down, or with the introduction right at the bottom, or similar errors.
error - sometimes packets are misdirected, or mixed up 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 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
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 - if they get more than that they can't use it, and if they get less, then they can't function at all. By contrast, elastic applications can take advantage of however much or little bandwidth is available.

Obtaining QoS

There are essentially two ways to provide QoS garantees. 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:

DiffServ are typically used with:

weighted round robin, WRR.
RED, WRED - Lessens the possibility of port queue buffer tail-dropss and this lowers the likelihood of TCP global synchronization.
Traffic shaping
A number of port queue bufferss.
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.

to do: mention Paris Metro pricing as a minimal QoS policy

QoS problems with some technologies

The following proporties may only be used on end ports, but not on server, backbone or other ports, that mediates 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 are not a real flow control, but instead a queue-control. An example of a IEEE 802.3x problem are "head of Line"-blocking. Many of todays 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).