published in: Second Workshop on Protocols for Multimedia Systems, PROMS95, Salzburg Austria, October 1995

Application Requirements and QoS Negotiation in Multimedia Systems

Thomas Plagemann, Knut A. Sthre, and Vera Goebel University of Oslo, Center for Technology at Kjeller (UNIK) Granaveien 33, P.O. Box 70, N-2007 Kjeller {plagemann, knutas, goebel}@unik.no

Abstract
The Quality of Service (QoS) concept is of central importance in the context of communication protocols for multimedia systems. Generally, multimedia systems comprise the following functional units: networks, end-to-end protocols, data management systems, applications, human-computer interfaces, and operating systems. Obviously, the entire system is influencing QoS that is visible to human users at the human computer interface. With respect to application requirements and QoS negotiation, this complex system has to be partitioned into two parts: (1) user, HCI, and application which determine application requirements; and (2) communication system, data management system, and operating system that realize a certain QoS. We propose a specification method for application requirements as a Vector Maximum Problem (VMP). Such specification enables the platform related part of the multimedia system to decide on resource usage. Thus, applications do not have to consider available resources, are independent of particular environments, and resource utilization can be optimized.

1 Introduction
It is commonly accepted, that the Quality of Service (QoS) concept is of central importance for multimedia systems, even if there is no commonly accepted denition of QoS. Our understanding of QoS in multimedia systems is based on the QoS denition from Vogel et al. [56]: Quality of service represents the set of those quantitative and qualitative characteristics of a distributed multimedia system that are necessary to achieve the required functionality of an application. From the communications point of view, the main concern is how to support the various QoS requirements by (new) protocols. Within the last years, it was recognized that protocols are not able to offer end-to-end guarantees for QoS, even if they are placed on top of networks that support QoS guarantees, like ATM. Consequently, research on QoS issues was extended to additionally consider operating system support for multimedia protocols, for example [6], [22], and [39]. However, with respect to QoS in multimedia systems it is necessary to consider more than communication system and operating system, because most multimedia systems do not only manipulate and transmit multimedia data. Additionally, they store and retrieve multimedia data, and present it in a proper way to the user. In general, we can identify the following functional units of multimedia systems: networks that connect endsystems, end-to-end protocols that are handled by endsystems, data management systems that comprise a repository of functions to store, retrieve, and change persistent data (e.g., le system, or database system), applications that are written to solve certain problems, human-computer-interfaces (HCIs) through which users and multimedia systems communicate, and operating systems on which all elements of multimedia systems - except networks - are based. Human users recognize QoS at the HCI. Naturally, human users desire QoS from the multimedia system, that satises their needs and preferences. User needs and preferences form together with application characteristics, the so-called application requirements. Application requirements related QoS negotiation has to be performed between the two following parts of multimedia systems:

Application related part including users, HCIs, and applications, that determine application requirements and request a corresponding QoS from the multimedia system.

Platform related part representing a collection of generic functional units, including networks, end-to-end protocols, data management systems, and operating systems. These functional units realize QoS by mapping requirements onto internal functionality and reserving resources (e.g., CPU time, main memory, disk I/O bandwidth, or network bandwidth).

Application requirements and QoS negotiation play an important role in multimedia systems, because they glue these two complex and different worlds together. Design and implementation of the application related part has to reect results from requirements engineering, computer supported collaborative work (CSCW), user modeling, cognitive psychology, ergonomics, and sociology. In contrast to this application related part, the platform related part consists of a collection of systems. Communication systems (i.e., networks and end-to-end protocols), data management systems, and operating systems are generic units that are used as platform for various applications. Obviously, QoS negotiation between application and platform related part should lead to a good QoS contract, that is characterized by a minimal distance between application requirements and negotiated QoS. On the one hand, users are often not able to specify their requirements and they are often contradicting, like high quality and low costs. On the other hand, the extend to which application requirements could be fullled mainly depends on the available resources of the multimedia system. Only the functional units of the platform related part know about available resources. In order to properly glue these two parts together, a specication method for application requirements and an approach for QoS negotiation is needed, that support:

Specication: users, HCIs, and applications should be able to specify their requirements in user friendly and application related terms, like video frame rate, instead of system related terms, like megabit per second. Furthermore, it should be possible to explicitly express contradicting requirements with the specication method. Abstraction: the application related part must not know and must not care about internals of the platform related part, like available resources. Optimization: QoS negotiation should directly lead to a good contract with optimal resource utilization and optimal user support.

In this paper, we study the relationship between a single user and multimedia system, respectively between application related and platform related part, with respect to application requirements and QoS negotiation. Aspects of groups of users are outside the scope of this paper. However, different application requirements from group members in collaborative applications might often be combined to a common application requirement. Furthermore, in distributional services (e.g., television broadcasting) each receiver might perform QoS negotiation with the system. In such situations, our specication method and QoS negotiation approach can be applied. For more complex group scenarios, only the QoS negotiation approach has to be extended. The remainder of this paper is structured as follows: chapter 2 gives an overview on QoS issues. In chapter 3, we analyze application requirements and QoS negotiation with respect to entire multimedia systems. An exemplied discussion of how to use application requirements can be found in chapter 4. In chapter 5, we consider the problem of QoS negotiation as a decision making problem and propose a specication method for application requirements and an approach for QoS negotiation which supports the necessary specication, abstraction, and optimization. The concluding chapter 6 gives a summary of this paper and outlines implications on future multimedia protocols.

2 An Overview on QoS Issues

Application requirements and QoS negotiation cannot be seen isolated from the following QoS issues: QoS specication, semantics of QoS, and how to realize and enforce QoS. The following sections give a brief overview of these issues. 2.1 QoS Specication QoS is usually expressed as a set of pairs, called tuples, which consist of a parameter and a value. Generally, there are two approaches to quantify QoS parameters. The service user species either a target value [27], [12] or a target range [54], [18], [32] for each QoS parameter. Application layer QoS parameters have been discussed in [38] and transport layer QoS parameters have been discussed in [8] and [37]. The concept of streams is used in Cinema [2]. A stream type determines parameters and values that can be used for QoS specication. Values can be a list of discrete values or a value within a given range. A stream type hierarchy allows the denition of stream types that have the same parameters, but with different sets of possible values. Another

approach is the use of application classes to facilitate QoS specication. Schill et al. dene in [49] four QoS classes that can automatically be mapped onto QoS parameters. These classes divide application requirements into reliable, unreliable, time-dependent, and time-independent aspects. In [9] application level QoS specications take the form of channel types that encapsulate precongured QoS specications for commonly used parameters. The application classes isochronous, burst, and low delay are introduced in [22]. 2.2 QoS Negotiation The goal of QoS negotiation is to agree upon QoS parameters that satisfy service user(s) and service provider. Depending on the scheme used, the negotiation of QoS involves two or three entities, the calling service user, the service provider, and the called service user. Three basic negotiation schemes can be distinguished [18]:

Triangular negotiation: involves the calling service user, service provider, and called service user. The calling service user passes a QoS specication to the service provider, which may downgrade the values of the QoS parameters. The resulting QoS specication is passed to the called service user, which in turn may also weaken the QoS parameters. This nal QoS specication is returned to the calling service user. The service provider as well as called service user may reject the request. This scheme is further subdivided into the following three kinds of negotiations: - Information exchange, where the calling user introduces in the request primitive the value of a QoS parameter. For example, the OSI transport protocol TP4 [27] uses this scheme. - Bounded target, where the calling user introduces two values in the request primitive, the target and the lowest quality acceptable. The Experimental Internet Stream Protocol (ST-II) [55] uses this scheme. - Contractual value, where the calling user introduces two values in the request primitive, the minimum requested value and the bound for strengthening it. Bilateral negotiation: takes place between the service users. The service provider is not allowed to change the QoS specication. However, service provider as well as called service user may reject the request. Unilateral negotiation: The calling service user proposes a QoS specication that cannot be changed by the service provider or called service user. The unilateral negotiation represents a take it or leave it approach, because the request may only be accepted or rejected.

The connection request is rejected if no common agreement upon QoS is found. The service provider or called service user should provide the reason for rejection and perhaps additional information to the calling service user so that the request can be modied and resubmitted (with a higher probability of success) or cancelled. However, this information must be considered as having limited validity in time, because the amount of available resources might be changing very quickly. Therefore, it is not completely reliable for selecting a particular QoS [20]. Consequently, multiple information exchanges between service user(s) and service provider might be necessary to nd a satisfying QoS which can be supported. Furthermore, a QoS contract might be changed (i.e., renegotiated) during a sessions lifetime. For example, a QoS requirement may change during an application session due to changed user requirements or the fact that the negotiated parameters cannot be maintained due to network congestion. A general approach for QoS negotiation and renegotiation is discussed in [33]. 2.3 Semantics of QoS - Degree of Commitment The semantics of QoS parameters are given by the degree of commitment of the service provider. Generally, there are two extreme QoS semantics [18]:

Best-effort QoS: represent the weakest degree of commitment. All parties use their best efforts to meet the requested QoS. However, there is no guarantee that the QoS will in fact be provided; and it does not require monitoring or any remedial action should the requested QoS not be achieved [28]. In other words, the service provider has no obligation to maintain the negotiated QoS. For example, the OSI transport protocol TP4 [27] supports best-effort QoS. Guaranteed QoS: the requested QoS is guaranteed from the service provider and supported through resource allocation. No monitoring is required. For example, the Experimental Internet Stream Protocol (ST-II) [55] supports guaranteed QoS.

Recent approaches introduce new QoS semantics with a degree of commitment of the service provider in between best-effort and guaranteed QoS. The Quality of Service - Architecture (QoS-A) [6], [7] refers to such a QoS semantic as best-t QoS, and OSI 95 [18] denes compulsory QoS and threshold QoS as follows:

Compulsory QoS: the requested QoS is guaranteed from the service provider and supported through resource allocation and monitoring. The service provider will not offer the service unless it can be maintained at the target operating level and it aborts the connection if the requested QoS cannot be provided. Threshold QoS: the service provider noties the service user(s) when it discovers that it cannot achieve the selected values, instead of aborting the connection.

2.4 QoS Realization and Enforcement After specifying the requirements of service users and QoS negotiation, the service provider has to perform specic tasks in order to realize and enforce the requested QoS. A historical view on the approaches can be split up into several phases:

No support, only denition: at rst, the goal of the communication service was the error free delivery of data. In the OSI reference model, QoS parameters such as transit delay and throughput were dened. However, no monitoring were dened, hence a best-effort semantics. Monitoring: with stronger semantics such as compulsory QoS, threshold QoS (e.g., in OSI 95 [17]), and guaranteed QoS, monitoring is required. Chen et al. [11] describe an in-service monitoring for ATM networks to measure end-to-end QoS as it is experienced by the ATM service users. Simoni et al. [50] identify QoS monitoring as network management task and dene four abstract task levels for QoS management. Error and failure related monitoring of links is discussed in [30] and [51]. Reservation of network resources: to guarantee a specic QoS for a connection, resources have to be reserved in the network. Therefore, new standards for high-speed networks like FDDI-II and ATM offer support for resource reservation. In the network layer, the Internet Stream Protocol (ST-II) [55] and the Resource Reservation Protocol (RSVP) [59] are probably the most prominent protocols that reserve resources for so-called ows (i.e., network connections). Adaptation of protocol functionality: the insight that end-to-end protocols represent the performance bottlenecks in the communications and that traditional end-to-end protocols are not able to support the various multimedia requirements resulted in several proposals for exible protocols. Main goal of exible approaches is to increase protocol performance by decreasing its complexity while offering the requested QoS. Flexible lightweight (transport) protocols such as XTPX [36], HSTP [13], and TP++ [19] enable the transport user to select a retransmission strategy. The systems HOPS [23] and Virtual Protocols [41] allow to combine ne granular building blocks to protocols that comprise the functionality of the OSI layers three up to seven. ADAPTIVE [5], FCSS ([53] and [60]), and Da CaPo ([43] and [46]) additionally support mapping of application requirements onto protocol functionality. Operating system support in endsystems: the CPU of an endsystem represents the most limited resource for multimedia protocols and QoS guarantees require a reservation of it. Scheduling issues and how to meet the protocol processing requirements are discussed in [1], [31], and [34]. Generally, reservation of CPU is only supported by realtime operating systems. Coulson et al. [14] describe extensions of the micro-kernel Chorus to support continous media. In contrast, Gopalakrishnan et al. [22] integrate realtime signals in the Linux operating system to enforce QoS.

3 A General Consideration of QoS Negotiation in Multimedia Systems

Recent work on QoS support in multimedia systems focuses on communication systems and operating systems. However, it is necessary to consider more than communication systems and operating systems, because most multimedia systems do not only manipulate and transmit multimedia data. Additionally, they store and retrieve multimedia data, and present it in a proper way to the user. In general, we can identify the following functional units of multimedia systems: networks that connect endsystems, end-to-end protocols that are handled by endsystems, data management systems that comprise a repository of functions to store, retrieve, and change persistent data (e.g., le system, or database system), applications that are written to solve certain problems, human-computer-interfaces (HCIs) through which

human users and multimedia systems communicate, and operating systems on which all other elements - except networks - are based. Particularly, the importance of data management systems, applications, user interfaces, and users is not reected in current QoS approaches. Figure 1 illustrates a layered architecture of a sample multimedia system for a Video-on-Demand (VoD) application. Video data has to be transferred from a remote data management system, that manages a disk array, via end-to-end protocols and network to the application and HCI. Obviously, the entire system represents a chain, starting from the disk array that stores video data and ending at the HCI that presents the video data to the user. The cooperation of all elements establishes a QoS that is recognized from a human user at the HCI. Therefore, QoS considerations have to include all elements of multimedia systems. However, application requirements are determined by application requirements and by needs and preferences of the particular user. Consequently, the application requirements related QoS negotiation has to be performed between the two following parts of multimedia systems:

application related part including users, HCIs, and applications; and platform related part including networks, end-to-end protocols, data management system, and operating systems.
Multimedia System offers QoS

User recognizes QoS

HCI

APP

DMS

EEP

HNI

Network

HNI

EEP OS

DMS

OS

HCI: Human Computer Interface APP: Application DMS: Data Management System

EEP: End-to-End Protocols HNI: Host Network Interface OS: Operating System

Figure 1:Layered architecture of a sample multimedia system 3.1 Application Related Part Applications and HCIs are often implemented as one unit. However, application programs and their interfaces should be decoupled. This allows to change interfaces and to adapt them to user needs without altering the application. Application requirements are determined by the following three orthogonal aspects:

Service class of application, like conversational service (direct interactive realtime communication between two partners), messaging services (indirect one-to-one communication using intermediate storage facilities), retrieval services (individual requests to information centers), distribution services (one-to-many communication services, e.g., television distribution) and collection services (collecting information from distributed monitors in a many-to-one communication) [25]. Media types that are handled in an application and presented to the user, like plain text, graphics, still images, structured documents, animations, audio, and video. To be more precisely, we use the notion media type from Gibbs et al. [15], that is derived from the notion data type in programming languages. Media types, like data types, specify both a representation, or data structure, and a set of operations [15]. For example, the media type digital video includes the representation aspects: sampling rate, sample size and quantization, frame rate, and scaleability. End-user specic requirements: relevant aspects of the user include his or her level of expertise in the current task, perspective based on his or her role, value system, degree and nature of impairness due to fatigue or illness, and preferences concerning mode of communication [40].

The identication of user requirements represents one of the biggest problems. In the area of requirements engineering such problems of requirements capture and analysis are well known. The familiar problems include the following:

the user does not know her/his requirements, the user knows her/his requirements but cannot articulate them, and individual users are not representative of (all) relevant users [58]. Furthermore, users have often contradicting requirements, like high quality and low costs, and they do not know how to resolve them. Therefore, a specication method for application requirements with the following properties is necessary: (1) it has to support high-level, application related QoS parameters (based on application classes and media type characteristics), (2) it has to allow easy expression of - probably contradicting - requirements, and (3) it has to allow the platform related part to map the application requirements to internal functionality and resources as well as to optimize resource utility. 3.2 Platform Related Part QoS issues in networks, end-to-end protocols, and operating systems have been discussed in several publications (see chapter 2). First indications of relations between QoS and data management systems can be found in [24], [35], [52], and [56]. However, the relevance of data management system aspects for QoS in multimedia systems has not been broadly recognized. Therefore, we focus our discussion in this section on the inuence of data management systems on QoS. The term data management system describes a collection of mechanisms to store, retrieve, and change persistent data. Data management systems can be simple le systems as well as complex database systems. Generally, data management mechanisms can be found in any functional unit of the platform related part. For example, buffer management on host network interfaces, in end-to-end protocols, and le systems in operating systems. However, in multimedia systems we can identify a functional unit, that is responsible for handling persistent data. In the simplest case, such a data management system is running on a single system and uses the following resources:

CPU: all data management processes are running on the local CPU and compete with other processes (e.g., communication processes, application processes, or system processes) for CPU time. Primary storage: the results of read requests are buffered in main memory of the system, before they are copied to the address space of the application process. Furthermore, pages might be cached in main memory to reduce response times of following read requests. If there is a certain area of main memory reserved for data management, a the data management system assigns memory to competing data management processes. Otherwise, the data management processes have to compete with all other processes for main memory. Secondary storage: mainly hard disks are used for secondary storage. Disk space represents a limited resource for write operations. Disk rotation speed and head position time determine minimal access times for read and write operations. The theoretical maximal I/O throughput (transfer rate) will never be reached if multiple processes simultaneously access a disk. Each new I/O operation involves positioning of read/write heads and no data will be transferred to/from disk during this time.

In addition to characteristics and availability of hardware resources, QoS is inuenced by software resources respectively data management mechanisms. Such data management mechanisms include data modeling, integrity maintenance, change management, query processing, physical object and storage management, and transaction and workow management. A detailed discussion of relations between data management mechanisms and QoS can be found in [16]. Table 1 summarizes data management aspects that inuence the QoS parameters throughput, delay, delay jitter, and reliability. QoS Parameter Throughput Delay Delay Jitter Reliability Table 1: Data Management Mechanisms Transaction Management, Storage Management, Data Modeling, Query Optimization Transaction Management, Storage Management, Data Modeling, Query Optimization Temporal Data Modeling, Storage Management, Transaction Management Transaction Management with Recovery and Concurrency Control Mechanisms Relationships between QoS parameter and data management mechanisms

Traditionally, application requirements are mainly considered in data management systems during their design and implementation phase. Realtime database systems associate timing constraints with some operational aspects like query execution and transaction processing. They allow application processes to dene deadlines for these operations [42]. Missing hard transaction deadlines is disastrous and must not happen, while soft and rm transaction deadlines may be missed and their results are still of some interest for application and user. In terms of QoS semantics, tradi-

tional transactions can support only best-effort QoS, hard transaction deadlines support guaranteed QoS, and the degree of commitment in soft and rm transaction deadlines is most similar to threshold QoS.

4 Usage of Application Requirements in DEPEND

In this section, we use the DEPEND (Distance Education for People with differEnt NeeDs) project [47] at UNIK Center of Technology at Kjeller, University of Oslo, to illustrate the importance of application requirements in multimedia systems. However, a detailed description of how to map application requirements onto resources and functionality is out of the scope of this paper. DEPEND is concerned with two types of distance education: synchronous, that means lectures in an electronic classroom are distributed in realtime to other classrooms and student workstations; and asynchronous, in which students browse distributed hypermedia documents, including video clips from lectures, transparencies, exercises, and background material. DEPEND pays special attention to the needs of users and does not focus at one specic user group. Factors that determine user needs include: the level of expertise in the current task, perspective based on his or her role (e.g., teacher or student), as well as degree and nature of impairness due to fatigue or illness, like visual impairness, print disabled, hearing impairments, or motion impairment. Particularly, different (degrees of) impairments have to be reected in HCI conguration, e.g., visually impaired persons often prefer HCIs that combine synthetic speech and braille devices. One aim of DEPEND is to congure HCIs according to user needs. User needs are modelled and stored in a so-called user model and can be adjusted at runtime from the user. User needs, HCI specic requirements, and application specic requirements determine application requirements. Application requirements in turn, are used to negotiated a certain QoS between application related and platform related parts (see Figure 2). The platform related part uses application requirements for two tasks: QoS mapping and data selection. While QoS mapping is a central part of each multimedia system, data selection based on application requirements is special for DEPEND.
User Specications & User Model Application Related Part

HCI Conguration and Application

Application Requirements

QoS Negotiation

QoS Mapping

Data Selection (View) Platform Related Part

OS

EEP

DMS

NW

Multicast Protocols HCI: Human Computer Interface APP: Application DMS: Data Management System

DMS EEP: End-to-End Protocols HNI: Host Network Interface OS: Operating System

Figure 2:Application requirements and QoS negotiation in DEPEND - a functional view QoS mapping is a complex task, because resources and functionality of end-to-end protocols, networks, data management systems, and operating systems have to be selected in such a way that the resulting combination of all these elements fullls the application requirements. We apply the protocol conguration approach of the Da CaPo (Dynamic Conguration of Protocols) system ([43], [44], and [57]) for end-to-end protocols.1 In Da CaPo, application requirements are mapped at realtime onto protocol functionality by selecting appropriate protocol mechanisms (see chapter 5.2). Furthermore, protocol conguration in Da CaPo includes the selection of a network service and selection
1. The Da CaPo system was developed at Computer Engineering and Networks Laboratory, Swiss Federal Institute of Technology (ETH) Zurich.

of corresponding network QoS parameters. In the rst DEPEND prototype, we are using the SHORE database system [10] for persistent data management. SHORE is a exible persistent object store, that allows to incorporate application specic data modeling, transaction management, and storage management mechanisms. In other words, application requirements are mapped to particular data models, transaction management, and storage management. Later extensions will include aspects of realtime database systems to be able to map application requirements onto disk scheduling priorities and transaction deadlines. Obviously, all DEPEND processes or threads, i.e., Da CaPo threads, SHORE threads, application threads, and user processes or threads consuming processing power (i.e., CPU time) of the end-system. Gopalakrishnan et al. [22] suggest an approach to derive processing requirements for protocols from application requirements. In DEPEND, this approach is extended with estimations for processing requirements of SHORE, application, and HCI. These processing requirements in turn have to be mapped to scheduling algorithms and corresponding priority schemes, to reserve the necessary CPU time. We have chosen the following two operating system platforms for DEPEND: Solaris 2.4 and Chorus. Chorus is a micro-kernel operating system with multithreaded address spaces and realtime facilities [48]. Different scheduling policies can be implemented in the form of scheduling classes. Each class communicates with the core scheduler of the micro-kernel (a pure pre-emptive scheduler) and can make its own scheduling decisions within that class based upon attributes, like priorities and deadlines. In other words, in Chorus application requirements can be mapped onto priorities and deadlines of processes and threads. In Solaris application requirements can be mapped onto priorities of processes and threads. Furthermore, application requirements are used from the platform related part to distinguish between data that is of importance for the user and those that is not. For example, visually impaired persons are often not interested in video data and graphics, while hearing impaired users often do not care about audio data. Such a selection is called a view in database systems. In asynchronous teaching, a view will be used to reduce the amount of data that has to be retrieved from secondary storage and transferred to the students endsystem. This reduces the utilization of the following resources: disk I/O bandwidth, network trafc, CPU time for end-to-end protocol handling, data handling in the application, and to present the data to the user. In synchronous teaching, data is transferred from the classroom to several receivers with different needs. Several multicast relations, e.g., one per media types, as well as multicast protocols with ow splitting [3] can be used to fulll the different application requirements of the receivers, and to save resources (i.e., network trafc, CPU time for end-to-end protocol handling, data handling in the application, and resources necessary to present the data to the user). In both cases, data selection saves resources that could be used to realize appropriate QoS for the important data.

5 QoS Negotiation as an Optimization Problem

Application requirements are used to negotiate a certain QoS between application related and platform related part. Obviously, users want to get a good service, i.e., high video frame rate, low delay jitter, and low error rate; and the better the service the more satised is the user. Additionally, users prefer low costs and often need some remaining processing capacity to perform other tasks in parallel. However, the multimedia system has only a limited amount of resources available to fulll the requested QoS. Considering the multimedia system as a unit, the general problem is how to maximize the utility of limited resources. The term utility refers to the degree of satisfaction of the users of the multimedia systems. In other words, QoS negotiation results in an optimization problem. In traditional approaches that specify only target values in application requirements, this optimization problem is tackled by good guesses. The application submits a QoS request to the platform related part. This part analyzes whether it is possible to support such a QoS or not. If the answer is no, the application may submit the next guess. The rst QoS suggestion from the application, that could be fullled represents a solution of the QoS negotiation problem, but it is probably no optimal solution. Application and user must not know about the available resources within the multimedia system and therefore, this approach to solve the QoS negotiation problem is a try-and-error approach. Obviously, the platform related part is in a much better position to solve the QoS negotiation problem and to nd an optimal solution, because it knows about the available resources. However, this requires that the application species its - probably contradicting objectives. 5.1 Specifying Application Requirements in Form of a Vector Maximum Problem Scientic methods and techniques are used in operations research for decision making and to maximize the utility of limited resources. In particular, several mathematical programming techniques, like linear programming, are designed to solve optimization problems. All these techniques require a mathematical description of the optimization problem, that comprises three elements:

A measure of merit respectively an objective function that has to be minimized or maximized. For instance, maximize the quality of video and audio stream in a video conference, or minimize the response time of a distributed query. A set of variables that inuence the value of the objective function. Such variables include the amount of resources (i.e., network bandwidth, CPU time, or disk I/O bandwidth) that might be used. A set of constraints that allow certain values for the variables but exclude others. For example, the response time (rt) should be bounded by a certain value (v) and is always positive, i.e., 0 < rt < v.

The optimization problem itself can be formulated as: Find values of the variables that minimize or maximize the objective function while satisfying the constraints. However, often users would actually like to optimize a number of different objectives at once. For instance, the video quality should be maximized and the cost should be minimized. Usually, different objectives are not compatible and variables that optimize one objective may be far from optimal for others. For example, in order to support a higher video quality more network bandwidth has to be reserved. However, the reservation of more bandwidth increases the cost (instead of decreasing them). In operations research practice, problems with multiple objectives are reformulated as single-objective problems by either forming a weighted combination of the different objectives or else replacing some of the objectives by constraints. The resulting problem is often referred to as a vector maximum problem (VMP) and is mathematically represented as follows [26]: Max f ( x ) , f ( x ) , ......., f ( x ) 1 2 k subject to: g ( x ) < 0 i = 1, ...., m i

where x is an n dimensional decision variable vector, m constraints and k objectives. In order to specify application requirements, the n dimensional decision variable vector x comprises n QoS parameters that are of relevance for the application. Constraints can be used to express the non-negativity of variables as well as the minimal or maximal acceptable value of a decision variable. Objectives can be used to indicate whether certain decision variables should be minimized or maximized and how important their optimization is with respect to other variables. 5.2 QoS Negotiation in Da CaPo The Da CaPo system uses application requirements that are specied as a VMP to nd an optimal protocol conguration during the QoS negotiation. Da CaPo is based on a three layer model that splits communication systems into the layers A, C, and T. Endsystems communicate via the transport infrastructure (layer T), representing the available communication infrastructure with end-to-end connectivity (i.e., T services are generic). In layer C the end-to-end communication support adds functionality to T services such that at the AC-interface services are provided to run distributed applications (layer A). Da CaPo congures in realtime (i.e., during QoS negotiation) layer C protocols that are optimally adapted to application requirements, offered network services, and available resources. Fine granular building blocks that perform single protocol functions serve as building blocks for conguration. These building blocks provide a unied interface and can be implemented in hardware or in software. Thus, Da CaPo supports easy integration of existing devices like compression boards or en/decryption cards, because they have only to be encapsulated by the unied interface. Application requirements eAR are specied in Da CaPo in form of tuples of requirements on single attribute types ari, such as delay, delay jitter, packet loss rate, or security level: eAR = <ar1, ..., arn>. Each tuple ari includes attribute type, attribute value, and a (n)-ary weight function (n {0, 1}): ari = <attribute type, attribute value, weight function>. The specied attribute value is the minimal acceptable value and has to be met by a protocol entity. We call this value a knock-out value (i.e., constraint in VMP). The application sets the attribute value equal to the least element of its value set if it has no hard constraints and accepts every value. Weight functions describe objectives of the application by dening the importance of the particular requirement. The application requirements are passed to layer C where the

heuristic method CoRA (Conguration and Resource Allocation) [45] performs together with a connection management protocol the QoS negotiation. Da CaPo supports unilateral and bilateral negotiation. In unilateral negotiation, the CoRA entity at the initiators side makes a coarse and optimistic admission control. If there are probably enough resources available, the CoRA entity congures a protocol (i.e., selects modules and network services with certain QoS) that satises the application requirements as good as possible (according to the VMP) and is as light as possible (i.e., no unnecessary functionality and minimal resource usage). Afterwards, CoRA performs a more detailed admission control, because it now knows about the resources that are needed to offer the requested QoS. In the bilateral negotiation, both CoRA entities perform the same tasks and compare their results. One entity selects the globally best conguration and informs its peer about it. CoRA entities communicate via the connection management protocol. In other words, QoS negotiation in Da CaPo is performed by passing the application requirements to layer C, and one or two CoRA entities select the best protocol. The combination of admission control and protocol conguration represents a form of resource reservation. However, the rst Da CaPo version is implemented on SunOS 4.1.3. Therefore, it cannot be enforced that the protocol threads receive enough CPU time. Performance measurements of CoRA demonstrate that such a protocol conguration and admission control can be performed at realtime. Table 2 summarizes response times of the CoRA modes First, Mini, Medium, and Full with increasing response times and increasing qualitative results in four different scenarios. All measurements where made on Sun SparcStation 10/30. The complexity (denoted Comp.) of the optimization problems is measured as number of possible congurations and the quality compares how far the QoS of the selected protocol conguration fullls the application requirements. The input values for CoRA, like application requirements and properties of building blocks, are based on measurements, derived from the literature, or are estimations. Therefore, we performed a worst case analysis and created optimization problems with unrealistic high complexity. Nevertheless, such problems can be solved in a few milliseconds with results of high quality. Comp.: Time First Mini Medium Full 6 ms 9 ms 103 ms 700 ms 175,959 Quality 78 % 78 % 79 % 99 % Comp.: Time 3 ms 14 ms 183 ms 230 ms 1,876,896 Quality 96 % 99 % 100 % 100 % Comp.: Time 9.6 ms 15.8 ms 76 ms 81 ms 7,288,848 Quality 96 % 98 % 100 % 100 % Comp.: Time 5.7 ms 6 ms 116 ms 500 ms 58,560,768 Quality 70 % 70 % 70 % 90 %

Table 2:

Response times of CoRA

5.3 Extensions in DEPEND Several Da CaPo solutions for application requirements and QoS negotiation are extended and generalized for DEPEND, because end-to-end protocols are only one part of multimedia systems. The specication method in Da CaPo supports abstraction and allows layer C to optimize the utility of resources. Furthermore, contradicting requirements can be easily expressed by weight functions. However, the attribute types are low-level parameters and are replaced in DEPEND by user friendly and application related terms. In particular, those factors that determine application requirements are used to specify application requirements: media type, application class, user needs (i.e., necessary minimal quality), and user preferences (i.e., simple weight functions). Application requirements spAR are specied in form of tuples of requirements on single media types ari, such as digital video, digital audio, or text: spAR = <ar1, ..., arn>. Each tuple ari includes media type, minimal quality, a (n)-ary weight function (n {0, 1}), and application class: ari = <media type, minimal quality, weight function, application class>. We are using the notion media type in DEPEND as it is suggested in [15]. Media types specify representation and operations and are used for implementation of applications and HCIs in DEPEND. Therefore, it is easy to pass this information from the application to the platform related part. Obviously, representation related information can be

mapped easily onto resource requirements. Figure 3 illustrates the media types digital video, digital audio, and image, as they are dened in [15].
Media Type Image Media Type Digital Video Media Type Digital Audio Representation Representation Representation Color Model Analog formats sampled Sampling Frequency Alpha Channels Sampling Rate Sampling Size and Quantization Number of Channels Sampling Size and Quantization Number of Channels (Tracks) Channel Depth Data Rate Interleaving Interlacing Frame Rate Negative Samples Indexing Compression Encoding Pixel aspect Ratio Support for Interaction Operations Compression Scalability Storage Operations Operations Retrieval Editimg Storage Editing Point Operations Retrieval Effects and Filtering Filtering Synchronization Conversation Compositing Editing Geometric Transformations Effects Conversation Conversation

Figure 3: Sample media types (according to [15]) User needs for each media type are expressed in form of their minimal acceptable quality. This quality measure is very coarse and is realized as a scale from 0 to 10. Value 0 represents a very bad quality and value 10 a very good quality. These needs are stored in the user model and are acquired from users with help of examples. As weight functions we assume very simple functions, that can be described as: the higher the quality, the better, a particular quality level is best, the user does not care about it, and no need for this media type. Furthermore, the application delivers a specication of the application class for each media type.2 We use three application classes, as they are dened in [22]: isochronous class, burst class, and low delay class. In isochronous classes, continous media streams are handled, and in burst classes bulk data is transferred. Remote procedure requests are an example for the low delay class. Application classes offer additional information for the QoS negotiation.3 In particular, they indicate for which parameters it is most important to be optimized. For example, the media type video could be handled in a mail application (i.e., application class burst), or in a video conference, i.e. (application class isochronous). The total throughput is of main relevance for the mail application, while in video conferences delay jitter represents one of the most crucial parameters. For QoS negotiation, we extract the functionality of CoRA from Da CaPo and implement it in an extended version as a functional unit in the platform related part. CoRA additionally considers properties (i.e., functionality, resource usage, and current load) of data management system, operating system, application, and HCI for conguration and resource allocation. Each functional unit comprises a so-called local QoS manager that delivers information to CoRA and performs actions in the functional unit that are demanded from CoRA. Furthermore, the QoS negotiation protocol includes information exchange between the CoRA entities on the various endsystems. Figure 4 illustrates the relation between CoRA and the other functional units of multimedia systems.

6 Conclusions
In this paper, we have analyzed the problem of application requirements and QoS negotiation with respect to entire multimedia systems. Entire multimedia systems comprise the following functional units: HCIs, applications, data management systems, end-to-end protocols, networks, and operating systems. Application requirements are determined by application, HCI, user needs, and user preferences. We suggest to specify application requirements in form of VMPs. On the one hand, such a specication increases independence of the application related part from the platform related part in multimedia systems, because they do not have to specify target QoS values. A good target speci2. This represents for most applications redundancy, because mostly all media types are in the same application class. However, we do not want to exclude applications, that combine different classes, e.g. isochronous video and audio in addition to bulk transmission of documents. 3. Obviously, media types and application classes include some redundant information. However, both aspects can be directly derived from the application and their specication represents no computational overhead.

HCI APP LQ OS LQ DMS CoRA LQ EEP LQ HNI

Endsystems

HCI APP LQ CoRA LQ HNI LQ EEP OS LQ DMS

HCI: Human Computer Interface APP: Application DMS: Data Management System

EEP: End-to-End Protocols HNI: Host Network Interface OS: Operating System

Logical Relations LQ: Local QoS Manager

Figure 4: Simplyed conguration and resource allocation for QoS management in DEPEND cation would require knowledge about resources of the multimedia system. Due to the complexity of multimedia systems and their resources, this is not applicable (and must not be done). Independence of application related part from platform related part additionally minimizes the necessary effort to port the application and HCI from the initial environment to other environments with different resources. On the other hand, a VMP specication enables the platform related part to optimize the utility of resources, and to offer a QoS that fullls as good as possible the application requirements. Performance measurements of the heuristic method CoRA demonstrate that such optimization problems can be solved in realtime. The specication method and QoS negotiation in DEPEND is based on the approach of Da CaPo. Media types and application classes substitute the low-level attribute types in Da CaPo and are combined with minimal acceptable qualities and weight functions to specify application requirements. The DEPEND project is still in the design phase. Additionally, single elements of DEPEND are prototypically implemented, to study their feasibility and to use these experiences as a foundation for design considerations. In particular, there are three implementation activities: implementation of an adaptable world-wide-web browser for users with different degrees of visually impairment, portation of Da CaPo to the Chorus micro-kernel and realtime support for Da CaPo protocols, and implementation of a multimedia database system based on SHORE. Obviously, the DEPEND approach has several implications on design and implementation of future multimedia protocols. Two new approaches for multimedia protocols are:

Combining data management mechanisms and protocols mechanism like buffer management or forward error correction that are both applied in data management systems and communication protocols. For example, data management systems for VoD applications apply buffer management when reading blocks from disk arrays and at the clients (or terminals) site before displaying the data to minimize delay jitter [21]. Buffer management in end-to-end protocols is used in such applications to perform ow control and minimize delay jitter. Using a common buffer management could save an expensive copy operation between data management system and communication system at server and at client site. In order to reduce the probability of loss of data that is striped over a disk array, data management systems in VoD systems perform some form of forward error correction. For multimedia protocols, forward error correction is important, because continous media streams require low delay jitter and cannot tolerate retransmission of corrupted packets. In [4] the same forward error correcting code is used for data that is striped over several severs in a network and the end-to-end protocol. A step further in this direction is to use the same forward error correcting code in data management system and end-to-end protocols without de/endcoding of data between data management system and communication system. This would save at the servers site one decoding process in the data management system and one encoding process in the communication system. Considering storage systems as intermediate systems might be interesting for applications that mainly read multiple times data from secondary storage, like VoD applications. In such applications, communication systems are used to transport once data to a (remote) server and later multiple times from the server to the users. In both cases data is transported over space. The data management system is used to transfer data over time, i.e., to retrieve exactly the data that was written a certain time before. When considering a storage system as an interme-

diate system, we have the situation of data transport over space and time. However, several principles for intermediate network nodes will also be valid for such an intermediate storage node. For example, it is not necessary to handle the protocol stack respectively the corresponding functions from the physical layer up to the application layer. Network layer protocol data units might be stored directly without handling them from the higher layer protocols before writing them on disk. Correspondingly, during a read operation, network protocol data units are retrieved from disk and forwarded with the new destination address to the link layer.

Bibliography
[1] [2] [3] [4] [5] Anderson, D.: Metascheduling for contious media, in: ACM Transactions on Computer Systems. Vol. 11, No. 3, August 1993, pp. 226-252 Barth, I., Dermler, G., Fiederer, W.: Levels of Quality of Service in CINEMA, to appear in: Proceeding of German and Swiss Computer Science Society Conference, GISI95, Zurich, Switzerland, September 1995 Bauer, D., Wilde, E., Plattner, B.: Design Considerations for a Multicast Framework, in: Proceedings of the Tenth Annual Workshop on Computer Communication, Washington, September 1995 Bernhardt, C., Biersack, E.: The Server Array: A Scalable Video Server Architecture, in: Proceedings of 2nd IASTED/ ISMM Int. Conf. on Distributed Multimedia Systems and Applications, Stanford, California, USA, August 1995, pp. 85-88 Box, D. F., Schmidt, D. C., Suda, T.: "ADAPTIVE - An Object-Oriented Framework for Flexible and Adaptive Communication Protocols", Proceedings of 4th IFIP conference on high performance networking, hpn 92, Liege, Belgium, December 1992 Campbell, A., Coulson, G., Gracia, F., Hutchison, D., Leopold, H.: Integrated Quality of Service for Multimedia Communications, Proceedings of IEEE INFOCOMM'93, San Francisco, March 1993, pp. 732-739 Campbell, A., Coulson, G., Gracia, F., Hutchison, D.: Orchestration Services for Distributed Multimedia Synchronization, High Performance Networking, IV (C-14), A. Danthine and O. Spaniol (Editors), Elsvier Science Publishers B.V. (North-Holland), 1993, pp. 153-182 Campbell, A., Coulson, G., Hutchison, D.: A multimedia enhanced transport service in a quality of service architechture, Internal report MPG-93-22, Dept. of Computing, Lancaster University, 1993 Campbell, A., Coulson, G., Garcia, F., Hutchison, D., Leopold, H.: Intergrated quality of service for multimedia communications, in: Proc. of IEEE INFOCOM, March 1993, pp. 732-739 Carey, M. J., DeWitt, D. J., Franklin, M. J., Hall, N. E., McAuliffe, M., Naughton, J. F., Schuh, D. T., Solomon, M. H., Tan, C. K., Tsatalos, O., White, S., Zwilling, M. J.: Shoring Up Persistent Applications, in: Proceeding 1994 ACM-SIGMOD Conference on Management of Data, Minneapolis, MN, May 1994, pp. 383-394 Chen, T., Liu, S., and Samalam, V.: In-Service Monitoring of QoS in ATM Networks, in: Proc. of Gigabit Networking Workshop, Boston, Massachusetts, April 1995 Clark, D. D., Lambert, M. L., Zhang, L.: "NETBLT: A Bulk Data Transfer Protocol", Network Working Group Request for Comments 998, March 1987 Cohn, M.: "High Speed Transport Protocol (HSTP)", Contribution to ISO/IEC JTC1 SC6/WG4, September 1991 Coulson, G., Blair, G. S., Robin, P.: Micro-kernel Support for Continous Media in Distributed Systems, in: Computer Networks and ISDN Systems, Special Issue on Multimedia, 1995 Gibbs, S. J., Tsichritzis, D. C.: Multimedia Programming - Objects, Environments and Frameworks, ACM Press, Addison Wesley, 1994 Goebel, V., Johansen, B. H., Lchesn, H. C., Plagemann, T.: Next Generation Database Technologies for Advanced Communication Services, to appear in: 3rd Int. Conf. on Intelligence in broadband Networks and Services, IS&N95, Creet, Greece, LNCS, Springer, October 1995 Danthine, A., Baguette, Y., Leduc, G., Leonard, L.: The OSI 95 Connection-mode Transport Service - The Enhanced QoS, in: IFIP Conference on High Performance Networking, Liege, December 16-18, 1992 Danthine, A., Bonaventure, O.: "From Best Effort to Enhanced QoS", RACE 2060, CEC Deliverable Number R2060/ULg/ CIO/ DS/P/004/b1, July 1993 Feldmeier, D. C.: "An Overview of the TP++ Transport Protocol Project", High Performance Communication, Editor: Ahmed Tantawy, January 1993 Ferrari, D.: "Client Requirements for Real-Time Communication Services", IEEE Communications Magazine, November 1990, pp. 65-72

[6] [7]

[8] [9] [10]

[11] [12] [13] [14] [15] [16]

[17] [18] [19] [20]

[21] [22]

Freedman, C. S., DeWitt, D. J.: The SPIFFI Scalable Video-on-Demand System, in Proceedings of the 1995 ACM SIGMOD, SIGMOD Record, Volume 24, Issue 2, June 1995, pp. 352-363 Gopalakrishnan, R., Parulkar, G. M.: A Framework for QoS guarantees for Multimedia Applications within an Endsystem, to appear in: Proceeding of German and Swiss Computer Science Society Conference, GISI95, Zurich, Switzerland, September 1995 Haas, Z.: A Protocol Structure for High-Speed Communication over Broadband ISDN, in: IEEE Network Magazine, January 1991, pp. 64-70 Had, A. Bochman, G. v.: An Approach to Quality of Service Management for Distributed Multimedia Applications, in: Open Distributed Processing Experiments with Distributed Environments, Raymond, K., Armstrong, L. (Editors), IFIP, Chapman & Hall, 1995, pp. 334-345 Hehmann, D. B., Salmony, M. G., Stttgen, H. J.: "High-Speed Transport Systems for Multi-Medis Applications", Protocols for High-Speed Networks, H. Rudin and R. Willliamson (Editors), Elsvier Science Publishers B.V., North-Holland, IFIP, 1989, pp. 303-321 Hwang, C.-L., Masud, A. S.: Multiple Objective Decision Making - Methods and Applications, Lecture Notes in Economics and Mathemetical Systems 164, M. Beckmann, H. P. Knzi (Editors), 1979 "Open Systems Interconnection (OSI) - Model and Notation, Service Denition, Recommendadtions X.200 - X.219", ITU International Telecommunication Union, CCITT, Blue Book, Volume VIII - Facsimile VIII.4 Melbourne, Australia, November 1988 Quality of Service Framework (draft no. 3)", ITU - Telecommunications Standardization Sector Study Group 7 / WPs, Source: SC 21/WG 1 (N 1298), Project: JTC1.21.57, Geneva, Switzerland, February 1994 Quality management and quality assurance, Concepts and Terminology, International Standard ISO 8402:1994, Subcommittee SC 1 Ramaswami, V., Wang, J. L.: "Analysis of the link error monitoring protocols in the common channel signaling network", in: IEEE/ACM Transactions on Networking, Vol. 1, February 1993, pp. 31-47 Jeffay, K., Bennet, D.: A rate based execution abstraction for multimedia computing. in: 5th International Workshop on Network and Operating System Support for Digital Audio and Video, April 1995, pp. 67-78 Jung, J., Seret, D.: "Translation of QoS Parameters into ATM Performance Parameters in B-ISDN", in: Proceedings of IEEE INFOCOMM'93, San Francisco, March 1993, pp. 748-755 Kerherve, B., Vogel, A., Bochmann, G. v., Dssouli, R., Gecsei, J., Had, A.: On Distributed Multimedia Presentational Applications: Functional an Computational Architechture an QoS Negotiation, in: Proc. of 4th Int. IFIP Workshop on Protocols for High-Speed Networks, Chapman & Hall, London, 1994, pp. 1-17 Liu, C., Layland, J.: Scheduling Agoritms for Multiprogramming in a Hard Real-Time Environment, in: Journal of the ACM, Vol. 20, No. 1, January 1993, pp. 46-61 Louis, S., Teaff, D.: Class of Service in the High Performance Storage System, in: Open Distributed Processing Experiments with Distributed Environments, Raymond, K., Armstrong, L. (Editors), IFIP, Chapman & Hall, 1995, pp. 323-334 Metzler, B., Miloucheva, I.: "Specication of the Broadband Transport Protocol XTPX", CEC Deliverable R2060/TUB/ CIO/DS/P001/b2, February 1993 Mohran, M., Wolnger, B.: Design of a continuous media data transport service and protocol, Tech. Rep. TR-92-019, Computer Science Division, University of California, Berkley, April 1992 Nahrstedt, K.: Network Service Customization: End-point perspective, Tech. Rep. MS-CIS-93-100, University of Pennsylvania, Computer and Information Sciences, December 1993 Nahrstedt, K., Smith, J. M.: The QoS Broker, in IEEE Multimedia, Spring 1995, pp. 53-67 Neal, J. G., Shapiro, S. C.: Knowledge-Based Multimedia Systems, in: Multimedia Systems, John F. Koegel Buford (Contributing Editor), ACM Press, Addison-Weseley, 1994, pp. 403-438 OMalley S., Peterson L.: A Higly Layered Architecture for High-Speed Networks, Protocols for for High-Speed Networks, II, Majory J Johnston (Editro), Elsvier Science Publisher B.V. (North Holland), November 1990, pp. 141-156 zsoyoglu, G. Snodgrass, R. T.: Temporal and Real-Time Databases: A Survey, in: IEEE Transactions on Knowledge and Data Engineering, Vol. 7, No. 4, August 1995, pp. 513-532 Plagemann, T., Plattner, B., Vogt, M., Walter, T.: A Model for Dynamic Conguration of Light-Weight Protocols, Proceedings of IEEE Third Workshop on Future Trends of Distributed Computing Systems, Taipei, Taiwan, April 1992, pp. 100-107 Plagemann, T., Plattner, B., Vogt, M., Walter, T.: Modules as Building Blocks for Protocol Conguration, Proceedings International Conference on Network Protocols (ICNP'93), San Francisco, USA, October 1993, pp. 106-115

[23] [24]

[25]

[26] [27]

[28] [29] [30] [31] [32] [33]

[34] [35] [36] [37] [38] [39] [40] [41] [42] [43]

[44]

[45] [46] [47]

Plagemann, T., Gotti, A., Plattner, B.: CoRA - A Heuristic for Protocol Conguration and Resource Allocation in: Protocols for High-Speed Networks IV, Neufeld, G., Ito, M. (Editors), IFIP, Chapman & Hall, 1995, pp. 103-119 Plagemann, T.: A Framework for Dynamic Protocol Conguration, PhD Thesis, Swiss Federal Institute of Technology Zurich (Diss. ETH No. 10830), Zurich, Switzerland, September 1994 Plagemann, T., Goebel, V., Tollefsen, M.: DEPEND - Distance Education for People with Different Needs, in: Proceeding of 2nd IASTED/ISMM Int. Conf. on Distributed Multimedia Systems and Applications, Stanford, California, USA, August 1995, pp. 159-162 Rozier, M., Abrossimov, V., Armand, F. , Boule, I., Gien, M., Guillemont, M., Herrmann, F., Kaiser, C., Langlois, S.,Leonard, P., Neuhauser, W.: "Overview of the CHORUS Distributed Operating Systems", Chorus systemes Technical Report, CS-TR-90-2, 1990 Schill, A, Mittasch C., Hutschenreuter T., Wildenhain, F.: A Quality of Service Abstraction Tool for Advanced Distributed Applications, in: Open Distributed Processing Experiments with Distributed Environments, Raymond, K., Armstrong, L. (Editors), IFIP, Chapman & Hall, 1995, pp. 359-371 Simoni, N., Znaty, S.: "Qos: from denition to management", in: Proc of 4th IFIP Conference on High Performance Networking, Lige, Belgium, IFIP, December 1992 Simpson, W.: "PPP link quality monitoring", Internet Request for Comments RFC 1333, Internet Engineering Task Force, May 1992 Steinmetz, R.: Analysing the Multimedia Operating System, in: IEEE Multimedia, Spring 1995, pp. 68-84 Stiller, B.: Flexible Protocol Conguration Support for a Service Integrated Commmunication System (in German), Vol. 10, No. 306, Dsseldorf, Germany: VDI, 16, February 1994 Tobe, Y., Chou, S. T.-C., Toduka, H.: "QoS Control for Continous Media Communications", INET 92, April 1992, pp. 471481 Topolcic, C., Ed., Experimental Internet Stream Protocol, Version 2 (ST-II), RFC 1190, Oct. 1990 Vogel, A., Kerherve, B., Bochmann, G. Gecsei, J.: Distributed Multimedia and QoS: A Survey, in: IEEE Multimedia, Summer 95, Vol. 2 No. 2, pp. 10-19 Vogt, M., Plagemann, T., Plattner, B., Walter, T.: A Run-time Environment for Da CaPo, Proceedings of INET93, International Networking Conference Internet Society, San Francisco, August 1993, pp. 106-113 Woolgar, S. : Rethinking Requirements Analysis: Some Implications of Recent Research into Producer-Consumer Relationship in IT Development, in: Requirement Engineering - Social and Technical Issues, Jirotka, M. Goguen, J. (Edt.), Academic Press, 1994, pp. 201-216 Zhang,L., Deering, S., Estrin, D., Shenker, S., Zappala, D.: RSVP: A New Resource ReSerVation Protocol, IEEE Network, September 1993, pp. 8-18 Zitterbart, M., Stiller, B., Tantawy, A.: "A Model for Flexible High-Performance Communication Subsystems", IEEE Journal on Selected Areas in Communications; Volume 11, Number 4, May 1993, pp. 507-518

[48]

[49]

[50] [51] [52] [53] [54] [55] [56] [57] [58]

[59] [60]