In the fields of broadband networks, 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. 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.

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

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 dedicated link emulation requires both guaranteed throughput and imposes limits on maximum 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 - 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.

Obtaining QoS There are essentially two ways to provide QoS guarantees in broadband networks. 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:In computer networking, IntServ or integrated services is an architecture, which specifies the elements to guarantee quality of service (QoS) on networks. IntServ can for example be used to allow video and sound to reach the receiver without interruption. IntServ specifies a fine-grained QoS system, which is often contrasted with DiffServ's coarse-grained control system. DiffServ or differentiated services is a method of trying to guarantee quality of service on large networks such as the Internet. DiffServ deals with bulk flows of data rather than single flows and single reservations. This means that a single negotiation will be made for all of the packets from, for example, a single ISP, or a single university. The contracts resulting from these negotiations are called "service level agreements", and will inevitably involve money changing hands. These service level agreements will specify what classes of traffic will be provided, what guarantees are needed for each class, and how much data will be sent for each class. 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.

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