FLEXIBLE AND EXTENSIBLE QOS-MANAGEMENT
FOR ADAPTIVE MIDDLEWARE
Thomas Plagemann1, Frank Eliassen2, Brita Hafskjold3,
Tom Kristensen1, Robert H. Macdonald3, and Hans Ole Rafaelsen4
1
University of Oslo, UniK - Center for Technology at Kjeller, {plageman, tomkri}@unik.no
2
University of Oslo, Department of Informatics, frank@ifi.uio.no
3
Norwegian Defence Research Establishment, {bha, Robert-H.Macdonald}@ffi.no
4
University of Tromsø, Department of Computer Science, hansr@acm.org
ABSTRACT
The task of middleware is to mask out problems of
heterogeneity and distribution for application
developers. With the emergence of new application
domains, like multimedia and real-time applications,
flexible support of QoS and real-time requirements
becomes a major challenge. Reconfigurable bindings
and policy driven binding protocols are the major
means in the MULTE framework to support these
requirements. Our current prototype implementation is
based on the CORBA 2.0 implementation COOL and
supports reconfigurable open bindings.
1 INTRODUCTION
Middleware has emerged as a central architectural
component in supporting distributed applications and
services. The role of middleware is to present a higher
level programming paradigm for application writers
(typically object-oriented or, more recently,
component-based) and to mask out problems of
heterogeneity and distribution. The importance of the
topic is reflected in the increasing visibility of
technologies as OMG's CORBA, Java RMI,
Microsoft's DCOM and the ISO/ITU-T Reference
Model for Open Distributed Processing.
However, the marketplace for middleware technology
is significantly changing. For example, there is
increasing demand to apply middleware technologies
in a wider variety of application domains including
real-time systems, embedded systems, fault-tolerant
systems, multimedia, and mobility. In this context,
flexible and extensible Quality-of-Service (QoS) and
real-time support is one of the major challenges.
Flexibility and extensibility are important, because a
single fixed middleware solution will not be able to
support the following requirements that are imposed
by the new application domains:
• Dynamic QoS support: applications should be able
to specify QoS requirements and to change them
dynamically. The middleware should provide the
requested QoS and adapt to changes in QoS
requirements, resource availability, etc.
• Evolution of QoS requirements: new media types
and new applications might introduce new QoS
characteristics. In order to support these new
requirements, QoS management in the middleware
must be extensible.
• Transparency versus fine-grained control:
developers of application components and users
should be able to define QoS requirements in highlevel (application) terminology, e.g., good video
quality, and in low-level system para-meters to
directly influence middleware configu-ration, e.g.,
compression = MPEG, and resource allocation,
e.g., throughput ≥ 1 Mb/s.
• Policy control: the middleware should enable endusers, application developers, and system
managers to specify policies for QoS mapping,
negotiation, monitoring, adaptation, etc. For
example a policy might be used to express that in
case the quality of a video should be degraded,
adaptation is done by reducing the frame rate
instead of the resolution.
• Automatic support for compatibility control: the
middleware should detect incompatibilities in user
requirements and equipment and resolve them – if
possible – with media scaling and transcoding.
• Support for seamless system evolution: the
integration of new components in the middleware
should not require re-compilation or changes of
existing components and middleware entities. This
must also be true for components that encapsulate
resources, i.e., APIs to network services.
Our experience with flexible protocol configuration
has shown that the above requirements cannot be
solved only by dynamic (re-)configuration of
communication protocols. Additionally, flexibility in
establishing and managing bindings is necessary.
It is the goal of this paper to give a conceptual and
architectural overview of how the MULTE framework
supports flexible and extensible QoS management.
The remainder of this paper is structured as follows:
in Section 2, we describe the two application domains
of the MULTE project and their requirements. Section
3 introduces the MULTE binding framework. How
the different aspects of QoS management, i.e., QoS
specification,
mapping,
resource
reservation,
monitoring and adaptation are integrated in the
MULTE binding framework is described in Section 4.
We summarize our prototype implementation in
Section 5 and related work in Section 6. Section 7
concludes the paper.
2 TWO APPLICATION SCENARIOS
In this section, we briefly outline two application
scenarios we are currently working with, the first one
represents a flexible multimedia application, and the
second a typical hard real-time system.
2.1 Lecture-on-Demand System
In the OMODIS project [25], we develop an adaptive
distributed multimedia system for Lecture-on-Demand
(LoD) to support asynchronous interactive distance
learning. The core of this system is a multimedia
database system (MMDBS) with QoS support.
Recorded lectures and additional multimedia
information that is relevant for the courses will be
stored in the MMDBS. The main requirements of the
LoD system related to QoS management are:
• Individual online access: users can access the
MMDBS via various types of networks, like
Ethernet, ATM, N-ISDN, and GSM.
• QoS support: user and application requirements
must be considered in the MMDBS, operating
systems, communication protocols, and network.
• Independence of data elements/streams: all
events and media streams must be independently
stored to allow independent retrieval and scalable
playback of elements.
• Scalable playback of lectures: must be triggered
via queries and via QoS requirements. Scaling of
streams must be supported during playback.
•
Fully synchronized playback: information about
the temporal relationships between data elements
is stored in the MMDBS as metadata.
A major feature of the LoD system is collaborative
presentation of multimedia objects. Typically, one
user (e.g., the teacher) selects via a QoS annotated
query a certain multimedia object in the MMDBS and
controls the play-out of the object from the MMDBS
to multiple clients. The MMDBS retrieves the data
and multicasts it over the network to multiple
students, each receiving the data on her/his computer.
A specific requirement of LoD is heterogeneity of
student equipment and underlying networks. For
example, if the supported performance, audio/video
formats, and compression schemes vary among the
receivers, the middleware platform must solve this
problem through, e.g., transcoding and media stream
scaling. Automatic support of this feature requires a
computationally tractable foundation for reasoning
about compatibility of the capabilities of systems and
networks.
Furthermore,
the
resolution
of
heterogeneity among the receivers must be performed
at run-time since both the set of receivers and the type
and amount of data to be transmitted is not statically
known, but rather depends on the specifics of the
teachers query. This requires run-time configuration
of the multicast binding. Dynamically varying
resource availability (e.g., network bandwidth for
wireless receivers) may require further run-time
adaptation of the binding, e.g., to reduce bandwidth
requirements for some of the receivers. Receivers may
even require the enforcement of individual policies for
this adaptation.
2.2 Combat Management Systems
Threats to naval ships, such as anti-ship missiles have
increased significantly over the last two decades.
Defensive capabilities to cope with such threats must
be developed but add a whole new dimension of
complexity to Combat Management Systems (CMS).
Such systems must be able to react within less than 10
seconds from detection of the threat (the flight time
from the radar horizon to the ship). A typical scenario
can be broken down into the following phases: missile
detected by radar (2 seconds), computers finished
processing classification (2 seconds), allocation of
defensive weapon system resources (shared resources
such as fire control radars are often allocated to other
less critical tasks) (2 seconds), target hand-over and
firing of appropriate self-defence weapon (1 second).
CMS systems may be visualised as a local-area
network (LAN) to which sensors, tactical processors
and workstations for command and control and all
other resources (like weapon systems, off-ship
communications, navigation systems with digital map
databases and so on) are interconnected [13].
Network technologies such as TCP/IP and UDP over
Ethernets and ATM; and processor systems, like Sun
SPARC and ALPHA based workstations running
various flavours of UNIX are in widespread use [21].
Sensor systems are connected to the backbone
network through standard network interfaces. The
system is often segregated into sub-systems for each
warfare area (such as anti-submarine or anti-aircraft
warfare) often using different hardware and software
commercial off the shelf solutions. In other words, a
ship's CMS is a complex heterogeneous system and
CMS applications benefit from the abstraction
middleware can offer [19].
Each CMS application is dedicated to particular
warfare areas. One demanding task is carrying out
data fusion from several sensors in order to provide a
qualitative stable situation picture. This requires data
to be pulled across the network into a tactical
processor, a complex processing to be executed
followed by a second information exchange across the
network to the CMS decision handling system.
In general, CMS applications are prioritized and are
under human supervision. The system as a whole is
designed to perform all in parallel. Missile selfdefence has the highest priority, above those of the
other warfare areas. Therefore, resources in the CMS,
like available network switches and bandwidth, CPU
time of tactical computers, etc., may have to be
reallocated to the missile self-defence task in the event
of a hit taking out critical parts of the system. This is
subject to the system-wide hard real-time requirement,
and as an upper limit the complete detection of
damage, reallocation of resources and all necessary
reconfiguration must be performed within 5-10
seconds to be of any use. In other words, real-time
support,
redundancy
and
careful
resource
management, and dynamic system reconfiguration
capability are of vital importance for CMS.
3 THE MULTE BINDING FRAMEWORK
The binding framework defines all entities involved in
the creation and manipulation of bindings, as well as
the binding components and the way they are handled.
Some principles are assumed for the binding
framework, such as the support for multi-party and
multimedia bindings, QoS negotiation/re-negotiation
among the binding endpoints, and the use of policies.
Policies are an important part of the framework since
they provide a flexible way to control the behaviour of
the entities involved in binding actions.
Crucially, the binding framework is based upon the
concept of open binding [10]. An open binding is a
composite distributed object, used to connect multiple
interfaces across a distributed environment.
Therefore, open bindings provide all the necessary
functionality to support remote interaction, including
distribution transparencies and services. In addition,
an open binding usually has multiple levels of composition, meaning that one binding can be composed
of lower level bindings. This allows multiple levels of
abstraction and reuse of binding specifications.
3.1 Basic Elements
The binding framework defines the following entities:
• Binding factory (BF): responsible for creation of
bindings. The BF is a distributed entity, meaning
the existence of replicated factories. Each of these
replicas behaves according to well-defined roles
when co-operating to create a binding.
• Binding manager (BM): responsible for
monitoring and co-ordinating binding adaptation
such as adding, removing or replacing components
in a binding, as well as changing the behavior of
existing components, e.g., by changing resource
reservations for the components. Furthermore, the
BM can ask the application to adapt.
• Binding destructor (BD): releases bindings and
frees the allocated resources.
• Binding template (BT): specifies the properties,
constraints, and configuration guidelines for
binding objects. Binding templates are used by
BFs to define the structure of new bindings.
• Configuration: the set of components that
constitute the internals of binding objects. A
configuration is the product of the evaluation of a
BT, and is represented by an object graph
depicting the identities and types of the binding
components, and their interconnections.
• Binding protocol (BP): protocols used by BFs to
create new bindings, by BM to adapt existing
bindings, and by BDs to remove bindings.
BFs, BMs, and BDs are collectively referred to as life
cycle components of bindings. In contrast, binding
components are the basic building blocks of binding
configurations, and are defined as objects that can
have multiple distinct interfaces. Our components
model prescribes how components are specified, how
component specifications are stored for future use,
and how components are created from such
specifications. Importantly, the model allows
components with arbitrary levels of granularity, which
means that primitive and composite components can
be defined. Figure 1 illustrates a simple (nested)
stream binding between the LoD system and a
students’ client consisting of a composite component,
i.e., a primitive (closed) UDP binding, a flow-control
component and a MJPEG decoder component.
LoD
System
Figure 1.
UDP
binding
Flow
Control
MJPEG
student
client
Components of a simple stream binding
3.2 Binding Protocols
Different types of binding protocols are used by BFs,
BMs, and BDs during the life cycle of bindings. All
binding protocols have some common features, due to
the way open bindings are structured:
• Binding protocols guide the communication and
co-ordination among the BF, BM, and BD replicas
involved in a binding.
• Open bindings may have multiple levels, each of
them corresponding to individual bindings. This
implies that all binding protocols have a recursive
definition, or alternatively, that a binding protocol
must rely on the execution of other lower level
binding protocols. Consequently, for each level of
binding, a different context of BFs, BMs, and BDs
respectively, will be involved.
• Binding protocols combine a set of simple
protocols for tasks like QoS management,
connection management, resource management,
and other signalling tasks. For all these tasks
mostly multiple alternatives with different
properties exist. For example, QoS negotiation can
be performed as unilateral, bilateral, or triangular
negotiation; and the binding can be established in
a three-way handshake, two-way handshake, or
implicit. These alternatives are combined in
different scripts according to various policies.
Thus, the behavior of a binding protocol is
determined by policies and specified in scripts.
By defining distinct binding protocols, we define
different ways in which bindings may be created, and
adapted. This allows the creation of bindings with
different characteristics (e.g., multi-party, with QoS
guarantees). In addition, different binding protocols
may be optimized for different binding templates.
Therefore, prior to requesting the creation (and
subsequent modification) of a binding, the user may
set up policies that configure the life cycle
components of the binding such that they behave
according to the desired binding protocol.
Another commonality among different binding
protocols refers to the way peer life cycle replicas
communicate with each other. When a replica wants to
pass information to a peer on the other side of the
binding (e.g., interface references and transport
addresses), it packs that information and passes it to
the next upper level life cycle replica on its side. At
the most external level of binding, the life cycle
replicas actually transfer the binding information over
the network. On the other sides of the binding, at each
level, the respective information is then unpacked and
delivered to the intended life cycle replicas. Using this
approach, we effectively reduce the communication
overhead
involved
in
multi-level
binding
establishment and adaptation.
A third similarity among binding protocols is the way
QoS negotiation is conducted. In general, the above
principle is followed, where the overall QoS for the
binding is negotiated among the life cycle replicas for
the uppermost level of binding. Subsequently, the
negotiated QoS parameters are propagated to the
lower levels of binding.
4 QOS MANAGEMENT IN MULTE
QoS management in MULTE is based on the highlevel stream binding language B and the low-level
QoS mediator language M. Furthermore, MULTE
provides prefabricated high-level specifications, called
Application Specific Adapters (ASAs), for
standardized services, like H.323 video conferences.
4.1 QoS Mediator Language M
The language M provides an abstraction over network
resources and operating system resources, like CPU
time and memory, by defining an extensible set of
low-level QoS parameters and values that are
independent of particular resources, but can be
mapped easily to them. Components that encapsulate
particular resources have to provide a mapping
between M and the native “QoS terminology” of the
resource, e.g., the QoS parameters defined by a
particular network service like RSVP or ATM UNI
4.0. Table 1 summarizes the “core” parameters of M.
Table 1.
Parameters and value ranges of M
Parameter
Value Range
Obligation
Establishment delay
Establishment failure probab.
Release delay
Release failure probability
Minimum data rate
Average data rate
Peak data rate
Max burst size
Minimum data unit size
Average data unit size
Maximum data unit size
Transit delay
Transit delay jitter
Loss ratio
Memory
Period
Deadline
Priority
guaranteed,
statistical
guaranteed,
proportional share, best
effort
> 0 ms
0 .. 1
> 0 ms
0 .. 1
> 0 bytes/s
> 0 bytes/s
> 0 bytes/s
> 0 bytes
> 0 bytes
> 0 bytes
> 0 bytes
> 0 ms
> 0 ms
0 .. 1
> 0 bytes
> 0 ms
> 0 ms
0 .. 255
4.2 Stream Binding Language B
The main programming concepts for multimedia
applications provided by the MULTE framework are
explicit stream bindings, stream interfaces, flows, and
associated type checking rules [9]. A binding type
identifies the type of stream interfaces that can
participate in the binding, the roles they play, and the
way behavior at the various stream interfaces are
linked. A stream interface consists of a collection of
source and/or sink media flows.
The language B is used to specify properties of stream
bindings, including QoS requirements and binding
structure such as one-to-one, one-to-many, and manyto-many associations of stream interfaces. The
MULTE framework includes a binding trader in
which B specifications are used to express binding
requirements and binding offers. The trader resolves a
trader inquiry to one or more binding factories that
offer bindings conforming to the user’s requirements.
The language B also includes the notion of policy
specification. In those cases where binding objects
specify alternative stream behavior (e.g., for
encodings, resolutions, or frame rates) at its supported
interfaces, policy specification support automatic
negotiation and renegotiation (i.e., adaptation) of the
actual stream interface behaviour.
Furthermore,
policies might specify different strategies how to
negotiate QoS, how to perform connection
management and how to allocate resources. In this
case, these policies are implemented by a particular
configuration of the binding protocol.
A binding is specified by a 5-tuple (T, P, M, ∆, E).
The tuple’s elements are briefly explained in Table 2.
Table 2.
Elements of binding specifications
Role types (T)
Roles (P)
Matching
requirement
(M)
Role
causalities (∆)
Role
cardinality (E)
Set of stream interface types
Given role names of a given role type
Required compatibility relation-ship
between corresponding interfaces
offered by the binding and application
respectively
Specifies the binding structure as
associations between instances of
roles
Maximum number of instances of a
particular role in the binding object
Typical QoS parameters for flows, shown with some
possible value ranges are listed in Table 3.
Table 3.
Parameters of flow specifications
Parameter
Value Range
Encoding
Sample rate
Sample size
Audio channels
Width
H.261, MPEG, MJPEG, GSM, etc.
1 .. 44kHz
8, 16, 32
1, 2
160, 320, 640, 1024
Height
Pixel depth
120, 280, 480, 768
1, 2, 4, 8, 16, 24, 32
A policy specification is given by a set of selection
statements. For each selection statement a set of
attribute ranges are specified (see Table 4).
Statements are evaluated from top to bottom. For each
statement, attribute ranges are evaluated from right to
left. That is, configurations with different values for
the right most attributes, are preferred before different
values of the left most attributes. For further details
about policy specifications, the reader is referred to
[26].
Table 4.
1
2
3
Structure of policies specifications
res(high,med)
res(med.low)
depth(16,8)
depth(24,16)
rate(20,15)
rate(20,15)
rate(30,20)
depth(24,16)
res(low,low)
Example: Consider a LoD scenario (c.f. section 2.1)
where some students want to playback an earlier
recorded lecture. Once the recorded lecture has been
selected, a binding between the video server storing
the lecture and the students’ application is needed.
Based on the capabilities of the students applications,
and the format of the stored lecture, an initiator, i.e.,
one of the students, requests the creation of a binding
with the following binding type:
-- interface types
type AudioConsumer = stream [
a : sink flow [
a1 : Audio [encoding:{GSM}, rate: 8000]]
configuration a ]
type AudioProducer = stream [
a : source flow [
a1 : Audio [encoding:{GSM}, rate: 8000]]
configuration a ]
type VideoConsumer = stream [
v : sink flow [
v1 : Video [encoding:{H.261, MJPEG},
rate: {10..25}]]
configuration v]
type VideoProducer = stream [
v : source flow [
v1 : Video [encoding:{H.261, MJPEG},
rate: {10..25}]]
configuration v]
--role types
LectureProducer={VideoProducer,AudioProducer}
LectureConsumer={VideoConsumer,AudioConsumer}
-- roles
LoDsystem : LectureProducer
student : LectureConsumer
-- matching requirements
<LoDsystem : partially_relaxed, narrow>
<student : partially_relaxed, narrow>
-- role causalities
<ONE-MANY, LoDsystem, student, no_conv>
-- role cardinalities
<LoDsystem, 1>
<student, 1..30>
4.3 Application Specific Adapters
Application Specific Adapters (ASAs) contain predefined B and QoS specifications for standardized
services, like H.323, in which the application can only
change values of the given QoS parameters. The B
specification in ASAs is a subset of what B is able to
express, because a given standard or application
restricts the parameter types and their value ranges.
Parameter in the B specification of an ASA have
default values if the application does not specify
particular requirements. The rest of this section
describes a simplified ASA for H.323 [14].
Figure 2 shows the scope of H.323. A set of audio and
video codecs are used for the media flows. The media
flows use RTP [29] as transport protocol. To connect
equipment as white boards or perform file transfer and
database queries the T.120 family of protocols are
used. H.323 defines how to signal control
information. Signaling is performed by the protocols
in the System Control component. RAS (Registration,
Admission and Status) provides services to find the
gatekeeper, to register to the net, etc. H.245 is used as
a control channel during the session lifetime. It’s tasks
include to exchange capabilities to send/receive
different message types, coding formats, and change
bandwidth requirements. Q.931 is used for call setup,
that is to establish a session by signalling the peer
application.
Microphone/
speaker
Audio codec
G.7xx
Camera/
display
Data
equipment
Video codec
H.26x
Data interface
T.120
System
Control
User
Interface
System Control
H.245
Q.931
RAS
Figure 2.
RTP
LAN
H.323 Architecture
H.323 has a limited set of QoS parameters, but the
applications may specify the tolerated jitter, skew
between different media flows and bandwidth
requirements. Also the supported set of codecs
restricts the format parameter space for the B
specification. For video the possible choices are
H.261 with QCIF and CIF resolution, and H.263 with
SQCIF, QCIF up to 16CIF. The only mandatory
applications H.323 must support are H.261 and QCIF.
These mandatory components are together with the
other possible combinations specified in the ASA.
To extend our H.323 ASA, it is optionally possible to
use RSVP for QoS signalling. H.323 also allows the
definition of non-standard extensions, this enables
applications to use the other features of MULTE-ORB
not supported by the H.323 framework.
The ASA for H.323 contains a BT for this simplified
H.323 ASA, where the different signalling sequences
are described in BF, BM and BD scripts. During
format and QoS parameter negotiation the actual
component configuration and the instances of BF, BM
and BD are found.
In summary, MULTE provides three levels of QoS
specification. Applications can choose between the
following three approaches (see Figure 2): use an
ASA, use B, or use M. Thus, application developers
determine whether they want to benefit from the
transparencies and high abstraction an ASA provides
or whether they want to use the possibility of finegrained control by specifying QoS parameters and
resource requirements in M.
Degree of abstraction
Application
ASA
B
Middleware
M
Ability for fine-grained control
Figure 3.
Levels of QoS Specification
4.4 Policies and QoS Mapping
The basic approach of mapping a QoS specification in
B to a particular binding configuration is as follows: B
and the binding trader are used to select an
appropriate BF and to perform application level QoS
negotiation. After successful negotiation the QoS
specification in B is mapped to a specification in M.
M in turn is mapped from the resource encapsulating
components to resource reservations. In case a
monitoring component detects violations of
guaranteed QoS, or required resources are no longer
in the appropriate amount available, M is mapped to B
and a BM is used to reconfigure the binding.
It is important to note, that the type of QoS
negotiation, mapping, and resource adaptation is
defined by policies and included in corresponding
scripts for the binding life-cycle components, i.e., BF
and BM.
4.5 Resource Reservation
Whether resources can be reserved for a binding
respectively for the set of threads that implement the
binding on, depends on the services that are provided
from the operating systems on these systems and the
available network services. For example, ATM and
Internet Integrated Services support reservation of
network resources, while the classical Internet does
not. Thus, the primary question is whether such
services are available or not. If not, only bindings with
best effort QoS semantics can be supported.
If resource reservation services are available, the task
of resource reservation might either be performed
locally, e.g., for reservation of memory and CPU time,
or requires a reservation protocol, like RSVP or ST-II.
Obviously, resource reservation protocols are part of
binding protocols. Therefore, resource reservation
protocols can be selected by policies and included in
scripts of the binding life-cycle components.
For both types of resource reservation, a mapping
from M to the native parameter has to be provided by
a wrapper that encapsulates the native services and
provides a MULTE conform interface.
QoS from the preferred values, we get as input to the
system the preferred change of QoS values. However,
it might take a long time that the monitored values rise
or fall to the preferred value. In order to reach a
system state in which the monitored QoS values
match the requested QoS values as fast as possible, we
use a regulator to adjust the preferred changes (see
Figure 4). By using an appropriate regulator, we can
also avoid transient effect, with the monitored values
bouncing up and down before settling at the preferred
values.
preferred change
monitored
of QoS values
values
system and
regulator
monitors
preferred
QoS values
4.6 Monitoring and Adaptation
The BM is responsible to maintain the QoS for a
binding according to the application requirements, i.e.,
QoS specification and policies. Generally, QoS
maintenance includes two tasks:
• Monitoring is performed by configuring
monitoring components into the binding.
Monitoring results are communicated to the BM
with an event service to which the BM has
registered and the monitor reports, or that the BM
polls the monitor(s) at regular intervals, or a
combination of both. Furthermore, components
that perform internal monitoring, like ARQ
components that collect information on number of
retransmissions, can communicate monitoring
results to the BM in the same way.
• Adaptation can basically be performed in the
following four ways: (1) changing local resource
reservations, e.g., increase the amount of allocated
memory for a receive buffer, (2) changing global
resource reservations with a resource reservation
protocol, (3) changing behavior of single
components by setting new QoS parameters, like
the Q-factor of an MJPEG component, and (4)
changing the binding configuration, e.g.,
exchanging a component for lossless compression
with a component for lossy compression.
Depending on the application requirements, available
resources and monitoring results a single, or a
combination of multiple these approaches has to be
performed. However, the basic decision when and
how to adapt is based on classical feedback control
loop from control theory [34]. The basic elements of a
feedback loop are:
• System under control, which can be a single
component, multiple components, or a binding at
an arbitrary level.
• Input to the system, i.e., the preferred QoS values
respectively the preferred change of QoS values.
• Output of the system/monitor, i.e., the measured
QoS values.
By subtracting the monitored values of the achieved
Feedback loop with regulator
Regulators are part of the script in the BM and are
selected according to the type of system, i.e., binding
configuration or component, that is monitored.
In Figure 5, such a feedback control loop is illustrated
for the simple stream binding introduced in Section
3.1, Figure 1. A monitoring component measures the
throughput of the flow control component and
generates a monitoring event if the measured
throughput is below a given threshold value. The
regulator in the BM calculates the necessary change in
memory reservation for the flow control components
and a corresponding allocation is performed.
It should be noted that feedback loops can be
recursively encapsulated. The input to an outer
feedback loop will typically be of a closer-to-thehuman-operator kind, which in computer systems
means that it is more abstract. The input to the inner
feedback loop could be bandwidth in Mbps, while the
input to the outer loop could be the preferred frame
rate of a multimedia application.
Binding Manag.
.....
regulator()
res_reserv()
....
Reserve_memory(X);
LoD System
Figure 4.
UDP
Monitoring _event()
Monitor
Flow
Control
MJPEG
Feedback control loop in stream binding
5 PROTOTYPE
Our prototype implementation, called MULTE-ORB,
is based on the flexible protocol framework Da CaPo
(Dynamic Configuration of Protocols) [24] and [18].
Da CaPo enables us to configure implementations of
protocol functions of arbitrary granularity to complex
protocols. Naturally, the implementation of a protocol
function corresponds to a component in the binding
framework.
In order to enable flexible and configurable binding
protocols for BF, BM, and BD, we are currently
substituting the original connection manager in Da
CaPo with a more general signalling manager. The
main task of the signalling manager is to start and
terminate signalling modules and to multiplex and
demultiplex signalling packets to be send to,
respectively received from, the peer signalling
manager(s). The signalling itself is performed by the
signalling modules. We use the term signalling in a
broad sense and signalling modules can be classified
into modules for QoS negotiation, QoS mapping,
resource reservation, protocol negotiation, connection
management etc. For each of these classes there are
obviously several possible modules, like unilateral,
bilateral and triangular QoS negotiation. Simple
scripts are used to specify which signalling modules
should be used in the binding protocol (based on
standardized names for the modules) and in which
order they should be executed. The signalling
manager interprets the scripts and instantiates by this
the binding protocols.
Currently, we develop a new multithreaded version of
Da CaPo on top of the real-time micro-kernel
operating system Chorus and RT-Linux to take full
advantage of their real-time support. Furthermore, we
have integrated Da CaPo into the CORBA
implementation COOL such that the MULTE-ORB is
able to negotiate QoS via an extended version of IIOP
called QoS-IIOP, or QIOP, and utilizes optimized
protocol configurations instead of TCP/IP. Figure 7
illustrates the architecture of the MULTE-ORB on top
of Chorus. This prototype is able to implement
binding objects that support QoS and real-time
requirements.
prototype a binding has an associated metarepresentation through which adaptation of the
binding can be preformed.
6
RELATED WORK
There exists considerable amount of research on endto-end QoS support. A survey of the “classical” QoS
architectures can be found in [1]. There are several
areas of related work that are important for our
project and are discussed in the following subsections:
QoS specification, policies, and QoS support in
middleware systems.
6.1 QoS Specification
QML is a recent proposal for a QoS specification
language [11]. The semantics of QML is similar to
our stream and flow type model, and from our
judgement should be capable of specifying quality
properties of stream interfaces. Its applicability has
been demonstrated for operational interfaces only.
The QML work does not consider automatic support
of QoS negotiation from QML specifications.
Quartz is a QoS architecture from Trinity College
[30] with a similar approach to ours regarding the
QoS mapping functionality. Other work that considers
QoS specifications and/or negotiations includes [20],
[3], [7], [35] and [38]. However, the focus of our
work is different. These works do not provide
anything corresponding to a type model of streams
and bindings, including type relationships such as
subtype, compatibility and conformance, and the
derivation of automatic systems support such as QoS
negotiation from high-level interface specifications.
6.2 Policies
Generic Message Protocol
IIOP
QIOP
Generic Transport Protocol
TCP/IP
Chorus
IPC
Da CaPo
(2)
COOL
t i
COOL
Protocol
Da CaPo
(1)
Chorus OS
Figure 5.
Integration of Da CaPo into COOL
The next step in our work is to implement the second
alternative, where Da CaPo additionally configures a
message protocol. The message protocols are then Da
CaPo modules formatting requests for (de-)
marshalling in stubs and skeletons. This alternative is
the basis for a new stream adapter in MULTE.
A first version of open stream bindings based on Da
CaPo has also been implemented [33]. In this
The idea of using policy governed QoS provision and
configurability in middleware is not new. For
example, the Open OODB project [37] applies
policies in extensible database middleware. Policies
have been adopted in a wide spectrum of applications
ranging from QoS management within networks to
security and enterprise modeling (e.g. [31]).
Utility functions have been proposed used as policies
for selection of QoS in multimedia systems [36].
However, it has not been shown how these functions
can be used for policies involving multiple QoS
parameters. In [16], so-called worth based functions
are proposed as policies for QoS negotiation. The
expressiveness for negotiation with multiple QoS
parameters seems to be quite similar to our approach.
However, they consider only negotiation between
client and server, i.e. bilateral negotiation, while our
approach aims at the flexible selection of an
appropriate negotiation schema.
6.3 QoS Support in Middleware Solutions
QoS support in object-oriented middleware is tackled
by several projects with different approaches. The
AMIDST project [2] builds an Object Request Broker
(ORB) which is able to adapt using a feedback control
loop. The ORB is configurable and uses composition
filters to handle different aspects. Also at the
University of California Santa Barbara [15] a realtime ORB is developed that uses feedback control for
resource scheduling.
The ERDOS ORB [32] focuses on QoS-driven
resource allocation and end-to-end QoS using
different models capturing different perspectives, in
order to perform distributed resource management.
The Real-Time CORBA specification (RT-CORBA)
[23] addresses how the ORB ensures end-to-end
predictability with respect to priority propagation,
threading schemes, explicit binding, and protocol
policies and configurations. Explicit bindings are used
according to the CORBA Messaging specification
[22]. In RT-CORBA, policies guide the selection of
protocols, and the configuration of the protocol is
depending on the flexibility and nature of the
protocol. The configurable properties for TCP in RTCORBA include send and receive buffer sizes, keep
alive, and do not route. RT-CORBA does not support
to reconfigure protocols after binding time.
The ReTINA project has summarized requirements
for a multimedia ORB in [5]. The DIMMA project at
ANSA [6] has implemented a real-time, multimedia
ORB. The end system architecture TAO [28] provides
static real-time support for CORBA. The Adapt
project [10] using Ensemble [12] has extended COOL
with configurable protocol stacks for adaptive
multimedia applications. Adapt exploits the open
binding abstraction, but only for stream
communication. GOPI [4] is a generic middleware
platform, which can be extended with new protocols
and new QoS mapping schemes provided by the
programmer. Another flexible ORB is Jonathan [8],
where arbitrary binding mechanisms may be chosen
for the binding between interacting objects.
In order to make the ORB itself configurable
component technology is used in LegORB [27] and
dynamicTAO [17], which are examples of ORBs
combining components with reflection, but both lack
the ability to adapt and re-configure at runtime.
7 CONCLUSIONS
In this paper, we have identified the need for flexible
and extensible QoS support in future middleware
solutions. In the MULTE binding framework, we
support dynamically (re-)configurable open bindings,
as well as flexible scripts for BFs, BMs, and BDs to
create, manage and destroy bindings according to the
application requirements.
In our prototype implementation, we have integrated
the flexible protocol configuration framework Da
CaPo into the CORBA 2.0 implementation COOL.
This prototype allows dynamic (re-)configuration of
bindings. Currently, we are integrating and
experimenting with flexible scripts for BFs, BMs, and
BDs to enable flexible and extensible binding
management.
REFERENCES
[1] C. Aurrecoechea, A. Campbell, L. Hauw, ”A
Review of Quality of Service Architectures”,
ACM Multimedia Systems Journal, Nov. 1995.
[2] L. Bergmans, A. van Halteren, L. Ferreira Pires,
M. Aksit, ”A QoS-control Architecture for
Object Middleware”, accepted at 7th
International Conference on Interactive
Distributed
Multimedia
Systems
and
Telecommunication Services (IDMS 2000),
Enschede, Netherlands, Oct. 2000.
[3] T. Campbell, “A Quality of Service
Architecture.”,
PhD
Thesis,
Lancaster
University, 1996.
[4] G. Coulson, "A Configurable Multimedia
Middleware Platform", IEEE Multimedia, Vol.
6, No. 1, Jan.-Mar. 1999.
[5] Chorus Systems, "Requirements for a Real-Time
ORB", ReTINA, Tech. report RT/TR-96-8, May
1996.
[6] DIMMA Team, "DIMMA Design and
Implementation", ANSA Phase III, Technical
Report APM.2063.01, Sept. 1997.
[7] P. Dini, A. Hafid, “Towards Automatic Trading
of QoS Parameters in Multimedia Distributed
Applications”, IEEE ICODP/ICDP Conference,
Toronto, Canada, pp. 166–179, 1997.
[8] B. Dumant, F. Dang Tran, F. Horn, J.B. Stefani,
"Jonathan: an Open Distributed Procesing
Environment in Java", Middleware'98, The Lake
District, UK, Sept. 1998.
[9] F. Eliassen, S. Mehus, “Type Checking Stream
Flow Endpoints”, Middleware’98, The Lake
District, UK, –Sept. 1998.
[10] T. Fitzpatrick, G.S. Blair, G. Coulson, N.
Davies, P. Robin, "Supporting Adaptive
Multimedia Applications through Open
Bindings", 4th International Conference on
Configurable Distributed Systems (ICCDS'98),
Annapolis, Maryland, USA, May 1998.
[11] S. Frølund,J. Koistinen, “Quality-of-Service
Specification in Distributed Object Systems”,
Distributed Systems Engineering Journal, Vol.5,
No.4, 1998.
[12] M. Hayden, "The Ensemble System", Cornell
University Tech. Report, TR98-1662, Jan. 1998.
[13] J.S. Hill, "Data Exchange, System Architectures
and Structures", Defence Research and
Evaluation
Agency
(DERA),
Naval
Engineering, Volume 33(2), 1991.
[14] ITU-T, “Draft ITU-T Recommendation H.323”,
SG 15 Plenary 28 May, 1996.
[15] V. Kalogeraki, P.M. Melliar-Smith, L.E. Moser,
”Using Multiple Feedback Loops for Object
Oriented Profiling, Scheduling and Migration in
Soft Real-Time Distributed Object Systems”, 1st
IEEE International Symposium on Objectoriented Real-time distributed Computing
(ISORC’98), Kyoto, Japan, April 1998.
[16] J. Koistinen, A. Seetharaman, “Worth-Based
Multi-Category Quality-of-Service Negotiation
in Distributed Object Infrastructures”, The
Second International Enterprise Distributed
Object Computing Workshop, Nov. 1998.
[17] F. Kon, M. Roman, P. Liu, J. Mao, T. Yamane,
L.C. Magalhães, R.H. Campbell, “Monitoring,
Security, and Dynamic Configuration with the
dynamicTAO
Reflective
ORB”,
Middleware'2000, New York, USA, April 2000.
[18] T. Kristensen, T. Plagemann, “Enabling Flexible
QoS Support in the Object Request Broker
COOL”, International Workshop on Distributed
Real-Time Systems, Taipei, Taiwan, April 2000.
[19] R.H. Macdonald, "An integrated architecture
for the CMS for the new Norwegian escort
vessels", FFI 96/04033, Norwegian Defence
Research Establishment (FFI), Aug. 1996.
[20] K. Nahrstedt, J.M. Smith, “The QoS Broker”,
IEEE Multimedia, 2(1), pp. 53-67, 1995.
[21] NATO ANEP-53, "Extension to Shipborne
Open System Environment (SOSE)", Study
report to NATO NIAG SG-52, April 1998.
[22] Object
Management
Group,
"CORBA
Messaging - Joint Revised Submission", OMG
Document orbos/98-05-05, May 1998.
[23] Object Management Group, "Real-Time
CORBA - Joint Revised Submission", OMG
Document orbos/98-12-10, Dec. 1998.
[24] T. Plagemann, ”A Framework for Dynamic
Protocol Configuration”, Dissertation at Swiss
Federal Institute of Technology, Computer
Engineering and Networks Laboratory, Zurich,
Switzerland, Sept. 1994
[25] T. Plagemann, F. Eliassen, V. Goebel, T.
Kristensen, H.O. Rafaelsen, , “Adaptive QoS
Aware Binding of Persistent Objects”,
International Symposium on Distributed Objects
and Applications (DOA’99), Edinburgh,
Scotland, 1999.
[26] H.O. Rafaelsen, F. Eliassen, ”Trading and
Negotiating
Stream
Bindings”,
Middleware’2000, New York, USA, April 2000.
[27] M. Roman, D. Mickunas, F. Kon, R.H.
Campbell, “LegORB and Ubiquitous CORBA,
Workshop on Reflective Middleware at
Middleware’2000, New York, USA, April 2000.
[28] D.C. Schmidt, A.S. Gokhale, T.H. Harrison, G.
Parulkar, "A High-Performance End System
Architecture for Real-Time CORBA", IEEE
Communications Magazine, Vol. 35, No. 2, Feb.
1997.
[29] H. Schulzerinne, R. Casner, R. Frederick, V.
Jacobsen, “RTP: A transport protocol for realtime applications,” IETF, RFC 1889, 1996.
[30] F. Siqueira, V. Cahill, ”Quartz: A QoS
Architecture for Open Systems”,
20th
International Conference on Distributed
Computing Systems (ICDCS’00), Taipei,
Taiwan, April 2000.
[31] M. Sloman, E. Lupu, “Policy Specification for
Programmable Networks”, First International
Working Conference on Active Networks
(IWAN’99), Berlin, June 1999.
[32] J.J. Sydir, S. Chatterjee, B. Sabata, ”Providing
End-to-End QoS Assurances in a CORBABased System”, 1st IEEE International
Symposium on Object-oriented Real-time
Distributed Computing, Kyoto, Japan, April
1998.
[33] K.O. Traa, ”Implementation of open bindings
based on Da CaPo”, Master Thesis, University
of Oslo, 2000
[34] E. Umez-Eronini, “System Dynamics and
Control”, Morgan State University, PWS
Publishing, 1998.
[35] C. Vogt, L.C. Wolf, R.G. Herrtwitch, H. Wittig,
“HeiRAT - Quality of Service management for
distributed multimedia systems”, Multimedia
systems, 6(3), ACM/Springer, pp. 152-166,
1998.
[36] J. Walpole, C. Krasic, L. Liu, D. Maier, C. Pu,
D. McNamee, D. Steere, ”Quality of Service
Semantics for Multimedia Database Systems,”
Database Semantics: Semantic Issues in
Multimedia Systems, ed. R. Meersman, Z., S.
Stevens, Kluwer Academic Publishers, Jan.
1999
[37] D.L. Wells, J.A. Blakely, C.W. Thompson,
“Architecture of an Open Object-Oriented
Database
Management
System”,
IEEE
Computer, Oct. 1992
[38] A. Zinky, D.E. Bakken, R.D. Schantz,
“Architectural Support for Quality-of-Service
for CORBA Objects”, Theory and Practice of
Object Systems, Vol.3, No.1, 1997.