Data Management and QoS in Distributed Multimedia Systems Towards an Integrated Framework

Vera Goebel and Thomas Plagemann

University of Oslo, Center for Technology at Kjeller (UNIK) Granaveien 33, P.O. Box 70, N-2007 Kjeller, Norway {goebel, plageman}@unik.no

ABSTRACT. The Quality of Service (QoS) concept is of central importance in the context of multimedia systems. Generally, multimedia systems comprise the following functional units: networks, end-to-end protocols, data management systems (DMSs), 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. However, the relevance of DMS aspects for QoS in multimedia systems has not been broadly recognized. In this paper, we identify QoS characteristics that are visible at the application - DMS interface. Furthermore, we discuss for some QoS characteristics the corresponding mechanisms within DMSs and describe two concrete types of DMSs that aim at QoS support: realtime database systems and multimedia storage servers. KEYWORDS. Quality of Service, Data Management, Database Systems, Storage Servers, File Systems

1 Introduction
It is commonly accepted, that the Quality of Service (QoS) concept is of central importance for multimedia systems [31]. From the communications point of view, the main concern is how to support the various QoS requirements by (new) protocols, like ST-II [29] and XTPX [17], and by new protocol architectures, like F-CSS [27] and Da CaPo [24]. Within the last years, it was recognized that protocols itself are not able to offer end-to-end guarantees for QoS. Several research projects, e.g., [3], [9], and [19], aim at operating systems support for multimedia protocols. 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 them 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 (DMSs) that comprise a repository of functions to store, retrieve, and change persistent data (e.g., le system, or database system - DBS), applications that are written to solve certain problems, human-computer-interfaces (HCIs) through which human users and multimedia systems communicate, and operating systems in which all elements of multimedia systems - except networks - are embedded. QoS is for human users only visible at the HCI. 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 DMS, that manages a disk array, -1-

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.
User recognizes QoS Multimedia System offers 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

First indications of relations between QoS and DMSs can be found in [12], [16], [26], and [31]. However, the relevance of DMS aspects for QoS in multimedia systems has not been broadly recognized. This is reected in emerging architectures, like the QoS-Architecture from Lancaster University [3], the End-System QoS Framework from Washington University [9], or the QoS Broker and the OMEGA architecture from University of Pennsylvania [19], that concentrate on data transfer related issues and pay no attention to data management aspects [24]. A good survey on various QoS architectures can be found in [1]. This paper focuses on QoS issues in DMSs.1 It relates well established DBS terminology and technologies to QoS terminology as it is dened in ISOs QoS Framework [13] to come one step closer towards an integratedframework for distributed multimedia systems. The remainder of this paper is structured as follows: chapter 2 briey describes the architecture of DBSs and classies DMSs. Chapter 3 gives a general introduction of QoS aspects of DMSs. Two types of DMSs that pay particular attention to some QoS aspects, i.e., realtime DBSs and multimedia storage servers, are described in chapter 4. The concluding chapter 5 gives a brief summary.

2 Classication of Data Management Systems

DMSs comprise a repository of functions to store, retrieve, and change persistent data like le systems or DBSs. DBSs that consist of database management systems (DBMS) and databases are by far the most advanced and complex DMSs. Thus, we use the layered architecture model for DBMSs (Figure 2) proposed by Hrder and Reuter [11] to illustrate the functionality of DBMSs, storage servers and simple le systems. Each layer supports a set of types and operations at its interfaces and typically consists of several mechanisms. In general, no concrete DBMS has fully
1. Only non-distributed DMSs are considered, because QoS aspects of distribution and communication have received much more attention in QoS research than pure DMS aspects.

-2-

realized the layered architecture for performance reasons, but this model serves as a good basis to compare DMSs (i.e., it is not thought as an implementation framework). The basic functionality of le systems (lowest layer) can be found in all three kinds of DMSs, but storage servers (lowest two to three layers) and DBMSs (all layers) contain much more application-oriented DMS functionality, e.g., application-oriented data modeling, query processing and optimization mechanisms, or buffering.
name of layer name of interface application model mapping unit: transaction aux. structures: ext. schema description unit: object/relations, tuples, attributes, views set-oriented interface DML languages like ALPHA, SQL, .... object processing & optimization access path optimization access control integrity control mapping of conceptual design onto logical design (data model) schema & transaction design operations functions/mechanisms

logical data structures

unit: objects/relations, tuples, attributes, views aux. structures: (ext.) schema description, integrity constraints/rules unit: records, sets, keys, logical access paths

record-oriented interface

FIND NEXT record name STORE record name, ... data dictionary navigation (cursor management) transaction management logical access path management sorting mechanism

logical access path structures

unit: records, sets, keys, logical access paths aux. structures: access path data, internal schema description unit: records, physical access paths, .... internal record interface STORE record, DELETE record, ....

storage structures

record management unit: records, physical access paths, .... physical access path management aux. structure: DBTT, FPA, page indices,.... lock management units: pages, segments log & recovery management reserve, release storage buffer interface (assignment operations) units: pages, segments aux. structures: page tables, block tables units: blocks, les le interface read block K write block K le management secondary storage management (operating system realizes this) system buffer management paging strategies

page assignement structures

storage assignment structures

units: blocks, les aux. structures: VTOC, extent tables, system catalog unit: tracks, cylinders, channels, ... device interface

volume table of contents (VTOC) channel operations/commands non-volatile secondary storage media (disk, tape, optical disk, RAID, ...)

database Figure 2:

Layered architecture model for DBMSs (according to [11])

-3-

2.1 Database Management Systems DBMSs provide concepts for the reliable, long-term management of integrated data to full requirements which are determined by the application domains and the computing environment. Examples for such concepts are: data structures and operations, views, authorization, transactions, and integrity constraints [15], [21], [11]. The layered architecture model for DBMS comprises the following six layers: Model mapping: DBSs must provide languages to dene and manipulate application data (the data model comprises data denition language (DDL), data manipulation language (DML), and (logical, semantic) integrity constraint specication language) and control information. Besides the mapping of all data types visible at the user interface onto internal object representations, the model mapping layer has to check all specied integrity constraints. Modern data models comprise object-oriented, deductive, temporal (history and versioning), spatial, and multimedia data modeling concepts, as well as imprecise data, and rules [15]. Logical data structures: support entities like relations, tuples, and views. Typical mechanisms are query processing and optimization, access control, and logical access paths to process declarative user queries. Information is accessed with DML statements based on its value or identity. Access control (security) is needed for applications to share information among users with different needs and authorizations by providing object-oriented authentication and authorization concepts. Logical access path structures: realize transaction management2 mechanisms and record-oriented structures and operations. Typical entities are records, sets, and logical access paths. They support the maintenance of temporal relationships, record-oriented search operations to specic data parts which are determined by specic storage structures (scan techniques), and complex operations of the higher system layers. Storage structures: comprise record management, addressing techniques, clustering mechanisms, physical access path structures, lock management, logging, and recovery. In this component, block and page structures have to be mapped onto more complex object structures and the corresponding operations. The tasks of storage structures are the implementation of physical objects and access paths in page-addressed segments; at the upper interface the knowledge about pages and segments is hidden from the logical access path component. This component has to manage description and mapping of data, free space information etc. The physical object descriptions are necessary to store and manipulate physical objects efciently. Page assignment structures: provide page replacement strategies and their optimization (e.g., prefetching). Ideally, this component should provide an innite linear address space, such that the next higher DBMS-components can address all objects virtually (virtual storage). The linear address space is subdivided in a set of segments with visible page boundaries because of efciency reasons of mapping and usage of selectively and tailored recovery algorithms. Segments of different types (and different maintenance effort) support a cost-optimal execution of various requirements. The direct assignment of pages to blocks enables to implement the interruptable replacement strategy update inplace. The indirection of the assignment makes it possible, to place pages atomically in the database. The choice of an appropriate

2. Transaction management can also be seen as an orthogonal concept (vertical side layer) concerning all layers of a DBMS.

-4-

placement strategy has signicant inuence on the usage of recovery and logging algorithms [11]. Main-memory buffering is crucial in the common DBMS scenario, there is locality and repetition in the objects referenced by an application, a lot of complex structured objects with many interobject references exist, or as a special case, the entire database working set may t into main memory. Storage assignment structures: have to provide the connection to the operating system, features to be provided are I/O of multiple blocks by one operation (chained I/O), exible le management, physical clustering (entire complex objects), and consideration of storage characteristics. They provide for the next higher layer a simple le interface with direct access to blocks of xed length. The information of device properties should be hidden at the upper interface which knows le- and block-oriented operations. A exible le management should support: a large amount of les which can grow dynamically, clustering of blocks on consecutive tracks and cylinders, denable block sizes per le. Sufcient mapping exibility with acceptable access performance provides the le assignment with extent tables [11]. The le interface is often preconditioned with xed block size by the operating system, thus, large pages can be simulated on the next higher level by chained I/O. Additionally, a storage hierarchy can be realized to ll the access gap between main memory and external storage in this layer. DBMSs have to support new media, e.g., CD-ROMs, or Jukeboxes, in order to provide an efcient system behavior [10]. Measures for enhancing fault tolerance (e.g., principle of stable storage for single blocks, mirror disks, etc.) can be transparently provided for the higher system layers.

2.2 File Systems File systems are an integral part of operating systems and are probably for most users its most visible aspect. Files could be dened as an organized collection of data records - possibly of different types - stored on external devices, such as disks, CD-ROM, or magnetic tapes [4]. For example, the UNIX le system is characterized by (1) a hierarchical structure of les and directories, (2) consistent treatment of le data as an unformatted stream of bytes, (3) a set of operations to create, read, write, and delete les, dynamic growth of les, the protection of le data by controlling le access with access permissions that are related with les, and (4) the treatment of peripheral devices - such as terminals and le units - as les [2]. The rather loose use of the term database has lead to some confusion between a le and a database. One basic difference is their usage pattern. Files are usually accessed by one or a few users, and there is only one logical view on the le. On the other hand, a database integrates a variety of data in such a way that it is available for multiple users, and each user may have a different logical view on the database. Furthermore, les are collections of occurrences of records of one type and databases are collections of occurrences of records of several types with specic relationships among the record types [4]. From the architectural point of view, le systems cover only the lowest layer of the DBMS model. 2.3 File and Storage Server Video-on-Demand (VoD), or more general Media-on-Demand (MoD) systems and applications currently enjoy a lot of attention in database and communications literature. Mainly, le servers also called video (le) server or multimedia (storage) server - are used to store multimedia data that is retrieved via network. Basically, le servers are components of distributed environments that are based on the client-server interaction. Tannenbaum [28] characterizes le server as proc-5-

esses that run on some machine - in a distributed environment - and implement the le service. The le service in turn is the specication of what the (distributed) le system offers to its clients. Simple le servers offer the same le operations than le systems, while video le servers often offer VCR-like functionality to their clients [5]. The use of le servers in a network introduces many new design issues compared to le systems. To improve the performance of such data management systems caching and prefetching techniques are often applied, which in turn raise cache coherence problems. Furthermore, le servers have to address the problem of authentication [20]. Due to the large amount of data in MoD systems and their strong performance burdens, disk arrays are often used as secondary storage media. However, the operations of a le server are independent from its physical structure. From the architectural point of view, le servers cover the lowest layer two to three DBMS layers (even if there is no real consensus about this terminology). The functionality of storage servers can be seen between those of simple le systems and sophisticated DBMSs.

3 Data Management Systems and QoS

The relationship between service provider and service user as it is dened in the OSI reference model corresponds to the relationship between application and DMS when considering the DMS as subsystem. This relationship is also often called client-server relationship in the context of DMS. Generally, DMS support the following QoS characteristics: response time, throughput, integrity, consistency, security (protection), reliability, and availability. However, most DMSs do not offer the possibility for the client to specify QoS requirements and no QoS negotiation takes place. There are two primary reasons for this: (1) performance related characteristics like response time and throughput are mainly best-effort and (2) often only one particular value is guaranteed for a QoS characteristic, e.g., full integrity in DBMS or a certain level of security. Traditionally, application requirements are mainly considered in DMSs in their design and implementation phase. In other words, most mechanisms that inuence QoS are initiated a priori or before initiation of the activity. In DBSs, the activity is marked by begin of transaction (BOT) and end of transaction (EOT), like in the transport layer by a CONNECT.request and a DISCONNECT.conrm (see Figure 3). The rst step towards integration of DMSs into distributed multimedia systems is to consider DMSs as a subsystem (i.e., black box). In the following sections, we identify QoS characteristics that are supported by DMSs, describe their semantics, corresponding mechanisms in DMS, and the time of their initiation. In particular, we consider the following QoS characteristics: response time, throughput, integrity, consistency, and security (protection). The denition of reliability and availability of DMSs is identical to their denition in ISOs QoS Framework [13] and is therefore not repeated at this place. 3.1 Response Time Response time is the elapsed time (T2 - T1) between the submission of the request and the receipt of the response [13]. In case of DBSs, the submission of the request is marked by a BOT and the receipt of the response by EOT. In case of more simple DMSs, the submission of a request corresponds mainly to a system (or procedure) call. Response time has two components: (1) wait time, i.e., the time spend waiting for the DMS and/or the time spend waiting for resources; and (2) service time, i.e., the time needed to process the request (without wait time) [10]. Most DMSs offer best effort response times, except realtime systems that guarantee a maximum response times. -6-

a priori User/Application Data Management System UPT

before initiation

during the activity BOT EOT time

at initiation of the activity a: Initiation of QoS Management in DMS

a priori Transport Service User Transport Service Provider UPT

before initiation

during the activity DISCONNECT.confirm time

CONNECT.request

at initiation of the activity b: Initiation of QoS Management inTtransport Layer UPT: Undefined Point in Time before BoT Figure 3: Initiation of QoS management BOT: Begin of Transaction EOT: End of Transaction

Specializations: response time of transaction for DBSs, response time of I/O operations like read and write operations for data elements (in logical or physical representation), pages, segments, and les. The following mechanisms are of relevance for response time: query optimization, transaction management including locking and logging mechanisms, and storage management including access paths, data placement, paging, and caching.

In traditional DMSs all these mechanisms are selected and initiated a priori. However, so-called extensible DBMSs offer possibilities to change some mechanisms (e.g., query optimization and data placement) during runtime (before initiation) of the transaction [7]. 3.2 Throughput Throughput is the rate of operations performed over a time interval t. In the context of DMSs, such operations correspond to transactions, in case of simple le systems operations correspond to I/O operations. Obviously, the type of transaction has to be dened in order to get a measure that could be used to compare the capacity of different systems. In MoD systems, throughput is often measured in maximum number of clients (or video streams) that could be served concurrently. Throughput is a best effort characteristic of DMS. Specializations: transaction throughput, I/O operation throughput, number of concurrent clients. The following mechanisms are of relevance for throughput:3
3. Throughput and response time represent two performance related aspects. Generally, the same mechanisms are used to improve both aspects. However, throughput optimization and response time optimization might have contradicting objectives.

-7-

query optimization, transaction management including locking and logging mechanisms, and storage management including access paths, data placement, paging, and caching.

In traditional DMSs all these mechanisms are selected and initiated a priori. However, extensible DBMSs offer possibilities to change some mechanisms (e.g., query optimization and data placement) during runtime (before initiation) of the transaction [7]. 3.3 Consistency and Integrity Data consistency (semantic integrity) comprises the process of keeping and showing the data correct in single user mode. Correct means here logical correct, without contradictions, and complete. Data integrity comprises the reliable operation of the DBS in multi-user mode and is concerned with uniqueness of identiers, ordering of data, and loss prevention. In other words, integrity can be seen as consistency in multi-user mode. Conventional DBMS guarantee consistency and integrity, because of their transaction management that assures atomicity, consistency, isolation, and durability (so-called ACID properties). DMS without transaction management to assure ACID properties can only offer best effort consistency. Specializations: implicit, explicit, inherent consistency, semantic (logical) integrity, storage (physical) integrity, transaction integrity. Transaction management is the central mechanism that assures consistency and integrity. It is traditionally initiated a priori, but some extensible DBMSs allow to change and integrate multiple transaction management mechanisms that can be selected during runtime. 3.4 Security (Protection) Security (protection) comprises all technical, physical, and organizational means/measurements to protect (guarantee protection) data and programs (from violations with or without purpose). Data protection comprises all efforts to avoid damage to persons by changing or destroying their data stored in the DBS. The following mechanisms are relevant to guarantee security/protection: authentication (identication), authorization, access matrices, cryptography.

4 Two Examples of Data Management Systems Supporting QoS

In this chapter, we describe two types of DMSs that pay particular attention to some QoS aspects, i.e., realtime DBSs and multimedia storage servers. 4.1 Realtime DBSs Realtime DBSs explicitly support the QoS characteristic response time by enforcing deadlines for (sub-)transactions according to [21]. 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 -8-

interest for application and user. In terms of QoS semantics, traditional 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 compulsory QoS. Due to the fact that timely transaction execution is more important than fairness or optimal utilization, the throughput of realtime DBSs is measured in percentage of transactions that complete within their deadlines. Realtime temporal data constraints originate from the fact that the age of data in the database is important for some realtime transactions and that, sometimes, members of a set of data values stored in the database must have similar values. Each base item value has an absolute valid time that indicates the real-world data observation time, and a validity interval that denes the length of the time following the absolute valid time during the value is considered valid. Realtime temporal data constraints have the following two components (the rst can be applied to any temporal database): Absolute data consistency states that the validity interval of the most recent value of a base (or derived) item is always longer than the time interval between its absolute valid (or absolute transaction) time and now. Relative data consistency states that a set of data items must be observed within a small time interval so that the items can be used to derive a new value for a data item. Such a set forms a relatively consistent set of items and is associated with a time interval, called the relative validity interval.4

Realtime transactions must read the most recent values of data items as dened by the following two constraints: External transaction consistency: it may not be possible to read and use the current value of external objects, because the most recent values in the database may differ from current values of realtime objects. External transaction consistency means that the difference between the time of a transaction operation on a data value and the absolute valid time of the data value is less than a given small threshold. Temporal transaction consistency: let V denote the values of a set of items that a given transaction T reads. Transaction T is temporally consistent if the difference between the valid (or transaction times) of any two base or derived values in V is less than a given small threshold.

Mechanisms that enforce deadlines and consistency constraints include transaction processing, concurrency control mechanisms, buffer management, and disk scheduling. Hard deadlines can only be supported if all factors that inuence transaction processing (e.g., transaction arrival pattern, data access type(s), properties of access objects, and resource requirements of transactions) are known a priori. With this knowledge, estimates of worst case transaction execution times can be obtained, and realtime task-scheduling techniques can be used to guarantee timely transaction execution. In order to process transaction with soft deadlines, priorities for realtime transactions are used for conict resolution and CPU scheduling. Transaction priority assignment policies include earliest-deadline-rst, highest-value-rst, least-slack-time-rst, xed-priority-with-a-priority-ceiling, and weighted priorities. Concurrency control techniques for realtime DBSs that use serializability as the correctness criteria include lock-based protocols such as two-phase locking
4. Enforcing relative consistency is an open research problem.

-9-

and its variants, optimistic concurrency control protocols, and timestamp-ordering protocols. Other concurrency control techniques for realtime DBSs include multiple copies of data and hybrid protocols that combine lock-based, timestamp-ordering-based, and optimistic concurrency control techniques. Epsilon serializability is an example for a concurrency control techniques that relax serializability. In conventional DBSs, buffer contention among transactions can impact performance signicantly. Therefore, priorized versions of two buffer management algorithms, like priority-least-recently-used and priority-DBMIN, have been investigated for realtime DBSs. Disk I/O constitutes a signicant part of transaction execution time and conventional disk I/O scheduling algorithms are revised to ensure timely transaction execution. 4.2 Multimedia Storage Server Multimedia storage servers are developed for particular applications, like VoD or News-onDemand, and store mainly continuous media types. The throughput of multimedia storage servers is often measured in number of clients that can be concurrently served. Low-level evaluation criteria of storage servers include I/O operations per second, bytes per second, response time capacity per dollar, I/O operations per second per dollar, bytes per second per dollar. In order to ensure smooth and meaningful ow of information to the user, the following two requirements are imposed [14]: Timeliness (or continouity [30]) is known in communications as delay jitter and requires that consecutive pieces of data from a stream be displayed to the user within a certain duration of time for continouity and no glitch [6] occurs. Hence, unlike realtime DBSs where deadlines are associated with individual transactions, multimedia data has continuous deadlines. Synchronization requires that data from different media be coordinated so that the user is presented with a consistent view.

There is a general consensus in literature on VoD systems that disk (arrays) are used as secondary storage in VoD systems. According to [18] the design of disk-based servers for VoD include the following issues: Concurrency: multiple concurrent streams need to be supported from the same copy of a video object. However, such situations cannot be solved by multicast distribution, because customers start not at the same time to access a video object. Data placement mechanisms like striping of data over several disks are used to increase this number of concurrent streams. Buffer sizing and management: buffer space is required to smooth the transition between asynchronous disk accesses and the synchronous playback of video streams. For example, in [6] a special buffer management is proposed that minimizes the delay jitter in video streams. Reliability: due to the number of disks used in VoD server, the issue of disk failure recovery needs to be addressed. This is an especially important issue when disk striping is used since failure of one disk will affect a large number of clients. Video layout: the mismatch between video object size and disk capacity leads to various inefciencies including the wastage of disk storage capacity and/or disk bandwidth. Thermal calibration (or workload balancing): most disks need to perform thermal calibration (i.e., move hot objects onto cold disks) on a regular basis. Workload balancing increases the number of clients that can be concurrently served, but during this process, the disk cannot - 10 -

serve I/O commands. This process can disrupt the seamless playback of video streams and increase the delay jitter in video streams.

5 Conclusions
Generally, multimedia systems comprise the following functional units: networks, end-to-end protocols, data management systems, applications, human-computer interfaces, and operating systems. In order to support QoS in distributed multimedia systems, all functional units have to support the same notion of QoS. In this paper, we presented QoS characteristics that are relevant for data management systems and referred to corresponding mechanisms. Obviously, such a presentation cannot be complete but it represents a rst step towards an integrated framework for distributed multimedia systems.

6 Bibliography
[1] [2] [3] [4] [5] [6] Aurrecoechea, C., Campbell, A., Hauw, L., A Survey of Quality of Service Architectures, Technical Report, Lancaster University, MPG-95-18, 1995 Bach, M., The Design of the UNIX Operating System, Prentice Hall, 1986 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 Claybrook, B.G, File, Encyclopedia of Computer Science, Ralston, A., Reilly, E. D. (Editors), IEEE Press, 1993 Dey-Sircar, J. K., Salehi, J. D., Kurose, J. F., Towsley, D., Providing VCR Capabilities in Large-Scale Video Servers, ACM Multimedia, October 1994 Freedman, C. S., DeWitt, D. J., The SPIFFI Scalable Video-on-Demand System, Proceedings of the 1995 ACM SIGMOD International Conference on Management of Data, San Jose, California, May 1995, pp. 352363 Goebel, V., A Modular Approach to Support the Data Placement Aspect in Congured DBMS, PhD Thesis, University of Zurich, Switzerland, Shaker Verlag, Germany, July 1995 Goebel, V., Johansen, B. H., Lchsen, H. C., Plagemann, T., Next Generation Database Technologies for Advanced Communication Services, in: Clark, A., Campolargo, M., Karatzas, N. (Editors), Bringing Telecommunication Services to the People - IS&N95, Third International Conference on Intelligence in Broadband Networks and Services, Heraklion, Crete, Greece, LNCS 998, Springer, October 1995, pp. 320-333 Gopalakrishnan, R., Parulkar, G. M., A Framework for QoS guarantees for Multimedia Applications within an Endsystem, in: Proceeding of German and Swiss Computer Science Society Conference, GISI95, Zurich, Switzerland, September 1995

[7] [8]

[9]

[10] Gray, J., Reuter, A., Transaction Processing: Concepts and Techniques, Morgan Kaufmann, 1993 [11] Hrder, T., Reuter, A., Concepts for Implementing a Centralized Database Management System, in: Proc. Int. Comp. Symp. 83, Teubner, 1983, pp. 28-59 [12] 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 [13] ISO/IEC Quality of Service Framework ISO/IEC JTC 1/SC 21 N9680, CD 13236.2, July 1995 [14] Kamath, M., Ramamritham, K., Towsley, D., Continous Media Sharing in Multimedia Database Systems, in: Proceedings of the Fourth International Conference on Database Systems for Advanced applications (DASFAA95), Ling, T., Masunaga, Y. (Edts.), Singapore, April 1995 [15] Kim, W. (Editor), Modern Database Systems - The Object Model, Interoperability, and Beyond, ACM Press, Addison-Wesley, 1995

- 11 -

[16] 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 [17] Miloucheva, I., Quality of Service Research for Distributed Multimedia Applications, 1995 ACM Pacic Workshop on Distributed Multimedia Systems (DMS 95), Honolulu, Hawaii, March 1995 [18] Mourad, A. N., Issues in the Design of a Storage Server for Video-On-Demand, to appear in: ACM/Springer Multimedia Systems Journal, 1996 [19] Nahrstedt, K., Smith, J. M., The QoS Broker, in: IEEE Multimedia, Spring 1995, pp. 53-67 [20] Narten, T. File Server, Enceclopedia of Computer Science, Ralston, A., Reilly, E. D. (Editors), IEEE Press, 1993 [21] 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 [22] Plagemann, T., Plattner, B., Vogt, M., Walter, T., Modules as Building Blocks for Protocol Conguration, in: Proceedings International Conference on Network Protocols (ICNP'93), San Francisco, USA, October 1993, pp. 106-115 [23] Plagemann, T., Goebel, V., Tollefsen, M., DEPEND - Distance Education for People With Different Needs, in: 2nd IASTED/ISMM Int. Conf. on Distributed Multimedia Systems and Applications, Stanford, California, August 1995, pp. 159-162 [24] Plagemann, T., A Framework for Dynamic Protocol Conguration, PhD Thesis, Swiss Federal Institute of Technology Zurich (Diss. ETH No. 10830), Zurich, Switzerland, September 1994 [25] Plagemann, T., Saethre, A. S., Goebel, V. , Application Requirements and QoS Negotiation in Multimedia Systems, in: Proceedings of Second Workshop on Protocols for Multimedia Systems, Salzburg Austria, October 1995 [26] Steinmetz, R.: Analysing the Multimedia Operating System, in: IEEE Multimedia, Spring 1995, pp. 68-84 [27] Stiller, B., Flexible Protocol Conguration Support for a Service Integrated Commmunication System (in German), Vol. 10, No. 306, Dsseldorf, Germany: VDI, 16, February 1994 [28] Tannenbaum, A. S., Distributed Operating Systems, Prentice Hall, 1995 [29] Topolcic, C. (Editor), Experimental Internet Stream Protocol, Version 2 (ST-II), RFC 1190, Oct. 1990 [30] Rangan, P. V., Vin, H. M., Ramanathan, S., Designing an On-Demand Multimedia Service, in: IEEE Communications Magazine, Vol. 30, No. 7, July 1992, pp. 56-65 [31] 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

- 12 -