Encyclopedia  |   World Factbook  |   World Flags  |   Reference Tables  |   List of Lists     
   Academic Disciplines  |   Historical Timeline  |   Themed Timelines  |   Biographies  |   How-Tos     
Sponsor by The Tattoo Collection
Quality of service
Main Page | See live article | Alphabetical index

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 See also
6 External links

Problems

Back when the Internet was created, nobody saw the need or the feasibility of QoS applications, so the whole thing ran 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:

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:

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 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:

DiffServ are typically used with: 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 properties may only be used on end ports, but not on server, backbone or other ports, that mediates many concurrent flows.

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 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).

See also

External links