Including Confidentiality in a Multimedia QoS Adaptation Architecture

Miguel Pupo Correia

 Navigators  Team, Faculty of Sciences of the University of Lisbon

mpc_AT_di.fc.ul.pt 


1. Introduction

In the last years there has been a growing attempt to use conventional data networks like the Internet for the communication of continuous media -- audio and video. Applications like internet telephone, vic, ivs, and nv are good examples of this trend. Audio and video have very different characteristics from the data those networks were designed for. They are real-time and some data loss is in general acceptable. This contrasts with conventional data, like files and email, for which no loss is acceptable but that do not have strong time constrains. Another differentiating characteristic of these media is that some data can be dropped in order to reduce the network bandwidth and the end hosts CPU time needed to process them. More, the reduction, or adaptation, of this quality, to the conditions of the overall system, network bandwidth and end hosts load, maximises the quality that can be achieved [3]. This quality is in general denominated as Quality of Service -- QoS. Consequently, a QoS adaptation mechanism has an important role in a distributed multimedia system [2, 3, 4, 5, 10].

A QoS adaptation mechanism can also be useful in contemporary networks like ATM, although these networks permit the reservation of bandwidth for real-time services. The VBR (Variable Bit Rate) service is especially adequate for continuous media. It reserves some bandwidth but also permits the use of some more, that is available within a certain probability; therefore an adaptation mechanism can also be beneficial to use that bandwidth. Also, the bandwidth necessary for a compressed video stream is very dependant on the scene complexity, so the reservation of a maximum value is difficult and would correspond to a bad resource usage. Consequently an adaptation mechanism can be used to match the media quality to the realistic value of bandwidth that was reserved.

A QoS adaptation mechanism that takes into account both the network and end hosts conditions was proposed in [2]. Here, we propose the inclusion of cipher schemes in that mechanism (section 2). Security in networks is an increasing concern and its wide spread use with multimedia data is just a question of time. In general, a single cipher algorithm is used during all data transmission but, as there are many algorithms and they cause different loads in end hosts, their inclusion in the adaptation mechanism makes sense and gives an additional degree of freedom to the programmer and user. That is the objective of what we propose here.

In [1] we proposed an architecture to handle QoS adaptation, so that the programmer would not have to handle this issue explicitly every time he created an application. This architecture is constituted by a set of components. We consider that each cipher algorithm is implemented as two software components (cipher and decipher). The adaptation of the confidentiality level is done by the substitution of one algorithm component by another. This increases the complexity of component management in the architecture, so here we propose the use of an Architecture Description Language (ADL) like Darwin [8, 6, 7] to manage this configuration efficiently (section 3).

 

2. QoS adaptation and confidentiality

The QoS of a distributed multimedia system is expressed in terms of QoS parameters associated to each media, for example: frame rate and colour depth for video; sample rate and coding for audio; latency for both. The QoS of a generic distributed system is related to its non-functional properties: performance, timeliness, security and fault tolerance. The purpose of QoS adaptation (in a distributed multimedia system) is to maximise the performance, i.e., the quality obtained with the bandwidth and CPU time available at each instant in the distributed system. Timeliness is also an issue as multimedia data has an instant (or a "short" time interval) to be presented; so it is dropped if for some reason it gets available (for example, received) after that instant. Security and fault tolerance are usually not addressed in the bibliography on distributed multimedia systems. Nevertheless, security is getting more important everyday with the greater and more commercial use of computer networks like the Internet. Also, Intranets and Extranets are two concepts necessarily associated with security mechanisms.

In this paper we advocate that confidentiality, one of the facets of security [11], can be considered as a QoS parameter of a distributed multimedia system and that it can be handled by a QoS adaptation mechanism like the one proposed in [2]. The advantage of such an inclusion is that the user or programmer can decide that the confidentiality level can be adapted to the network and end hosts conditions as well as other QoS parameters. We assume that there are stronger ciphering algorithms that are more CPU time consuming than others that are also weaker. So it is possible to chose a weaker algorithm to reduce the load at the end hosts. In general, the ciphering algorithms do not increase the amount of data to be sent, except possibly by a small quantity, so the bandwidth used is not affected by the ciphering scheme.

Our adaptation mechanism works with a QoS scale composed of several QoS levels. A QoS level is a working level of the algorithm. It is expressed in terms of QoS parameters. The scale gives all the working levels the algorithm can take.

An example of a scale is given in fig. 1. The media considered is M-JPEG video. The scale is expressed in terms of two QoS parameters: frame rate and confidentiality. The frame rate varies between 25 and 5 frames per second. For confidentiality we consider three algorithms: IDEA that uses a 128 bits key, DES that uses a 56 bits key, and a transposition cipher. They have a descending degree of security and we assume that the three implementations have performances inversely proportional to this degree. Our preference for secret-key algorithms is justified by their better performance in relation to public-key algorithms [11]. For the high rates of data herein considered this difference has a significant importance for the overall system performance. The application that defined the scale in fig. 1 wants to use IDEA as the ciphering method but accepts to use weaker methods if the conditions get worse. If the application was, for example, a videoconference, the user could be advised of the inferior security using some sort of visual effect.

25 / IDEA

20 / IDEA

15 / IDEA

10 / IDEA

5 / IDEA

5 / DES

5 / Transpos.

Fig. 1. An example of a QoS scale with seven levels (frames/second; ciphering algorithm).

The adaptation mechanism we proposed [2] is based in a closed control loop. A sender sends continuous media data to a receiver. The receiver sends back monitoring data to the sender. The sender uses this data to adjust the QoS of the media being sent. We advocated the use of Real Time Protocol (RTP) [9] and its control protocol (RTCP) for the media transmission and monitoring. Nevertheless some additional information was added to the receiver report RTCP packets, sent by the receiver to the sender with monitoring information, in order to measure also the end hosts conditions. The QoS algorithm computes the sum of the following values: 1) frames lost in the network; 2) frames discarded due to a delay in the sender or at network; and 3) frames discarded due to a high delay introduced by the kernel scheduler in the receiver. The first is part of the original RTCP receiver reports; the other two are the ones he included for measuring also the end hosts conditions. This sum is the total value of the losses. The algorithm does not use this value but the average of the last n values in order to avoid oscillations due to sporadic problems. We call this value filtered losses. We had good results in the experiments with n=3 and a time between RTCP packets of 5 s [2, 3].

The value filtered losses (%) is classified in four zones (the values li, lt, and ls are obtained experimentally):

In some situations the QoS Manager has to leave the decision of what to do to the application. An example is when the QoS is already at the lower value and the algorithm needs to decrease it once more. The application can decide to shut down the connection, to accept lower QoS values or not to do anything.

 

3. Architecture and configuration

In [1] we proposed an architecture to handle QoS adaptation on behalf of the application. The architecture is constituted by a set of components. Components have a state (data) and provide operations that change that state, so the words object or module could also be used. A component is an instantiation of a component type. In this section we show the changes introduced in the architecture by the inclusion of confidentiality and we discuss the advantages of using an ADL to describe its configuration.

The objective of the architecture is to simplify the distributed multimedia applications programmer's job by offering him a software layer that already performs most QoS management operations. In fact, the architecture can handle completely the media processing (capture / send / receive / present) and the adaptation of QoS with only a small intervention of the application. The architecture also hides the complexity of the system by performing a translation between higher level and lower level QoS parameters. Higher level QoS parameters (or Programmer level QoS parameters) are parameters that make sense to the application and to the programmer. Lower level QoS parameters (or System level) are the parameters that are meaningful for the operating system and the network.

Fig. 2. A configuration of the QoS adaptation architecture that receives, deciphers (IDEA) and presents an MPEG video stream (the notation is based in Darwin).

Fig. 2 shows a particular configuration of the architecture. A configuration is constituted by a set of components and their bindings. The configuration varies with time; for example, if the application creates a new media stream some new components are instantiated and binded. Next we describe briefly the component types from which the components are instantiated. Longer descriptions can be found in [1].

The Media Device Managers (MDMs) are a set of component types that capture and send, or receive and present, one media with certain characteristics. One example of an MDM is the MDM that can receive and present an MPEG video stream (MDM-mpeg-out, fig. 2). An MDM for an M-JPEG video stream would be different, as it would work with a different device driver. An MDM is instantiated for each stream being sent or received.

The QoS Manager is the component type that handles the adaptation of QoS (section 2). There is only one instantiation of this component type per application. For each receiving stream it gets a QoS scale from the application. It computes the filtered losses with the data it receives from RTCP, defines the working level and indicates the working level to the corresponding MDM, that translates it from Programmer Level to System Level QoS parameters. The QoS Manager is independent of the media being handled.

The ciphering and deciphering components are specific to each kind of cipher: IDEA, DES, etc. For instance, an IDEA deciphering component gets a frame, ciphers it and passes it to the RTP component (fig. 2). These components, contrary to all the others, can exist or not, depending on the application using confidentiality or not.

The Device Drivers (for ex., Video-out-dev in fig. 2) and RTP components only encapsulate the true device drivers and RTP implementation in a way adequate to the proposed framework.

The set of component instantiations existent in one host for one application is a composite component. This composite component is connected to the application, or better, to the part of the application that exists in that host. There is at least another of these sets in another host that communicates with this one, assuming that we have a distributed application.

The example shown in fig. 2 is very simple as it considers only one stream. Even a very simple application like a videoconference with only two interconnected users would have at least two streams, audio and video, with some additional components: another MDM, device driver and decipher component. More complex applications can have a considerable number of components being the management harder than for these simple cases.

A traditional approach to the management of the architecture using an object-oriented language like C++ or Java, possibly communicating over a middleware like CORBA, would be the following. Each component (implemented as an object) would instantiate the components that provide services it needs and would get references for them. As each component can require and provide many services this would mean a complex sequence of reference exchanges. The configuration would be implicit in the computational components, not explicit. The operations of creating and binding new components would have to be managed by one of the components (or distributed by several) but this would be an additional function to the services a component is supposed to provide. The same would happen with the change between ciphering or deciphering components. Also, the modification of the architecture to include new mechanisms with new components would imply to rethink all management, probably requiring changes in several components. Parallelism between the execution of components would require the explicit handling of processes or threads.

Here we propose another approach that is based in an ADL. An ADL is a language used to describe the conceptual architecture of a software system [8]. A description of an architecture is constituted by a set of components, bindings (or connectors) and the configuration (or topology). The configuration shows the way the components are interconnected by the bindings to form the application. The concept of binding, or connector, can be used to enable the run-time definition of the communication semantics. This can be useful in several classes of applications and also in multimedia, for example, to select the communication protocol adequate for a specific network.

Darwin [6] is an ADL. It can describe the configuration of an architecture using a graphical (fig. 2) or a textual language, and its evolution using the textual language. The first advantage is that structure is explicit: the components, the services provided and required, and the bindings are explicitly identified in the specification.

A second advantage is that the components have only to perform their basic functionality: the management of the other components and bindings is done by Darwin. The modification of the architecture is simple as a consequence of the management being handled by Darwin.

Mechanisms for the run-time instantiation (dynamic instantiation), or removal, and binding of components are already part of the language. They are the basis for dynamic reconfiguration that we already shown to be essential in the architecture being presented, to change between ciphering or deciphering algorithms, and also to introduce new streams in the application.

A last advantage is that parallelism and distribution are intrinsic to Darwin: all components are executed concurrently.

Darwin is used simply to specify the application. The programming and execution have to be supported by a distributed environment such as Regis [7].

 

4. Conclusion

The adaptation of multimedia QoS to the dynamic operating system and network conditions is important in several scenarios as it allows a better use of the resources, thus a better quality of the media being presented.

In this paper we propose an extension of the QoS adaptation scheme that we presented in [2] to include confidentiality, as security is an increasing demand in networks like the Internet. This extension permits the automatic selection between ciphering algorithms in order to adjust the throughput to the system conditions.

The inclusion of new components to handle confidentiality motivated a discussion on the use of Architecture Description Languages for managing the configuration of the architecture we proposed in [1]. This architecture is used to manage QoS and the media capture, communication and presentation on behalf of the application. The advantages of using ADLs were evident.

 

References

[1] Bom J., Marques P., Correia M., Pinto P., "An Architecture for Dynamic Multimedia QoS Control", 7th IFIP/ICCC Conf. on Information Networks and Data Communications, Aveiro, June 1998

[2] Bom J., Marques P., Correia M., Pinto P., "Integrated Dynamic QoS Control for Multimedia Applications", Int'l Symposium SYBEN 98 Broadband European Networks, Zürich, May 1998

[3] Bom J., Marques P., Correia M., Pinto P., "QoS Control: an Application Integrated Framework", IEEE Int'l Conf. on ATM, Colmar, June 1998

[4] Busse I., Deffner B., Schulzrinne H., "Dynamic QoS Control of Multimedia Applications based on RTP", Computer Communications, Vol. 19, N. 1, Jan. 1996

[5] Campbell A., Coulson G., "A QoS Adaptive Transport System: Design, Implementation and Experience", ACM Multimedia´96, Boston, 1996, 117-127

[6] Magee J., Dulay N., Eisenbach S., Kramer J., "Specifying Distributed Software Architectures", 5th European Software Engineering Conf., ESEC '95, Barcelona, September 1995

[7] Magee J., Dulay N., Kramer J., "Regis: A Constructive Development Environment for Distributed Programs", IEE/IOP/BCS Distributed Systems Engineering, 1(5), September 1994

[8] Medvidovic N., Taylor R., "A Framework for Classifying and Comparing Architecture Description Languages", Software Engineering Notes, Vol.22, N. 6, Nov. 1997

[9] Schulzrinne H., Casner S., Frederick R., Jacobson V., "RTP: A Transport Protocol for Real-Time Applications", (RFC 1889) January 1996

[10] Sisalem D., "End-To-End Quality of Service Control Using Adaptive Applications", IFIP 5th Int'l Workshop on QoS, New York, May 1997

[11] Tanembaum A., "Computer Networks", pp 577-622, 3rd Edition, Prentice Hall, 1996