| Index: > A B C D E F G H I J K L M N O P Q R S T U V W X Y Z |
|
|||||
| First Prev [ 1 2 ] Next Last |
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.
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:
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.
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:
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