Software Quality Assurance Plan / 1

Resource Reservation and
Service Quality

Version 3.0

13.12.99

Resource Reservation and Service Quality- 1–

Version history

Version / Date / Author(s) / Description
< 1.0 / 29.10.98 / Jan Lucenius
1.0 / 11.12.98 / Jan Lucenius
1.1 / 30.12.98 / Jan Lucenius / minor changes
1.2 / 15.1.99 / Jan Lucenius / minor changes
2.0 / 11.3.99 / Jan Lucenius / Structure changed – still not final
2.1 / Jan Lucenius / minor changes
2.2 / 20.10.99 / Jan Lucenius and Juha Koivisto / structural changes
2.3 / 27.10.99 / Jan Lucenius and Juha Koivisto / spelling corrections etc.
2.4 / 01.11.99 / Diffserv chapter reorganised
2.5 / ...9.12.99 / Jan Lucenius and Juha Koivisto / Text about test results and QoS API included
2.6 / 10.12.99 / Jan Lucenius and Juha Koivisto / Chapter about experiments and points to study updated
3.0 / 13.12.99 / Jan Lucenius and Juha Koivisto / Minor editorial changes. Final deliverable.

Inspection status

Accepted by / Signature / Date

Contact information

Jan Lucenius

VTT Information Technology

P.O. Box 1202, FIN-02044 VTT, Finland

Street Address: Otakaari 7 B, Espoo

Tel. +358 9 4561, fax +358 9 456 7013

Email:

Web:

Copyright © VTT Information Technology 1998. All rights reserved.

The information in this document is subject to change without notice and does not represent a commitment on the part of VTT Information Technology.

End of editable fields

Abstract

The steadily increasing use of internet is reflected in varying quality of service seen from the user point-of-view. The communication has slowed down to a part of the capasity of the communication channel and especially real-time communication may become unintelligible. Another trend is that internet provision is becoming more commercial, instead of resource equally available for all almost for free. For those reasons, different scenarios to provide quality of service or at least different service classes to the internet have been developed. These developments are here studied, particularly the use of RSVP, but also alternative or complementary scenarios. The first chapter of this report is an introduction to the problem and possible solutions. After that, the Intserv framework with use of RSVP is studied, especially how this concept performs over different kinds of sub-networks The pros and cons with RSVP are outlined. After that, the Diffserv concept and use of TOS bits are outlined. End-to-end networks with both diffserv and intserv regions are studied in chapter 4, which also gives some points, on how these two approaches should be combined. Next, alternative solutions which may improve QoS, but are outside the scope of the previous concepts, are outlined. Finally, a test scenario for MOSES and points for further study are specified.

Resource Reservation and Service Quality- 1–

Table of Contents

1 Introduction......

1.1Purpose of this report......

1.2QoS in Internet......

1.2.1What is QoS?......

1.2.2Classification of applications / traffic......

1.2.3Delay......

1.2.4Jitter and Bandwidth......

1.2.5Data loss......

1.3Providing better quality of service into internet......

1.3.1Integrated services......

1.3.2RSVP......

1.3.3Priority based QoS......

1.3.4Diffserv......

1.3.5DRP......

1.3.6Process priorities in the user's workstation......

1.3.7AREQUIPA......

1.3.8Switching......

1.3.9Alternative approaches......

2 RSVP and Intserv......

2.1Description of RSVP......

2.1.1Intserv......

2.2Service commitments......

2.2.1Guaranteed service......

2.2.2Controlled load service......

2.2.3Implementation of traffic control......

2.2.4RSVP and charging......

2.3LANs[1]......

2.3.1Ethernet......

2.3.2FDDI, Token ring......

2.4Frame Relay, SDMS [1]......

2.5ATM [3]......

2.5.1IPSOFACTO......

2.5.2Tag switching [1]......

2.5.3NetFlow switching [1]......

2.6Mobile connections......

2.6.1Mobile IP and RSVP......

2.7Slow connections (Dial-up, PPP)......

2.8Reservation styles and scalability of RSVP......

2.8.1Reservation styles......

2.9Discussion......

3 Diffserv......

3.1Diffserv......

3.2Use of TOS field in RFC1349 and Mgen......

3.3Diffserv Code points......

3.4Assured forwarding......

3.5Expedited forwarding......

3.6Interoperability PHB group......

3.7Feedback in Diffserv......

3.8Bandwidth brokers......

3.9SIMA......

4 Intserv and Diffserv combined......

4.1Sample Network with Intserv and Diffserv Regions [5]......

4.2QoS API......

4.3Bandwidth Broker......

5 Points to study / test setup......

5.1Linux traffic control......

5.2Process priorities......

5.3Router priorities......

5.4Intserv......

5.5Diffserv......

5.6Different methods combined and compared......

6 Summary / Conclusions......

7 References......

1Introduction

Networks are steadily becoming faster and new techniques are evolving. At the same time also the amount of users in internet increases and ever faster computers also utilize the networks more. The increased load on the network then "eats up" the advantage of the faster technology. This causes long-term variations in the quality experienced by the users. Additionally there are of course short-term variations. The requirement to introduce different service quality or at least different service classes also on internet connections rises both from commercial viewpoint, i.e. that the load on the network should be more reflected in the charging and that some user's traffic could be privilegied according to how much they pay, and from the needs of the users to ensure good quality for traffic of critical applications. On the other hand, driven to eccess this may also be the end of internet as a "free data highway" for everybody, which certainly is one of the main IT accelerator.

1.1Purpose of this report

The aim of this report is to

  • give an overview on different techniques to provide QoS for IP connections
  • study when resource reservation is useful, particularly when the connection spans different kinds of sub-networks
  • specify possible tests setups for the MOSES project and possible future projects.

As the IP test network in VTT/TTE as well as the Mediapoli network will be built using Cabletron Smartswitch technology, and the existing internal ATM network in VTT/TTE uses FORE switches, etc. references especially to these equipment and their management software are inserted at some places in the text. However this does not mean that FORE or ATM based approaches at all really would be implemented, at least not in the MOSES project.

1.2QoS in Internet

1.2.1What is QoS?

Quality certainly means different things to different people. In the case of communication the definition of QoS also depends on where the viewpoint is focused. For the information consumer, the point is to receive the information he wants to access correctly and/or intelligibly and as fast as possible, or at the correct time, depending on the application. Another point of quality is also that connections can be established as fast and reliably as expected.

All bits transferred are not equally important. For example a few bits answering the question "are you alive" or about some business worth millions are considerably more valuable than an email message in general or the bits in a video stream. In general, the more bits are transferred, the less we want to pay per bit. Still, the purely technical requirements on the transfer channel for the video stream are considerably higher.

The quality requirements of the transferred information are reflected on the quality requirements on the communication channel, or reverse, constraints in the communication channel result in reduced quality on the received information or in some cases, that some information cannot be transferred at all. The bottlenecks may of course also be in the sender's and receiver's servers/terminals themselves, and it may be difficult to tell the reason for bad quality of information. This study focuses though on the quality parameters of the network, like bandwidth, delay, packet loss probability etc. Of course there may be other views on quality of service which are more or less outside the scope of this report.

1.2.2Classification of applications / traffic

Roughly applications can be divided into real-time and non-real-time (data) applications. Non-real-time applications (e.g. ftp) are typically not very sensitive to delay but require error-free transfer. Usually TCP with its resending mechanism takes care of that. When transferring huge files, the available bandwidth should also be utilized as well as possible. With typical real-time applications the situation is reversed. Some erroneous or lost data may be tolerated. There are different categories of real-time applications regarding their sensitivity to delay, jitter and bandwidth. Those parameters are studied further below.

The communication configuration (point-to-point, multicast, multipoint-to-multipoint, etc.) will also have an impact on the quality requirements. Especially non-realtime communication may also be of connectionless type, consist of (rather short) datagrams, like e.g. http, or be more connection oriented, like telnet or ftp. The division between connectionless and connection oriented communication is not very clear, as it varies from layer to layer. However, it is clear that the quality of service requirements are different and perhaps more critical for hugh stream-like transfers than for short messages transferred at random from here and there. But even in transaction processing, where short messages are sent in both directions, delays may be quite critical. Another, maybe less important classification criteria is whether the communication is sender or receiver initiated. Such aspects may have an impact on how the required service quality can be provided by the network.

Real-time communication, which generally means audio and/or video may be divided into playback applications and interactive applications. Depending on the coding, the applications may also require an output at fixed bit rate or the bit-rate may vary.

The applications in Integrated Services architecture [22] are divided into real-time applications and elastic applications. Elastic applications are the typical ones for internet: Telnet, FTP, X etc. . Real-time applications, in turn are described as either intolerant or tolerant, depending on their sensitivity to loss of fidelity.

1.2.3Delay

Delay means here the overall delay (latency) between the retrieving/generation of the information at the sender's side and the storing or reproducing of it at the receiver's side. Totally it includes such as encoding delays or fetching delays (depending on whether the information was stored in advance), transferring delay (through the whole path) and decoding delay.

If the maximum delay was known in advance, all packets could be buffered, and the playback point (delay between the sent packet and the replayed one) of the application set to exactly the maximum delay so no packets would be late or lost. However, a trade-off between interactivity and playback quality has to be considered in determining the playback point. For interactive communication like in an audio conference, the total delay should not exceed 0.25 s. [1]

The absolute delay doesn't matter in playback applications, where the roles of sender and receiver are fixed, for example in a TV transmission. Some video tools support this distinction and allow the user to switch between interactive mode and lecture mode.

1.2.4Jitter and Bandwidth

Jitter is specified as the variation in delay between different information packets.

Jitter and bandwidth are two quality of service (QoS) parameters that need to be controlled to support QoS for playback applications. Enough bandwidth must be available on the path for the average transmit rate plus a little extra so bursts can be cleared quickly. If the bandwidth is not sufficient, packets are dropped as soon as the queuing capacity is exhausted.

In playback applications all incoming data is buffered to remove jitter. The signal is then replayed at some designated playback point. Well-known playback applications are the video tool vic and the audio tool vat. Adaptive applications move the playback point so that the signal is replayed as soon as possible while the data loss rate is acceptable. Thus, adaptive playback applications work well on moderately loaded datagram networks.

The bandwidth requirement may not be fixed, but some "rate-adaptive" playback applications may change their coding scheme according to network service available. Applications like CU-SeeMe and RealPlayer can retrieve both intelligible audio and video even at modem speed. RealPlayer sites often provide different streams for different speeds.

1.2.5Data loss

In some cases buffering according to the worst case delay may also imply low network utilization [22]. If the application is tolerant to some packet loss, there is then a trade-off between network utilization, quality and delay.

If the net is heavily loaded, congestion may result, leading to jitter and packet loss. At certain times of the day, some MBone audio multicasts are unintelligible because of more than 30% packet loss [1].

1.3Providing better quality of service into internet

The internet spans over subnetworks using different technologies. The performance of the data transfer depends much on how the different flows are handled within these networks, e.g. access mechanisms, queueing mechanisms etc. used. A simple or even complicated approach for end-to-end QoS does not help alone. Even these approaches are not yet ready. This report gives an overview but can naturally not answer all questions, the research topic is nearly endless.

1.3.1Integrated services

The original internet service model is very simple and it does not provide any support for quality of service (QoS) or bandwidth sharing in the network. The Integrated Services, described in RFC 1633 [22] proposes to extend the service model with two additional categories of service: guaranteed and controlled load in addition to the traditional best effort service, in order to support also real-time and other performance critical applications.

1.3.2RSVP

Resource ReSerVation Protocol (RSVP) , described in RFC 2205 [8] is a part of this concept. "The RSVP protocol is used by a host to request specific qualities of service from the network for particular application data streams or flows. RSVP is also used by routers to deliver quality-of-service (QoS) requests to all nodes along the path(s) of the flows and to establish and maintain state to provide the requested service." RSVP requests will result in resources being reserved in each node along the data path, if the nodes can handle reservations, and the resources are available, of course.

1.3.3Priority based QoS

Another approach to implement QoS, is to use priorities alone, especially if guarantees are not required.

In internet routers (here the Cabletron SmartSwitch Router is used as example [35]) QoS policies can be set according to the following parameters:

  • Layer 2 (bridging layer)
  • MAC addresses (source and destination)
  • VLAN ID
  • The priorities (7 levels) can be set on specific incoming ports.
  • Layers 3 (IP)
  • IP addresses (source and destination)
  • Type of service (TOS)
  • incoming interface
  • Layer 4
  • UDP/TCP port (source and destination)
  • protocol (TCP or UDP)

In Cabletron SmartSwitch Routers (SSR) four priority queues are implemented: control, high, medium and low. Priority scheduling can be either strict (default) where higher priority throughput is assured at the expense of lower ones, or weighted fair queuing, where the throughput for all four priorities is distributed based on percentages.

The UDP/TCP port identifies the application and is thus more usable for QoS classification than for example address based policies. With the exception of TOS, the other parameters would assume that applications that require certain QoS are always run from the same addresses. It is possible to request the administrator to adjust the priorities for specific address, TCP/UDP port or TOS settings. This, however, seems as a very "primitive" approach.

1.3.4Diffserv

Diffserv [41, 5] is another concept aimed to differentiate traffic in internet. It does not require end-to-end signalling. In the differentiated services traffic entering a network is classified and possibly conditioned at the boundaries of the network, and assigned to different classes or behaviour aggregates. Each behaviour aggregate is identified by a single DS codepoint, i.e. value of the TOS field in the IP header. Within the core of the network, packets are forwarded according to the per-hop behaviour (PHB) associated with the DS codepoint.

According to the Diffserv architecture [41] services can be implemented through the following components:

  • packet classification at the edge of the stub Diffserv networks;
  • packet marking or packet re-marking at network boundaries (the DS -differentiated services – field is used for the service identification);
  • packet forwarding inside a given Diffserv domain according to the current content of the DS;
  • traffic conditioning at the network boundaries according to the requirements of each service, e.g. monitoring, policing and shaping.

There are still technical problems with DS bits ( TOS bits). First, they are handled differently in different networks, depending on which if any Diffserv approach is used and even on choices of the specific ISP. For the second, current applications cannot set the TOS bits. Interfaces for setting TOS bits are available for Linux [51] and in Microsoft Windows systems. In Windows 2000 the GQoS API is included [52], for Windows 95 and NT4, there is the QoS API by Intel available for Winsock 2 [53].

1.3.5DRP

Dynamic Reservation Protocol (DRP) is another protocol for the same purpose as RSVP. The main difference is that DRP is sender based whereas RSVP is receiver based. DRP is on development stage, i.e. implementations do not yet exist, at least not available in public.

1.3.6Process priorities in the user's workstation

In MOSES project it has also been studied whether flows could be prioritized in the user's workstation in the case where there are two or more simultaneous information flows. If the reception of these flows are handled by different software programs, the easiest way is to adjust the priorities of the corresponding processes. When fewer TCP acknowledgements are sent from the slower process, this should cause the sender to slow down. In the MOSES tests, the difference was clearly noticeable only when additional load was put on the processor. In that case, contradictory to what one would expect (Juha's paradox), the quality of the higher prioritized flow was considerably improved on the cost of the other flow [54].

1.3.7AREQUIPA

Application REQusted IP over ATM [17] specifies a method for allowing ATM-attached hosts that have direct ATM connectivity to set up end-to-end IP over ATM. This allows the requesting applications to benefit from ATM's ability to guarantee the quality of service (QoS). Arequipa can be used to implement integrated services (INTSERV) over ATM link layers.

1.3.8Switching

Internetworking vendors have announced several new routing solutions that combine network layer routing with link layer switching. Decisions are then made per flow, not per packet, and most network layer processing can be eliminated. Promising approaches are NEC's IPSOFACTO, Ipsilon Networks' IP Switching as well as Cisco Systems' Tag Switching and NetFlow Switching.