Helsinki University of Technology, Laboratory of Telecommunications Technology
The quality of service is one of most important areas of Internet development. As the Internet originally developed for data communications is now used more and more for real-time applications, there is a need for better service than the ``best effort''. In this study we will first review the concept quality of service, what it is and then we study the two most important efforts to provide QoS in the Internet: the Integrated Services and the Differentiated Services models. Both have their own application area as the first provides more fine grained control to network resources as the later gives better scalability.
The Internet has recently become an important communications channel. The Internet was used in the 1980s and in the beginning of 1990s by research and education communities for computer data transmission: electronic mail, network news (Usenet) and file transfers. The most demanding application from the service quality point of view was a network virtual terminal (telnet ) as it was an interactive application. The bandwidth required was small and occasional delay variations of order of several seconds could be tolerated .
Recently many interactive or real-time services has been introduced and at the same time the economical importance of the Internet has grown. The IP phones and services based on that technology is threatening the traditional circuit-switched telephone services, specially on long-distance applications.
Transmitting interactive real-time media is the greatest challenge in packet based networks. The end-to-end delay, the delay variations (jitter), and the packet loss must not exceed some limits or usability of the service degrades badly .
The Internet has worked so far with a best effort traffic model: every packet is treated (forwarded or discarded) equally. This is very simple and efficient model and several arguments has been stated against any need for a more complicated system :
As wireless systems are more and more common, they limit available bandwidth because capacity on usable radio frequencies is limited. Also the energy conservation in portable equipment may limit available bandwidth.
Corollary of Moore's Law: As you increase the capacity of any system to accommodate user demand, user demand will increase to consume system capacity. [21, p. 10]
There are two approaches to assigning the priority in Internet traffic: hop-by-hop based on reservation (Integrated services, Chapter 4) and packet marking at edges of network (Differentiated services, Chapter 5).
The Quality of Service (QoS) is often quite much abused term. If we look at traditional circuit-switched telecommunication networks, the QoS is formed by several factors, which can be divided into two groups: ``human'' and ``technical'' factors as shown in Table 1.
|Human factors||Technical factors|
|stability of service quality||reliability|
|availability of subscriber lines||expandability|
|fault clearance times||maintainability of the system|
|subscriber information||congestion waiting|
|stability of operation of the system||transmission quality|
In the packet switched networks there are much more factors then in the circuit-switched networks that must be agreed on. The Asynchronous Transfer Mode (ATM) networks have very extensive QoS control as it is intended for real-time traffic . For the IP networks the ITU is developing a recommendation I.380  which defines quite similar metrics for IP packet transfer performance parameters:
For ATM networks there are also metrics to characterize traffic flow for call admission control (CAC) purposes:
The IETF Internet Protocol Performance Metrics (IPPM) working group is working to define metrics for the Internet performance. The framework document  defines criteria for those metrics, terminology, the metrics itself, the methodology, and the practical considerations including sources of uncertainty and errors. There are some differences in terminology considering time between ITU-T definitions and IPPM working group definitions. Short summary of the differences is presented in Table 2.
|synchronization||time error||difference of two clocks|
|accuracy||time error from UTC||difference to real time|
|resolution||sampling period||the precession of clock|
|skew||time drift||change in synchronization or in accuracy|
As full traffic analysis is not always feasible, the IPPM metrics are based on random sampling of traffic. The framework document  includes discussion that recommends that the Internet properties are not considered in probabilistic terms as there is no static state in the Internet.
The Grade of Service (GoS) has been used in the telecommunications industry to indicate components which contribute to overall quality of service what the user experiences. Many components have both human component and technical component: the technical component can be measured (like bandwidth of voice) and the human component is subjective. There is relation between human and technical components but the exact mapping depends on many factors, for example language used and other culture factors . In  the GoS is defined as the following:
It may happen that in a network, or in part of a network, the volume of telephone traffic that arises exceeds the capacity for handling it without limitations, with the result that congestion occurs. These limitations affect the service provided to customers, and the degree of these limitations is expressed by an appropriate GoS parameter (e.g. probability of loss, average delay, failure rate due congestion, etc.). GoS should therefore be regarded as providing information on the traffic aspects of the ``quality of service''.
In a circuit-switched network the GoS has been divided into two standards :
The Class of Service concept divides network traffic into different classes and provides class-dependent service to each packet depending on what class it belongs to. While the strict QoS has some absolute measures for quality, the CoS has relative measures: at this time this class gets packet drop probability of 10-6 while on the other class packet drop probability is 10-3.
To differentiate the network traffic into the different classes, the differentiation must be based on some factor. The factors include[21, p. 21]:
The source port identifies traffic originating from the server.
In IPv6 there are was originally 4-bit priority field (8 levels for real time traffic and 8 levels for elastic traffic)  but it is now replaced with 8-bit traffic class field (DS Field) [18,34].
It is also possible, that some other descriptor is used to identify flow. In IPv6 there is defined a 20-bit flow label that can be used to identify a flow with source host address .
The Internet Protocol (IP) development started in DARPA ARPANET in 1969 using IMP nodes. As the network grow, the development work for common fault tolerant protocol started in 1974. The architecture and the core protocols was ready by end of 1970s and beginning of 1980s [40,42,41,43]. In January 1983 the ARPANET changed from Network Control Protocol (NCP) to Internet Protocol family (TCP/IP). The most commonly used applications programming interface (API) for TCP/IP services was developed for BSD 4.2 UNIX in 1983: the same interface is used on most platforms .
The IP works roughly at network layer in ISO Open Systems Interconnection (OSI) model . The supporting protocols are Internet Control Message Protocol (ICMP)  (error reporting, configuration and diagnosis), Internet Group Management Protocol (IGMP) [16,20] (multicast management), and Address Resolution Protocol (ARP)  which performs mapping between link layer addresses and IP addresses if needed.
The IP is a datagram delivery service: each datagram contains enough information to carry it to its destination. There is no call setup: the service is connectionless. The network, however, does not make any guarantees if the datagram is delivered to destination. If the packet is lost, corrupted, misdelivered, or for some other reason not delivered to its intended destination, the network does nothing to recover from the failure. This service model is commonly called as best effort or unreliable service. IP does not either guarantee anything about order in which packets arrive to destination nor that the packets are delivered at most once (datagrams may duplicate). However, there is a limited life time for each datagram.
The best effort connectionless service is the simplest service a internetwork can provide: this makes it possible to transfer datagrams over any link layer technology (as in humorous ``specification'' in ). If the link losses some packets, that's fine. If the link delivers all packets, even better.
If we want to transport data reliably on top of IP, we need a transport protocol which hides unreliability of IP from application. The most simple solution is that the sender sends one data segment; if the receiver receives it successfully, it acknowledges received packet. As sender receives acknowledgment it may send the second segment. If either segment or acknowledgment is lost or receiver is not online, the sender does not receive acknowledgment in specified time and retransmits segment. 
This is not very efficient as the transmission speed is restricted by the round trip delay. A better approach is to use sliding window scheme: the receiver announces how much it is prepared to receive: the sender can send this much without getting acknowledgment.
The Transmission Control Protocol (TCP) provides reliable byte stream using sliding window flow control scheme. The original scheme, however, worked badly in case of congestion as was seen first in 1986 in ``congestion collapses'' . The scheme was then improved by introducing following methods:
In addition to the window used for flow control (e.g.. the sender does not overrun the receiver) the concept of a congestion window was introduced. The congestion window tells the sender how much it can send to network and the sender selects minimum of those two windows.
The improvements made lead to more graceful operation in case of congestion. The problem is that there are difficulties to estimate (specially in case of retransmissions) round trip delay which is vital for maintaining steady flow. This has been addressed with timestamp option . Current TCP congestion control algorithms and discussion can be found from [1,22].
The TCP is an elastic transport protocol: it adapts its transfer rate to available bandwidth on on network. It does not make any efforts to have minimum rate but only deliveries data in reliable manner.
The User Datagram Service (UDP) provides program addressing (ports) and optional data integrity check (a checksum for payload) . It does not add any reliability to delivery, hence the original name ``Unreliable''.
The UDP is suitable for use as a carrier for real-time traffic as it does not have any flow control or retransmissions which could affect on timing. With real-time traffic retransmissions are generally useless as retransmitted data arrives too late to be for any use.
For a real-time application, there is more need for control than the UDP provides. The real-time transport protocol (RTP) and accompanying real-time control protocol (RTCP) are designed for this purpose . The RTP packets encapsulated in UDP packets carry the actual real-time data and have a sequence number and a time stamp. The sequence number makes it possible that the receiver can find out if there are some dropped packets. The time stamp is used to detect jitter introduced by network and end systems.
The lack of any QoS guarantees or levels in Internet is considered as one of main limitation of more wide use of Internet. To solve this problem an IETF Internet Integrated Services working group was formed. It defined a framework for the resource reservation and the performance guarantees. This framework is independent from protocols used for signaling and implementation details .
Each network node is divided into two parts: background process and traffic forwarding (see Figure 3). The background process takes care of routing, reservation setups and admission control in addition to management. The traffic forwarding part classifies traffic based on information in the traffic control database and based on this classification, the traffic scheduled to right queues.
By now there are two service classes. Both of them support merging of flows (aggregation) for scalability and have the rules to substitute ``as good or better'' service if the requested service is not available.
The guaranteed service is designed for applications which require certain minimum bandwidth and maximum delay. The service, as it provides firm (mathematically provable) bounds for end-to-end queuing delay, makes possible to provide service that guarantees both the delay and the bandwidth. 
The traffic is considered as a fluid model: delivered queuing delays
do not exceed the fluid delays by more than the specified error
bounds. The maximum delay is
where b is a token bucket depth, r is a bucket rate, p is a token bucket plus peak rate, M is a maximum datagram size, R is a bandwidth allocated to connection, is a end-to-end sum of rate-dependent error terms, and is a end-to-end sum of rate-independent, per-element error terms. When the resource reservation is being made, each node calculates its values for C and D.
As long as the traffic is conforming to traffic specification (TSpec: b, r, p, m (a minimum policed unit; used to estimate link level overhead), M) the network element must transmit the packets conforming to receiver specification (RSpec: R, S (a slack term; ``extra'' time the node can delay the datagram)). If the traffic exceeds the traffic specification, the non-conforming datagrams must be considered as best-effort datagrams. They should not be given any presence over other best-effort datagrams (to avoid misuse) nor they should be discarded as erroneous packets as a originally conforming traffic may become non-conforming in the network.
The controlled-load service provides independent the network element load the client data flow with QoS closely approximating the QoS the flow would receive in unloaded network. It uses capacity (admission) control to assure this. 
As in the guaranteed service (Chapter 4.1) the service is provided for a flow conforming the same TSpec. The applications may assume that only very few if any packets are lost and only very few if any packets greatly exceed minimum transit delay. If a non-conforming packet is received, the network element must ensure that
All resource reservation systems need a setup (signaling) protocol to allocate needed resources from the network. For the IP networks, the Resource ReSerVation Protocol (RSVP) is specified . The RSVP is independent from Integrated Services model and can be used with variety of QoS services as the Integrated Services can be used with variety of setup protocols .
The RSVP request is receiver initiated: this provides better scalability for large multicast receiver groups, more flexible group membership and diverse receiver requirements. The sender sends Path messages which records the route packets travel to receiver and has a traffic characterization information. On reception of a Path message the receiver sends a Resv message to reserve needed capacity from the network. This message travels hop-by-hop same route (other direction) the Path message traveled.
The RSVP supports three types of reservations:
One of crucial problems is resource reservation charging. If the resources can be reserved without charge, all network users will want reserve all of bandwidth to themselves. For a network to provide QoS, there must be some monetary cost associated to reservation which corresponds to amount of resources reserved. There is no currently any billing mechanism defined, but there is mechanism for cryptographic authentication . The key management and accounting  are still big issues to be solved.
In larger networks there are generally several alternative routes between two hosts. These alternative routes provide added fault tolerance and possibility to share network load. The routing algorithms are based on a graph theory and practical implementations within one administrative domain are based either on distance vectors or more commonly today to a topology and a link state, for example the Open Shortest-Path First (OSPF).
If we include QoS parameters, for example needed bandwidth or delay bounds, the picture changes. We must take those considerations into account when calculating network topology. The ATM Private Network-Network Interface (PNNI)  routing information uses source traffic descriptor to determine which links to include into topology and which not. There can be great number of different topologies depending on requirements so handling of those can be a difficult task.
Another factor where QoS constrains affect on routing are changes in route tables in life time of connection. If the network and the routing algorithm are not stabile, the route may change very often, specially if the network is congested. If routing information is changed after reservation setup there is no resources reserved for this particular connection on new route. For this reason, the RSVP requires that the route for a certain session is fixed: the concept is called as path pinning and it is relied on periodic RSVP Path updates to change reservation to the new route .
The IP and ATM world have one basic difference: the ATM is connection oriented as the IP is connectionless. There are two basic ways to realize IP-over-ATM: using permanent virtual circuits (PVC) which emulate point-to-point links (leased lines) and switched virtual circuits which are set up on-demand. The reservation in ATM is ``hard state'' (active as long as it is not released) while on RSVP the reservation is ``soft state'' (active as long there are periodic updates).
The mapping of Integrated services to ATM service classes is quite straightforward and is presented in Table 3. The ATM traffic descriptors (PCR, SCR, MBS) are set to values based on a peak rate, a bucket depth, a RSpec, and a Receiver TSpec.
|Integrated Service Class||ATM Service Class|
|Guaranteed Service||CBR or rt-VBR|
|Controlled Load||nrt-VBR or ABR (with minimum rate MCR)|
|Best Effort||UBR or ABR|
For the point-to-point links the bandwidth allocation and prioritizing is done by router. In multipoint networks there may be some shared media where each host can send as much data as they want. Some mechanism is needed to make sure that the bandwidth allocations do not exceed available bandwidth in network. This is a task for a bandwidth broker or Subnet Bandwidth Manager (SBM) .
Each (RVSP) request for a bandwidth goes through SBM and if sufficient capacity in the network exists, it grants the request. It does not, however, policy requests in any way, it is just a book keeper.
One of the main problems with any resource reservation technology is burden needed for maintaining a state information for each flow. In some central network nodes the number of simultaneous flows may exceed hundred thousand. If we estimate that each flow lasts for 10 seconds, there comes and goes more than 10,000 flows per second. For a reference, a large telephone exchange can handle up to million BHCA (busy hour call attempts) which equals to few hundred calls per second on average.
The number of flows makes maintaining per flow state information infeasible in core routers. The time needed to look up database entry for 5-tuple in each packet is considerable overhead compared for normal destination address lookup from routing table. The solution is to use a per-packet stateless information.
For the differentiated service approach several requirements were identified and addressed . The key requirements are:
The differentiated service (DS) architecture is presented in Figure 4. The traffic is classified at edges of the network (Figure 5). Each datagram is possibly conditioned and assigned to one of behavior aggregates which are identified by DS codepoints. At the core of the network, the packets are forwarded according to the per-hop behavior (PHB) associated with the DS codepoint.
A customer (possibly other network operator) makes a service level agreement (SLA) with the network operator. The SLA can be either qualitative (``Traffic offered at service level A will be delivered with low latency'') or quantitative (``90% of in profile traffic delivered at service level B will experience no more than 50 ms latency'') .
Based on SLAs the network provider assigns proper service level specifications (SLS) to boundary nodes. The nodes have four components as seen in Figure 5. The meters measure if submitted traffic conforms to a profile. Based on the measurements other components will implement the policing. Markers re-mark traffic: to demote out-of-profile traffic to different PHB, to conform SLS codepoint mutation, and to ensure that only the valid codepoints are used. Shapers delay traffic so that it does not exceed profile and droppers discard non-conforming traffic. 
The per-hop-behavior groups are the actual mechanism to implement needed service differentiation in core networks. There should not be too many PHB groups as it complicates efficient router design . Currently there are proposals for two PHB groups:
Each class is assigned some partition of bandwidth and buffer capacity. One way to use classes is ``Olympic service'': packets are assigned to ``gold'', ``silver'', and ``bronze'' classes. The ``gold'' class has lighter load than the other two classes. The customer may select one of these classes (which each are of of different cost).
In  there are defined some service examples. The codepoints used in the examples are not officially assigned.
The use of the IP Security protocols  causes some problems for both for the RSVP and differentiated service.
If the Encapsulating Security Payload (ESP)  is used, the upper protocol layers are encrypted (discussion about tunneling mode see Section 6.2) and the network nodes cannot know the port numbers or protocols. The RSVP uses port numbers to make difference between different flows between two hosts (for example one flow for a data communication and one for a audio transfer).
As the transport layer is encrypted the network nodes cannot know the ports and thus cannot differentiate between flows requiring real time handling and bulk transfers. If the datagram is only authenticated the port numbers are visible but they are on a different position which may cause performance problems on routers.
This problem was solved by introducing ``virtual destination port'' which is actually the IP SEC Security Parameter Index (SPI). We must then make sure that the flows needing different QoS have a different SPI .
If the services are classified for differentiated services networks based on port numbers , the encryption hides needed information. In this case the end system should be able to tell the network what kind of service each packet needs.
There are three main uses for tunneling: the first is to build (possibly secure) virtual private networks (VPN), the second one is to provide transport for protocols the network between does not support (as currently IPv6). The third use is tunneling the subscriber traffic from the access server to the Internet service provider (ISP). The access server can be located in local telephone exchanges so Internet connections do not reserve circuit switched capacity from the telephone network.
As the original IP packets are encapsulated to IP packets, the port numbers or DS code points are not visible to routing nodes. This problem has been solved for RSVP by using IP-in-UDP encapsulation. The UDP source ports are used to identify individual (or aggregated) flows. The RSVP reservations are tunneled and corresponding reservations are made for the tunnel also.  For the differentiated services the solution is simpler: the DS codepoint is copied to IP datagram which carries the original IP datagram. This way the datagram will receive same service as the original would. The packet reordering may cause problems with some tunneling protocols so packets in same flow should have same DS code.
The well known best effort service is not satisfactory for the real-time applications. The Internet pricing is currently in many cases flat rate: a monthly fee or a fee based on time on-line. The user has no possibility to get a better service even if he is willing to pay more for a premium service.
Currently there are two main efforts to provide control of QoS: the Integrated Services and the Differentiated Services. The first one is based on a resource reservation: the main advantage is possibility to get well defined QoS, the main disadvantage is the need to maintain connection state in all network nodes between end systems. It also needs support from both end systems and from all networks between these two systems to be useful at all.
The Differentiated Services model is based on using per-hop behaviors which are marked as DS code points to IP datagrams. The most important advantage is that the decision at core network node is local both in space and in time which guarantees scalability. It can also deployed step by step and the interoperability is maintained. The disadvantage is that no connection admission control is done which may cause temporary overload situations on low bandwidth connections.
It looks like there are two possible ways to implement QoS: a combination where the diffserv is used in the core networks and RSVP/intserv in access network or diffserv-only network. If the applications do not soon support RSVP, the latter alternative is more probable.