Distributed federative QoS resource management

Abstract

In a distributed multimedia system QoS resources have to be managed carefully to utilize the resource pool in a way that bottlenecks can be avoided. Our key idea is to let the applications participate on the resource management. We propose a distributed architecture with a fine granulated, balanced resource management with explicit QoS characteristics. The architecture is based on a distributed cooperative resource manager which combines both the adaption and reservation principle for guaranteeing QoS. We have designed and implemented a prototype of our federative QoS resource manager (FQRM) in the Java environment.

Introduction

Modern multimedia applications in general have an insatiable demand for resources. Not only the applications exist in a non-cooperative world but also the users want to run their applications with the best possible quality of service (QoS). Resources with a guaranteed QoS, which are used for running multimedia applications, are commonly overloaded [6]. One solution is, of course, to add as much resources as necessary (e.g. better communication links, more processing power, faster hard disks, etc.). This approach has not only the disadvantage that it wastes a lot of resources, but it is actually only meaningful if it is just the number of running applications that has to be increased and the size of needed resources per application is fixed. Otherwise, there is no limitation on the growth of demand on resources.

As a result of the development of powerful graphics and processing devices multimedia computing systems have changed from the control-only approach to the fully integrated approach. Continuous media technology had an influence not only on the communication infrastructure but also on operating systems [8].

A multimedia application assigns different types of system resources for representing a given user QoS. The transformation from the user QoS to the system QoS allows combinations, e.g. a smaller amount of assigned communication resources could be compensated by a larger amount of processing power by using better compression techniques. Our key idea is to let the applications participate in the resource management. The advantage of such an approach is obvious: applications know exactly what they really need and can adapt to changing situations without loss of user-level QoS. For example, if an application knows that the available bandwidth is getting less then it may reduce the size of the video-window or reduce the resolution, or even close certain windows etc., without frustrating the users. If the operating system does this automatically then it may do it in a way which is unacceptable, but applications are supposed to know, which solution is appropriate for their users. However, there are two obvious disadvantages as well: applications must be cooperative and they have to take care of management problems that other systems may solve entirely hidden. For the first objection there is an easy answer: applications will be ready to cooperate, if this reduces their costs. For the second objection, we answer: the participation of the applications must be made very easy — through a simple script language or through a simple API for resource allocation.

Our approach deals with “balancing” resources throughout the whole system. Beyond (the usual) negotiation in the admission phase, also renegotiations take place during sessions. The main goal of this approach is to schedule the limited set of different types of resources, characterized by QoS parameters, in a way that the number of the running and still “satisfied” multimedia applications will be maximized.

Currently most of the communication structures and also operating systems schedule their resources corresponding to the best effort principle, i.e. the scheduler tries its best but provides no guarantees for deadlines. This is principally unsuitable when dealing with QoS resources, where guarantees of availability are basic requirement. Mainly two strategies are applied to cope with this problem:

• The adaption principle [2]: The system components have to be aware of changing parameters and have to adapt to new situations. Adaption can be done at the operating- and communication system, the application or at the user domain. The goal of this approach is to widen the accepted resource space for a given user QoS. The application system is associated with a control system creating the feedback (see Fig. 1). The use of the proper adaption algorithm will influence the overall system performance and a lot of new problems known from control theory arise, e.g. instability.

• The reservation principle: Resources are assigned in advance to applications located at the end of a flow. The strategy is usual in operating (resp. communication) systems supporting real time scheduling. Examples are the SMART real-time-scheduler [6] (resp. isochronous channels in ATM [5]) or IEEE-1394 [3] and the use of RSVP [12]. In contrast to the former principle this technique needs an explicit resource management function which is handled by the operating system or dedicated daemons. Resources are assigned statically, e.g. the route in which bandwidth is guaranteed does not change over a session. Unallocated resources can be used for services with best effort characteristics.

  Since applications are developed under an egocentric view of the world they are not aware of over-reserving bandwidth. For example an MPEG stream has due to the dynamic compression technique a very bursty characteristic [7]. At startup time the application can only estimate the needed resource bandwidth. Cell oriented techniques (like in ATM [5] networks) provide a possibility of dynamic resource consumption even for such cases. Unused resources can be utilized by traditional best effort communication services. However, unused reserved resources cannot be reassigned to other applications.

We examined these two basic principles and combined them in the federative resource management principle. The manager provides on the one side an interface for reservation of resources with guaranteed characteristics. On the other side, it also implements strategies for resolving bottlenecks by employing the adaption principle. In this paper we describe mainly the structure of the system and the areas of operation.

The design principles of our QoS resource management system can be summarized as follows:

• Low implementation costs: The resource manager should incorporate easy-to-implement algorithms and resource models. If adaption to new management strategies is desired, there should not be much effort to do this.

• Easy to integrate — low usage costs: The programmer should not be burdened by a hard-to-understand API. Existing applications should be able to adapt to this new technology easily.

• Efficient communication model: The communication overhead created by the extra resource manager should not stress the network and block valuable resources.

• Fairness: Requests for resources can be affiliated with priorities and sessions of applications therefore can be categorized. The manager should not prefer any application of the same class.

• Fault tolerance: Even if a node in the distributed system fails, the rest of the system should not block.