Quality of service
In the fields of
packet-switched networks and
computer networking, the
traffic engineering term
Quality of Service (
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 within its desired latency period.
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.
When the Internet was first deployed many years ago, it lacked the ability to provide Quality of Service guarantees because its infrastructure was too limited, consisting of data links no faster than 56 Kbps, the speed of the modern dial-up modem. It therefore ran at default QoS level, or "best effort". There were four "Type of Service" bits and three "Precedence" bits provided in each message, but they were ignored. These bits were later re-defined as
DiffServ Code Points (DSCP) and are largely honored in peered links on the modern Internet.
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.
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
* Alarm signalling (eg.
Burglar alarm)
*
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).
* Grid computing applications using
Hpc4u middleware that guarantee QoS by offering
Fault tolerance mechanisms
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.
* Per call
* In call
* In advance: 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.
* Reserving resources: Resources are being reserved at each step on the network for the call as it is set up. An example is RSVP,
Resource Reservation Protocol.
Quality of Service can be provided by generously over-provisioning a network so that interior links are considerably faster than access links. This approach is relatively simple, and may be economically feasible for broadband networks with predictable and light traffic loads. The performance is reasonable for many applications, particularly those capable of tolerating high jitter, such as deeply-buffered video downloads.
Commercial VoIP services are often competitive with traditional telephone service in terms of call quality even though QoS mechanisms are usually not in use on the user's connection to his ISP and the VoIP provider's connection to a different ISP. Under high load conditions, however, VoIP quality degrades to cell-phone quality or worse. The mathematics of packet traffic indicate that a network with QoS can handle four times as many calls with tight jitter requirements as one without QoS. The amount of over-provisioning in interior links required to replace QoS depends on the number of users and their traffic demands. As the Internet now services close to a billion users, there is little possibility that over-provisioning can eliminate the need for QoS when VoIP becomes more commonplace.
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 IntServ 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 DiffServ model, packets are marked according to the type of service they need. In response to these markings, routers and switches use various queuing 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.1q and IEEE 802.1D can be used to carry essentially the same information)
Routers supporting DiffServ 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 queuing, 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:
*queuing
** fair-queuing
** first in first out (FIFO)
**
weighted round robin,
WRR** class based weighted fair queuing
**
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 shapingAs 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.
One compelling example of the need for QoS on the Internet that is often ignored by the naive relates to this issue of
congestion collapse. Either by error or by intention, the Internet relies on TCP to reduce traffic load under conditions that would otherwise lead to Internet Meltdown. QoS applications such as VoIP and IPTV do not use TCP, hence they can't help prevent meltdown. QoS contracts limit traffic that can be offered to the Internet and thereby prevent it from becoming overloaded, hence they're an indispensable part of the Internet's ability to handle a mix of real-time and non-real-time traffic without meltdown.
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.
*
Internet2 QoS Working Group determined that "it doesn't scale" to large networks (such as the Internet).
[1][2]*
Traffic shaping*
Network neutrality*
Tiered Internet*
Series of tubes
