QoS Management in a Continuous Media Network System - CiteSeerX

QoS Management in a Continuous Media Network System Ivan Chung

Tatsuo Nakajima

Japan Advanced Institute of Science and Technology 15 Asahidai, Tatsunokuchi, Ishikawa, 923-12, JAPAN e-mail:

fivan,[email protected]

Abstract In this paper, we describe the design and implementation of a suite of network protocols on a real time operating system that ensures the QoS (Quality of Service) of continuous media applications. The suite consists of a newly designed transport layer, a network layer that includes ST-II, a reservation-based network protocol, and a data link layer providing network access to ATM and Ethernet interfaces. Working together, these protocols manage QoS dynamically and oers a exible way to utilize network resources. Furthermore, since this new network architecture follows a layered approach, it can adapt easily to dierent types of networking environments.

1 Introduction The QoS (Quality of Service) in computer networks in general refers to service qualities a network must provide to its user during a connection of data transfer. Typical service qualities include throughput and delay and varies from networks to networks. It is common for a user to specify a list containing the minimum QoS values that are deemed acceptable for a particular connection. And to keep users happy, the network should never establish that connection whose minimum QoS values cannot be satis ed. On a higher level, applications look at QoS values differently from computers networks. For example, applications that send and receive video and audio data on a network see QoS values as frame rate and image size. In order for a computer network to understand what kind of services an application is demanding, we must convert application QoS values to network QoS values. This is called QoS mapping, and it is usually performed in the transport layer of the network system, as the transport layer is sandwiched between the application and network layers in the OSI model. In this paper, we will develop a network system to handle video and audio transmissions between applications. To describe this network, we shall use the buzzwords \continuous media communication" or \continuous media network", because video and audio data must be processed continuously by the network to display them without irregular random movement known as jitter. To be consistent, we will call an application that deals with continuous media a \continuous media application". The continuous media network we are developing features NPS-II (Network Protocol Server-II), a protocol server that will ensure QoS when transmitting continuous

media data over the network. NPS-II, when completed, will be an integral part of the RT-Mach operating system that provides QoS-support over ATM and Ethernet to network users transmitting critical real-time data such as video or audio. The background for this research is in section 2, which describes some concepts and terminology used in this research. The design and implementation issues for this network architecture are discussed in section 3, and section 4, respectively. In section 5, this paper concludes with a list of some future research issues. Issues regarding routing, multicast, CPU and buer resource reservations will not be dealt with in this paper. However, our research provides a basic framework to which the above modules can be added conveniently into NPS-II in the future.

2 Background

2.1 Problem Scope

There was a time when memory and hardware were expensive, so most computer systems that were connected to a LAN or WAN just did not have enough network bandwidth or processing power to display continuous media smoothly. Jitter occurred as a result of dropped packets in a congested network or simply because the processing power of the node couldn't keep up. Today, despite the emergence of faster CPUs and high speed networks such as FDDI and ATM, the situation hasn't improved. Jitters still occur and packets still get dropped. The problem, however, has shifted from lack of resources to lack of control. Throwing in more processing power and hardware resources will not help the situation, if there is no systematic control of how much resources should be allocated to each user and how the QoS of each user's process should be managed to use the allocated resources eectively. The lack of resource reservation and QoS management mechanisms in most computer network protocols have made smooth transmission of continuous media dicult. 2.2 Network Systems for Continuous Media

Two notable systems have been designed to provide resource reservation and QoS management for transmission of continuous media over networks. One such system was developed by researchers at CMU called CBSRP (Capacity Based Session Reservation Protocol)[3]. CBSRP's strength lies in its dynamic QoS management, an approach that provides exibility as well as improved network utilization to users (see section 2.3). However, the

lack of a network layer protocol and routing mechanisms in CBSRP limits the system to LAN use. With high speed networks such as FDDI and ATM being employed gradually in WAN (as costs subside), we will need to design a network system that can accommodate WAN continuous media transfers in its framework as well. The other system has been developed by IBM researchers in Europe. Their system, called HeiRAT (Heidelberg Resource Administration Technique), provides various modules to reserve system and network resources as well as manage QoS[5]. Furthermore, HeiRAT uses a network layer protocol called ST-II to provide rate-based

ow control and routing for data transmission, making it a more complete system than CBSRP. Unfortunately, HeiRAT does not provide dynamic QoS control like CBSRP, so network resources will not be utilized optimally. An ideal network architecture would combine dynamic QoS with provisions for a network layer. Such an architecture can utilize network resources optimally and provide transmission services to WAN users and applications as well. 2.3 Dynamic QoS Control

Dynamic QoS is the changing of streams' QoS in accordance to the amount of free resources available. In general, the amount of resources allocated to sustain a stream transmitting continuous media is a function of the QoS parameters speci ed by the user. Since a node supports multiple streams that are independent of each other, the amount of free resources available will vary at each instance in time. Our goal is to utilize free resources as much as possible at all times. Subsequently, at any point if there are unused resources, the system should let the streams in execution take advantage of those resources so they can increase their QoS and complete their jobs ahead of time. On the other hand, if all the available resources have been used by current streams yet there is a new stream pending creation, the system should lower the QoS of all current streams to their minimum QoS if possible. By doing so, hopefully enough resources can be squeezed out from the old streams to create the new stream, yet still guarantee the minimum QoS of existing streams. 2.4 NPS

Since NPS-II will be modi ed from the current version of NPS, we will give a little introduction here. NPS (Network Protocol System) is a real-time network engine running on RT-Mach (Real-time Mach). To ful ll its role as a preemptable and predictable network server, the current NPS is highly integrated with various kernel services - IPC, critical regions and packet queues - to solve the priority inversion problem, hence reduce jitter[2]. Structurally, the current NPS is divided into 4 layers, the Interface layer, the UDP transport layer, IP network layer and the NPS Data-Link layer. The Data-Link layer contains various physical network interfaces drivers such as Ethernet and FDDI. But since IP does not reserve network resources, there is no way for NPS to guarantee data delivery within a certain time frame when a network is congested. We must use a reservation-based protocol in NPS-II to do the job.

2.5 ST-II

NPS-II's network layer will feature ST-II, a reservationbased stream protocol[4]. The rst version, ST, rst appeared in the late 1970s and was used for transmitting voice and video in experiments. With the recent multimedia boom, there are ongoing eorts by the ST Working Group within the Internet Engineering Task Force (IETF) to specify the second version of the protocol, ST-II. Several implementations of ST-II have appeared even though the speci cation is not nished yet . Our research will implement a subset of the protocol (based on the completed part of the speci cation) that mainly has to do with ratebased ow control and connection establishment.

3 Design Issues To manage QoS successfully our network system must be able to do the following: 1. Allow applications to specify QoS parameters explicitly when creating a session for data transmission; 2. Perform QoS Mapping by converting application QoS parameters into network layer QoS parameters; 3. Negotiate QoS demands on the application's behalf, with the local system and the target system; reserve the necessary resources at both systems if negotiation is successful. 4. See that the negotiated QoS demands are satis ed during actual data transmission; 5. Perform admission control to check if enough there are enough resources to satisfy a new request; 6. Perform dynamic QoS management on existing sessions; 7. Regulate and monitor the transmission rates of all sessions to protect network resources from misbehaving users.

We will take a look at how the system architecture and network protocols are designed to satisfy these goals listed above. 3.1 System Architecture

 Continuous media applications reside on the very

top of the system architecture diagram (see Fig. 1).

 Transport layer features a QoS Manager that per-

forms admission control and dynamic QoS management of all sessions. The rest of the module is concerned with QoS mapping, exceptional handling, packet fragmentation and assembly.

 Network layer is where sessions' transmission rates

are monitored by a regulation mechanism. This mechanism protects the network bandwidth from misbehaving sessions that tend to use more resources than they are allowed. Connection management with other hosts is also done here.

 Data link layer contains an NRM ( Network Re-

source Manager) responsible for monitoring the network utilization of the network. The QoS Manager in the transport layer relies on the NRM's information when making decisions in admission control and dynamic QoS management. The rest of the Data link layer is responsible for dealing with the physical layer.

 There are two dierent physical layers in use: Eth-

continuous media application

transport layer QoS Manager

ernet and ATM. The data link layer must deal with each physical layer respectively. To allow the network layer to choose which ever interface it desires, the data link layer must provide interfaces to both physical layers.

 With ATM, the data link layer must deal with ATM

network layer

Adaptation Layers.

data link layer

 In order to monitor resources, the Network Resource Network Resource Manager

physical layer

Figure 1. System Architecture of NPS-II 3.2 Network Protocols for Continuous Media 3.2.1 Data Link Layer and the NRM (Network Resource Manager)

The Network Resource Manager is a module that can actually be placed in either the network or data link layer. We chose to do the latter because the NRM interacts with other modules in the data link layer to monitor network utilization eectively. Monitoring network utilization is a simple but crucial operation. In order for the QoS Manager to perform admission control, the NRM makes use of the utilization information when telling the QoS Manager whether enough resources are available to set up a new session. Dynamic QoS management is also carried out cooperatively between the NRM and the QoS Manager based on the utilization of the network. Measuring the utilization of the network, however, depends on the actual physical layer used. ATM and Ethernet will be used in this research. Hence, for ATM, network resources can be reserved and hence, the network utilization can be measured quite easily. Ethernet would warrant a dierent scheme, such as determining the utilization as a function of the collision rate of the network. When monitoring network utilization, NRM de nes a maximum and a minimum threshold and checks the current utilization against them. If the utilization is approaching minimum, all pending sessions with reasonable QoS are eagerly accepted by the QoS Manager. Also, the NRM tells the QoS Manager to raise the QoS of certain (even maybe all) sessions if it wishes to do so. On the other hand, if the utilization is close to maximum, the QoS Manager receives a message from the NRM to reject any pending session that will run the utilization over the maximum limit if accepted (admission control). Obviously, the NRM will also suggest the QoS Manager to lower the QoS of existing sessions as well. The rest of the data link layer is concerned with modules connecting the network layer with Ethernet and ATM device driver interfaces in the RT-Mach kernel. The most important design issues here are:

Manager will interact with the data link layer often. The data link layer must be designed to handle this sort of interaction.

3.2.2 Network Layer

As a protection against misbehaving sessions that may overrun and monopolize the network bandwidth, a regulation mechanism is used to pace the streams. This mechanism maintains strict control over the average rate of packet transmission, ie. the number of packets that can be sent per unit time. Also, this mechanism carries out bandwidth enforcement by detecting any user who misbehaves by sending too many packets per time interval. Such misbehaving users will be marked and the transport layer protocol will be alerted. We have chosen to add a rate-based control mechanism, similar to Virtual Clock [6] into ST-II to regulate the ows. The second design decision was to adopt a network layer protocol that was capable of reserving network resources. Whether the protocol actually did the allocation was not a concern here as a supporting module could easily do the actual dirty work. All we care is that the network layer protocol we use allows users to specify how much resources they need respectively in a QoS speci cation. Having such a speci cation, the network layer protocol can negotiate connection management issues with the network layer of the target host or any intermediate host or switch in between. The two design decisions taken above has prompted us to consider adopting ST-II in the network layer of NPSII. After all, ST-II provides a FlowSpec to convey stream QoS, and we can easily add a rate-based ow control mechanism to ST-II to monitor ST-II stream trac. Furthermore, as a connection-oriented protocol, ST-II is expected to perform option negotiation (negotiating QoS parameters with peers and target), an operation that is normally done in the transport layer; doing so will reduce the complexity of the transport layer protocol. However, ST-II is unreliable even though it is a connection-oriented protocol. ST-II does nothing much to recover lost packets or garbled packets since it assumes that it is permissible to incur a small number of errors in multimedia streams, based on the fact that losing a packet here and there will not aect the quality of video or audio playback severely. 3.2.3 Transport Layer and the QoS Manager

In the transport layer, interface calls are provided to the continuous media applications that intend to use the network. They are all listed in Table 1.

call

open() close() send() receive()

function

Open a connection and reserve resources. Close a connection and release resources. Send data to target host. Receive data from sender.

Table 1. Application Programming Interface

The most important module in the transport layer is the QoS Manager. This module performs admission control on all pending session requests as well as managing the QoS of existing streams dynamically. As mentioned in section 3.2.1, the QoS Manager bases all its admission control and dynamic QoS decisions on the utilization information it receives from the NRM module in the data link layer. And when a QoS Manager initiates a QoS change to an existing session, it must notify the application that owns the session via an upcall function called notify_qos_change_request(). There are two other upcall functions initiated by the rest of the transport layer independent of the QoS Manager. One is a function to signal to the application that a QoS violation has occurred (notify_qos_violate()). A QoS violation can be a deadline miss or a dropped packet that never reached its destination. The other upcall function is for the transport layer to warn misbehaving applications that have been caught by the regulation mechanism in the network layer (notify_qos_overrun()). call

notify qos change request() notify qos violate() notify qos overrun()

origin

QoS Manager Transport Layer Transport Layer

Table 2. Upcall Functions in the Transport Layer

In our system, applications communicate to the lower layers via the transport layer interface so the interface must be designed to accommodate QoS parameters for video and audio streams (ie. frames per second). However, since the network layer sees data as packets and are more concerned with throughput (ie. packets per second), the transport layer must perform QoS mapping to bridge the gap between the application layer and the network layer. Last but not least, the transport layer should be geared towards video and audio multimedia applications, so it must be able to fragmentize and assemble continuous media data in real time. Performance is crucial here.

4 Conclusion and Future Plans The network architecture discussed by this paper will be implemented on RT-Mach based on Network Protocol Server (NPS). NPS is a protocol-independent server that relies on the real time kernel to provide priority-inversionfree scheduling. By using the framework provided by NPS, our network architecture can take advantage of the real time bene ts provided by the RT-Mach kernel. The network layer of the proposed architecture will most likely be implemented as a subset of ST-II, if not another rate-based reservation protocol, to harness the

resource reservation capabilities provided by the ATM switches[1]. Speaking of hardware, RT-Mach is running on Gateway 2000 machines featuring Intel 486, 66MHz CPU. As for ATM, two Fore ATM switches are used in this research. One of the most important aspects of our system is that it provides the basic framework for which the following modules can be easily added in the future: 

Reservation of CPU and local resources: To truly guarantee QoS for streams we must reserve all resources that aect QoS. Thus not only network resources, but local resources such as CPU utilization and buer space must be reserved as well. The QoS Manager in the transport layer can be modi ed easily to do the job.



Routing: For our system to be functional in a WAN network, a routing module in ST-II is necessary to setup and maintain streams in a large network. If streams break down somewhere in the network, the routing module will be responsible for looking for new routes to recover the stream.

References [1] Olof Hagsand and Stephen Pink. ATM as a Link in an ST-2 Internet. In Proc. of the 4th International

Workshop On Network and Operating System Support for Digital Audio and Video

, 1993.

[2] Tatsuo Nakajima and Hideyuki Tokuda. Design and Implementation of a User-level Real-Time Network Engine. Technical Report IS RR 94 14S, School of Information Science, Japan Advanced Institute of Science and Technology, 1994. [3] Hideyuki Tokuda, Yoshito Tobe, Stephen T.-C. Chou, and Jose M. F. Moura. Continuous Media Communication with Dynamic QOS Control Using ARTS with an FDDI Network. In Proceedings of the ACM SIGCOMM, 1992. [4] Ed. C. Topolcic. Experimental Internet Stream Protocol, Version 2 (ST-II). Network Working Group Request for Comments 1190 (RFC 1190), Oct. 1990. [5] Carsten Vogt, Ralf Herrtwich, and Ramesh Nagarajan. The Heidelberg Resource and Administration Technique, Design Philosophy and Goals. Technical Report 43.9213, IBM European Networking Center, 1992. [6] Lixia Zhang. A New Architecture for Packet Switching Network Protocols. PhD thesis, Massachussets Institute of Technology, 1989.