More Quality for Services in Internet

by Juha Koivisto

Internet traffic consists of packets. How well the packets flow can be characterized by Quality of Service (QoS) parameters. Several approaches to provide better service for selected applications have been defined. A research team at VTT Information Technology is building test networks to evaluate QoS technologies in various configurations and combinations. Particularly interesting are configurations where QoS support is available only in very limited parts of the network.

Internet traffic consists of packets. These Internet Protocol (IP) packets carry all the data of, for instance, Web, e-mail and IP phone applications. How well the packets flow can be characterized by Quality of Service (QoS) parameters. QoS parameters include bandwidth (bits/second), average delay (transmission time from sender to receiver), delay variation, packet loss rate, and error probability. Which parameters are the most important depends on the applications. WWW users want as broad bandwidth and low packet loss probability as possible in order to shorten download times. Users of interactive voice applications cannot take advantage of the bandwidth exceeding a certain limit, but they find short delays important. In general, real-time applications are more sensitive to QoS than other applications.

When no special actions are taken, IP packets are transmitted as fast as the bandwidth and load on the network permit. However, this best-effort service is not always sufficient. Users want better quality for important applications. They are even ready to pay higher prices to guarantee the smooth operation of critical applications. Therefore, several approaches to provide better service for selected applications have been defined:

• Network managers may configure routers to favour certain applications, workstations or sub-networks. The routers set priorities based on the addresses and port numbers of the senders and receivers. Such priorities tend to be fairly static.
• Applications may categorize IP packets into different classes. Then the network knows which packets are, for example, less important and drops them in overload cases. This kind of differentiation of services does not require end-to-end signalling. However, there is no general agreement about the exact meaning of the traffic classes.
• Resources may be reserved in advance through, for instance, the Resource Reservation Protocol. This way, some applications can get guaranteed QoS, which is independent of the load other users put on the network. However, establishing and maintaining such reservations is complex, and classifying the packets is heavy for network components. This is why resource reservations are usually not supported. Before resources can be reserved, it must be decided who is allowed to make the reservations, and who is going to pay for them, etc.
• Smart applications that adapt to available QoS can improve perceived service quality. For instance, an adaptive video encoder may decrease resolution and send fewer bits per second when the network is heavily loaded. Adaptive applications need to get feedback about the actual QoS.
• The network may be enhanced to provide more bandwidth, or separate networks may be used for critical applications. This may be the simplest but not necessarily the cheapest approach.

Internet traffic between two users in different organizations goes through several administrative domains. A combination of various approaches can be used to improve QoS. For example, resource reservation in an access network can be combined with priorities in the core network. It is not necessary to control QoS on all the nodes on the path from sender to receiver, but it is important to control the bottleneck of the connection. We are building test networks to evaluate QoS technologies in various configurations and combinations. The goal is to find out when it is worthwhile to use QoS mechanisms.

One problem with many QoS mechanisms is that they require extra network infrastructure, modifications to protocols, or co-operation between the sending and receiving applications. Often such an infrastructure is not available, or end-users are not allowed to dynamically configure it. However, there are also simple mechanisms that set very little requirements on the environment. One example is the process-priority-based method that was developed in the Moses project. The method slows down selected applications by reducing the processor time they get. Through the properties of the Transmission Control Protocol (TCP), this will eventually slow down the sending rate on the other end and leave more bandwidth for critical applications. This method does not require any extra support from the network or the sending end or any modifications to existing applications and it gives a larger share of the limited bandwidth to important applications. The solution is useful when no other differentiation mechanism is available and the network bottleneck is not loaded by other users. This situation is quite common with slow wireless and modem access links. For example, a user may want to give a larger share of the access network capacity to an interactive voice application, and less capacity to WWW downloading.

This work is part of the Moses project. Other research topics in Moses include mobility support technologies on network and application layers, and communi-cation software development methods. Moses is a co-operation project between VTT, Lappeenranta University of Technology, HPY Research, Nokia Research Center, and Tekes (the National Technology Agency).

Please contact:
Juha Koivisto - VTT Information
Technology
Tel: +358 9 456 5664
E-mail: juha.koivisto@vtt.fi