A Control-Based Middleware Framework for Quality of Service Adaptations Baochun Li, Klara Nahrstedt Department of Computer Science University of Illinois at Urbana-Champaign
[email protected],
[email protected]
Abstract In a heterogeneous distributed environment where multiple applications compete and share a limited amount of system resources, applications tend to suffer from variations in resource availability, and are desired to adapt their behavior to the resource variations of the system beyond a minimum Quality of Service (QoS) guarantee. On one hand, current adaptation mechanisms built within an application have the disadvantage of lacking global information to preserve fairness among all applications. On the other hand, an adaptive resource management built within the operating system ignores the data semantics of the application. Hence we believe that a proper adaptive behavior of QoS can be achieved in a middleware framework, having data semantics of the application as well as understanding underlying resource management dynamics. We present a novel control-based middleware framework to enhance QoS adaptations by dynamic control and reconfigurations to the internal functionalities of a distributed multimedia application. Based on a strict model defining QoS metrics, and the Task Flow Model describing the application structure, a Task Control Model is developed based on the control theory. The control theory is applied to the design of Adaptation Tasks to devise control policies for changes of resource requests by individual applications, hence providing graceful degradation or upgrade over a shared resource within a required QoS range, or in extreme cases enforcing reconfiguration process beyond the QoS range. Our assumptions here are that (1) a resource reservation/allocation occurs to preserve the minimal QoS requirement of an application, and (2) not all resource capacity is allocated to reserved service. The adaptation happens over the non-reserved shared capacity. Using this approach, we are able to reason about and validate analytically system attributes such as the stability, agility, fairness and equilibrium values of the control actions over shared resources. Our validation is not only analytical, but also experimental. We have developed an experimental clientserver visual tracking system to evaluate our middleware framework. In order to maintain tracking precision in a specified range, the middleware framework controls the tracking application according to the current system dynamics. We show that our framework improves the adaptive abilities of the application, while the adaptive actions are stable, flexible and configurable according to the needs of individual applications. Furthermore, we show a quantitative improvement of resource utilization in comparison to over-allocation approach when QoS guarantees in range are required. This research was supported by the Air Force Grant under contract number F30602-97-2-0121, and National Science Founda-
tion Career Grant under contract number NSF CCR 96-23867.
1
1 Introduction In a heterogeneous distributed environment, a wide variety of distributed applications demand specific Quality of Service (QoS) from the underlying supporting platform to ensure user satisfaction. Critical qualities that are usually demanded are timeliness, data quality and reliability, other qualities such as security concerns and synchronization between data streams are also occasionally required. In a typical system, it is normally observed that multiple applications compete and share a limited amount of resources. Due to variations in the underlying distributed environment, with respect to resource availability, applications may not be able to receive constant Quality of Service from the system. However, there are a variety of flexible applications that can accept and tolerate resource scarcity to a certain minimum limit, and can improve its performance if given a larger share of resources. If resources above the minimum requirements are shared among all applications, statistical multiplexing gain can be improved. In addition, for the flexible applications that involve interactive activities that cannot be predicted a priori, it may be hard or impossible to specify a maximum demand for QoS beforehand. Based on these observations, it is necessary to support QoS adaptation mechanisms in the system. If we examine the adaptive behavior of applications in a more detailed fashion, it is very natural to map it to an adaptive control system. In a typical control system, there is a target system to be controlled. This target system takes appropriate actions to process the input. The input is determined by a controller according to a control algorithm, which monitors the states inside the target system, and compares them to the desired values referred to as the reference. Similarly, adaptation also needs to identify the current states of the target system based on any parameters that can be observed, and to decide input values to the target system in the future. This paper rigorously models adaptation behavior of a distributed heterogeneous environment, based on its analogy to the above described control system. The application of the adaptive control model on a distributed adaptive system leads to a new Task Control Model. There are two major advantages of this approach: (1) With the Task Control Model we can utilize various adaptive control policies, and rigorously derive and reason about equilibrium, stability and responsiveness properties of these policies using control theoretical techniques. (2) The Task Control Model fits well into the distributed environment, because it allows us to associate various system adaptive mechanisms, such as buffer smoothing, scaling, filtering, prefetching and others, with adaptive control policies in the adaptive controllers. This mapping between the adaptive control policies and adaptive system mechanisms will result in a flexible design and implementation of adaptive middleware. We choose to embed the adaptive policies and mechanisms within a middleware layer because (1) if we build adaptation mechanisms into applications, then the policies and mechanisms will lack the global information to preserve fairness among all applications; (2) if we build adaptation mechanisms into underlying resource management within operating system, then the policies and mechanisms will ignore the data semantics of the applications. The adaptive control policies within the middleware will guarantee equilibrium, stability and responsiveness properties, while the mapping between policies and system mechanisms will guarantee flexible adaptation and reconfiguration of different adaptive behavior. The rest of this paper is organized as follows. Section 2 provides a short overview of related work in this area. The core of the paper consists of Section 3 which presents the control model for QoS adaptation, Section 4 which outlines the middleware framework design, and Section 5 which discusses the experiments and experimental results using the distributed visual tracking. We conclude the paper with Section 6.
2
2 Related Work It has been widely recognized that many QoS-constrained distributed applications need to be adaptive in a certain QoS range between [QoSmin ; QoSmax ] [14], in order to provide a graceful reaction to dynamic resource availability in a distributed environment. Various adaptive mechanisms have been proposed [2] [4] [14, 23, 15]. This work differs from other approaches in the sense that it concentrates on determining adaptive policies, rather than the development of adaptive mechanisms. We use digital control theory to quantitatively determine the states of the adaptive system, and based on these states we activate control algorithms to adapt to the dynamics of the system. Our work is closely related to and utilizes the knowledge of dynamic resource allocations. Other approaches in the adaptive resource allocation area have also been presented in [16] [17]. The work in [16] focuses on maximizing the utility functions, while keeping QoS received by each application within a feasible range. The work in [17] focuses on a multi-machine environment running a single complex application, and the objective is to dynamically change the configuration of the application to adapt to the environment. Our work focuses on the analysis of the actual adaptation dynamics, rather than utility factors. We also focus on an environment with multiple applications competing for a pool of shared resources, which we believe is a common scenario easily found in many actual systems. The essence of a closed-loop control system is its feedback path. Various software and distributed systems utilize feedback information for adaptation purposes [3, 21, 7]. For example, the work presented in [3] uses software feedback mechanisms that enhance system adaptiveness by adjusting video sending rate according to on-the-fly network variations. However, the algorithms used in most of the software systems are heuristic in nature, and the analysis of various adaptation properties such as stability, steady-state fairness and responsiveness is not addressed. In recent research, control theories have been examined for QoS adaptation. In [18], the application of control theory is suggested as a future research direction to analyze adaptation behavior in wireless environments. In [5], a control model is proposed for adaptive QoS specification in an end-to-end scenario. In [7], the time variations along the transmission path of a telerobotics system are modeled as disturbances in the proposed perturbed plant model, in which the mobile robot is the target to be controlled. Our work attempts to apply control theory to analyze the adaptation dynamics in a broader range of applications, and in a more rigorous fashion.
3 A Model for Control-Based Quality of Service Adaptations In this section, our objective is to model Quality of Service (QoS) adaptation and reason about the adaptive properties such as adaptation stability, agility and system equilibrium values. We choose digital control theory as the basis for our modeling framework. Traditionally, digital control theory is applied to industrial control systems in order to perform control actions on various devices such as robots. Our goal is to explore theories and practices in this area within a distributed environment in the domain of end systems QoS adaptations, in order to enable control of QoS over shared system resources such as CPU and/or network. In the next subsections we outline our transformation approach from traditional digital control theories to the control-based middleware framework to provide adaptive QoS.
3.1 The Task Flow Model In order to analyze adaptation behavior of QoS using digital control theory, we need a strict mapping between traditional control systems and the framework to control QoS applications in a distributed environment. For this purpose, we consider each application as an ensemble of functional components, which we 3
refer to as tasks. Tasks are execution units that perform certain actions to deliver a result to other tasks or the end user. With the above definition of tasks, we utilize the Task Flow Model described in [10] and extend the model to address the modeling of adaptation behavior. In this model, the Task Flow Graph is a directed acyclic graph which consists of multiple tasks, and illustrates the consumer-producer dependencies among the tasks. A directed edge from task Ti to task Tj indicates that task Tj uses the output and its QoS produced by task Ti . Tasks can be uniquely characterized by its input QoS, output QoS and utilized resources, influencing the state space of a task.
Live video input Video Camera
Frame Grabber
video capturing Remote Site
Resources Source
T1
T2
T3
Network Transmission of Digital Live Video Data
Visual Tracking Runtime Module
Identification
Visual tracking Local site
User
(a) A Generic Task Flow Graph
(b) Task Flow Graph for a Visual Tracking System
Figure 1: Illustrations of the Task Flow Model for Distributed Environments Figure 1 illustrates a generic Task Flow Graph (1(a)) and its application to a distributed visual tracking system (1(b)), whose objective is to track objects inside a sequence of images captured from a remote site and transferred via a network connection.
3.2 The Task Control Model Based on the Task Flow Model, we present a Task Control Model, which concentrates on one single task in the Task Flow Graph. This task is referred to as the Target Task, which is the task to be controlled over a shared resource. In addition, we introduce an Adaptation Task, which performs the adaptive control algorithm, as well as an Observation Task, which observes the states of the Target Task and feeds them back to the Adaptation Task. The ideal objective of the Task Control Model is to achieve the following properties: (1) The Target Task maintains the same output quality at the desired QoS level, regardless of variations in resource availability; (2) Dynamic changes in QoS requirements can be accommodated in a timely fashion; (3) Fairness is guaranteed among all competing tasks accessing the shared resource. These properties will be satisfied by careful choice of the control policies in the Adaptation Task and by assistance of the Observation Task.
Adaptation Tasks: These tasks implement control policies and modify a set of controllable parameters according to a specific control algorithm. Controllability has a two-fold interpretation. First, a parameter is controllable means that by changing end-system configuration dynamically it is possible to affect its values; Second, it also means that by changing values of a parameter, it is possible to affect the internal states of the task and thus affect the output quality. Task States: In order to control the input quality to achieve the ideal range of the output quality, we need a precise analytical model to characterize the internal dynamics in the Target Task. We refer to the parameters in this model as Task States. The most important task states in any task are its
4
parameters related to its shared resources. All tasks have to consume resources in order to perform actions on input and produce output.
Observation Tasks: Adaptation Tasks need knowledge about the current states of the Target Task, in order to perform the control. If the task states are observable, they are observed by the Observation Tasks and propagated to the Adaptation Tasks. Otherwise, if some related parameters can not be observed, Observation Tasks will estimate or predict the current states, based on the estimation algorithm of its choice.
Figure 2 illustrates the different roles of the Target Task, Adaptation Task and Observation Task in a Task Flow Graph. Once the above notations are established, we are ready to present the Task Control Model based on the control theory. In the most generic fashion, we use the vector for the vector of task states, the vector for the vector of controllable input QoS parameters, the vector for the vector of observed output QoS parameters of the task, the vector for the uncontrollable variations in the task, and the vector for the observation errors. Using the above notations, we model the Target Task in the Task Control Model with the following equations:
s
v
y
ds(t) s_ (t) = f [s(t); u(t); v(t); t] dt y(t) = h[s(t); n(t); t]
u
n
(1) (2)
With the above definition, the task is said to be at equilibrium when:
s_ (t) = 0 = f [s(t); u(t); v(t); t]
(3)
An equilibrium is stable if small disturbances do not cause the state to diverge and oscillate. Otherwise, it is an unstable equilibrium. The above stated definitions are generic and can illustrate a wide variety of adaptation capabilities of the Target Task. According to these definitions, the Target Task may be continuous in time, non-linear and time-varying. In this paper we study a subset, namely, the tasks that can be approximated without loss of accuracy by discrete and linear equations as the following form:
GH
C
s(k + 1) = Gs(k) + Hu(k) + v(k) y(k) = Cs(k) + n(k)
(4) (5)
where , and are constant matrixes. We assume in later examples that the Target Task can be characterized accurately by discrete-time and linear equations in Equation (4) and (5). The Adaptation Task can incorporate two types of control policies, namely Passive Adaptation Control and Active Adaptation Control, which is embedded in Passive Adaptation Tasks and Active Adaptation Tasks, respectively. The ultimate objective of both types of Adaptation Tasks is to maintain a desired stable output Quality of Service of the Target Task. Figure 2 shows the difference between the passive and active adaptation control in the Task Control Model for Target Tasks Ti and Ti+1 . In this graph, uTi and uTi+1 are input QoS parameters, u0Ti and u0Ti+1 are adapted input QoS parameters, yTi and yTi+1 are output QoS parameters, and sTi , sTi+1 are task states. The passive adaptive control algorithm depends on the past and current incoming input QoS parameters uTi to generate the adapted input QoS parameters u0Ti , while the active control algorithm depends on the current incoming input QoS parameters uTi and feedback information about the task states sTi to compute the adapted input QoS parameters u0Ti . 5
Even though Passive and Active Adaptation Control system share the similar control objectives, i.e., they both control the input QoS metrics of the Target Task to achieve better output QoS, the approaches that they adopt for this objective is completely different. Passive Adaptation Tasks operate directly on the input QoS metrics, generating adapted input QoS metrics for the Target Task as a replacement of the original input QoS. With a better input QoS, the output QoS of the Target Task is expected to be better. In contrast, Active Adaptation Tasks do not operate directly on input QoS metrics, instead, they adjust the behavior and semantics of the Target Task itself, such as the values of controllable parameters, or the structural configuration of the Target Task. After enforcing internal adjustments of the Target Task, the input QoS metrics seen by the Target Task are better, which leads to better output QoS from the Target Task. This means that the Active Adaptation Control system generates the adapted input QoS metrics indirectly by performing internal adjustments in the Target Task. Detailed treatment of Active Adaptation Control is given in Section 3.5. Passive Adaptation Control output QoS
Target Task T(i)
Observation
y T(i)
Task
input QoS u T(i+1)
Passive Adaptation Task
adapted input QoS u’ T(i+1)
output QoS
Target Task T(i+1)
Observation
y T(i+1)
Task
Active Adaptation Control input QoS u T(i)
Active Adaptation Task
adapted input QoS u’ T(i)
output QoS
Target Task
y T(i)
T(i)
Observation Task
input QoS u T(i+1)
Active Adaptation Task
adapted input QoS u’ T(i+1)
s T(i)
Target Task T(i+1)
output QoS y T(i+1)
Observation Task
s T(i+1)
Figure 2: Passive and Active Adaptation Control in the Task Control Model
3.3 QoS Metrics In order to accurately model the behavior of Adaptation Tasks, we need to be able to quantitatively measure various input and output QoS parameters. We will present a simplified model for Quality of Service metrics with the objective to measure various QoS parameters in a quantitative way so that each QoS metric can be monitored by the Observation Task. A Quality of Service metric, in its restrictive sense, measures the delivery performance of a continuous stream of data units. In its broader sense, Quality of Service metrics can denote any kind of quality parameters in any measurement units, for instance consistency, completeness or accuracy in a typical query to a digital library. We will only address the restrictive sense of QoS metrics in this paper. However, we believe that our conclusions drawn from examinations on the restrictive sense of QoS metrics are generic and may also apply to any broader contents of Quality of Service. We represent a stream as an ordered sequence S = fdj gj 2I , where dj denotes a distinct data unit, which may in reality be a frame of video data, a packet of data transferred over packet switching networks, or a protocol independent message carried by any transport facility. I is the set of data unit indices, while a stream S is an ordered sequence of data units. Also, we define T as the domain of time instants, which are normally represented by real numbers, and R as the domain of real numbers. For each dj , we assign a distinct Quality of Service Signature j , where j 2 I :
j = hbj ; oj i(bj < oj ; bj 2 T; oj 2 T ) 6
(6)
where bj and oj represent the sending time at the original source of transmission and receiving time at the destination of the data unit dj , respectively. Once the above notions are defined, we are able to define the ordered sequence of QoS signatures. We formally define the ordered sequence S = fj gdj 2S as the Quality of Service Profile of sequence S. Furthermore, the predicates first(S ) and last(S ) denote the indices of the first and last QoS signatures in S , respectively. For example, the expression rfirst(S ) represents the receiving time of the first data unit in the stream S , while the expression slast(S ) denotes the sending time of the last data unit in the stream S . We will also use the expression S [C ] to represent the subset of QoS signatures in S that satisfy the condition C, where C may be any conditional equation. Given the above definitions, a Quality of Service metric consists of a measure computed from the Quality of Service Profiles of one or multiple streams. Formally, it represents a mapping function:
QoS : n 7! R
(7)
QoS : T T n 7! R
(8)
pi < qi; pi 2 T; qi 2 T
(9)
where is the domain of QoS profiles, n represents the dimension of the QoS metric, and R is the domain of real numbers. For example, in the one-dimensional category, the value of QoS (S ) is the result of computing the QoS metric QoS on the Quality of Service Profile S . If in reality we are interested in the QoS metric delay, we will compute delay (S ) based on the QoS Profile S of the stream S . A twodimensional category example is the synchronization skew with skew(A ; V ) based on the QoS Profiles A and V of streams A(Audio) and V (Video). Even though the QoS metrics can be defined as such, it is generally difficult to obtain these metrics strictly as the definitions specified, due to constraints by practical measurement limitations. We thus introduce the notion of approximated Quality of Service metrics, which makes it practical to observe QoS metrics in the Observation Task. Though these definitions can only approximate formally presented definitions shown above, they are normally sufficient for most cases. For approximated QoS metrics, we define a mapping function:
where is the domain of QoS profiles, n is the dimension of the metric, R is the domain of real numbers, and T represents the time domain. To be more specific, we define pi and qi to be time instants and [pi ; qi ] to be time interval so that
where i is an index number. As an example, in the one-dimensional category, if we are interested in the QoS metric delay, we use delay (pi; qi; S ) to compute the average delay of the QoS Profile S in the time interval [pi ; qi]. We may establish multiple time intervals referred to as sampling intervals during the course of QoS delivery, so that we can evaluate an ordered sequence of Quality of Service metric values during each of these time intervals. We will discuss these problems in later sections. For easier references, we summarize the above notations and definitions in Table 1. Given the above definitions, we are able to define the common QoS metrics such as request rate, delay, loss and jitter QoS parameters [13]. We will elaborate on the definition for request rate because we will use this QoS metric as an example of input/output QoS metric when discussing passive and active adaptation control for Target Tasks. Request rate denotes a QoS metric that measures the delivery speed or efficiency of any QoS quantitative data units processed in Target Tasks. Given the definitions for QoS metrics above, request rate represents the mean number of data units per time unit processed or received during the duration of a stream. For this 7
Notation
dj I S bj oj j
S
first(S ) last(S ) S [C ] QoS (S ) QoS (k1 ; k2 ; S )
Definition a data unit of index j the set of data unit indices a stream of data units: S = fdj gj 2I sending time of a data unit dj receiving time of a data unit dj Quality of Service Signature: j = hbj ; oj i(bj ; oj Quality of Service Profile: S = fj gdj 2S the index of the first data unit in stream S the index of the last data unit in stream S the subset of QoS signatures in S that satisfy C QoS metric computed on S approximated QoS metric computed on S
Example a data packet or message integers a regular data stream sending at time 1 receiving at time 2
2 T ) h1; 2i
S [rk 2] delay (S ) delay (k1 ; k2 ; S )
Table 1: A simplified model for Quality of Service metrics purpose, it is useful to define the function quantity: S [C ] 7! N that counts the quantity of data units in a QoS Profile S [C ] under the condition C. For example, quantity (S [k1 a k2 ]) is the number of data units in stream S that are received within the time interval [k1 ; k2 ]. The formal definition of request rate is:
rateS : 7! R rateS (S ) = o quantity?(o S [C ]) last(S ) first(S )
(10)
where condition C can be defined as:
C = ofirst(S ) oj olast(S ) ; oj 2 T
(11)
As stated previously, we measure usually approximate request rate. Given a time interval [pi ; qi ] defined in Equation (9), the definition of approximated request rate can be easily derived as follows:
rateS : T T 7! R (S [C ]) rateS (pi ; qi; S ) = quantity qi ? pi
(12)
where condition C can be defined as:
C = pi o j q i
(13)
In the next subsections, for controllable input QoS parameters u and adapted input QoS parameters u’ defined in Section 3.2, we use a single QoS metric request rate as an example. In the case of passive adaptation, request rate is also observed by the Observation Task.
3.4 Passive Adaptation Control As stated in Section 3.2, the Task Control Model allows passive adaptation control policies to be embedded in the Adaptation Task. We refer to these Adaptation Tasks as Passive Adaptation Tasks. In this subsection, we develop passive adaptation control policies to control the request rate rateS as the input QoS parameter u to the Target Task.
8
3.4.1
Passive Adaptation Control of Request Rate
As illustrated in Figure 2, in the case of passive adaptation control, Observation Tasks measure the output of the previous task(s), which becomes the input QoS metrics of an input data unit stream for the following task(s). Simultaneously, Passive Adaptation Tasks perform the actual adaptation and produce a series of adapted input QoS values with respect to a specific QoS metric, which are fed into the Target Task. Generally, a Passive Adaptation Task is an operator or filter on a particular stream that controls and modifies its QoS Profile. Formally, it is defined as ' : 7! , where '(S ) is any transformation performed on S . As a simple example, '(fhbj ; oj ig) = fhbj ; oj + constig is an adaptation operator, whose only transformation applied on the QoS Profile is to delay the receiving time by a specified amount const. To the extent of this paper, we will only address a specific subset of the Passive Adaptation Tasks defined above, namely, those tasks whose behavior only transforms a specific QoS metric, such as request rate, of a particular QoS profile S (see Equation 12) of a stream S . The result of the transformation is a series of values based on the measuring unit of this QoS metric. By utilizing the definitions for approximated QoS metrics, we can easily compute values for these metrics in the Observation Tasks, based on a sequence of QoS signatures in a specific QoS Profile. If necessary in the Target Task, this sequence of QoS metric values can also be reversely converted to QoS signatures. Figure 3 shows the transformation process between the QoS metric and the sequence of QoS signatures which is described in detail below. Allocated resources
Measurements
Conversion from QoS signature to QoS metrics
input QoS metrics
adapted Adaptation Task
input QoS
Observation Task
Conversion from QoS metrics to QoS signature
Main Task
output Observation QoS Task
Target Task
Figure 3: The role of a Passive Adaptation Task By adapting to the QoS metric request rate, Adaptation Tasks are only able to change the receiving time of each QoS signature, leaving the sending time unaffected. The behavior of these Adaptation Tasks is thus defined to transform the receiving time oj to o0j in all QoS signatures of a QoS Profile according to a predefined set of transformation rules. Formally:
' : 7!
0S = '(S ) = fhbj ; o0j ig; for 8hbj ; oj i 2 S
(14)
In order to reversely convert the QoS metric values to QoS signatures in the Target Task if necessary, we again take the metric approximated request rate as an example, if we apply Equation (12) to an ordered sequence of time intervals pi and qi , a series of discrete-time ordered sequence of values rateS [i] can be computed in the Observation Task, based on the QoS Profile S . For the most frequently used case of consequent time intervals where qi = pi+1 , we can take a sequence of rateS [i] and convert it to a QoS Profile S whose request rate is identical or approximated by the sequence rateS [i]. Formally: quantity(S [p1
oj pi]) =
In any Quality of Service signature in Equation (14), we have:
i X
(qj ? pj )rateS [j ](pj ; qj ; S )
j =1
(15)
hbj ; o0j i in the Quality of Service Profile 0S [p1 oj qn] defined 9
o01 = o1
o0j = o0j?1 + quantity(q0i [?p pi o0 q ]) = o0j?1 + rate [i](p1 ; q ; 0 ) ; if pi o0j qi i i i S j S i S
(16)
We now have sufficient grounds to apply theories in digital control systems to model the transformation process. Because of the limitations in measurements, the original values rateS [i] are a series of discretetime values, or signals at time points i, rather than continuous-time signals. Formally, the original values of QoS metrics rateS [i] can be represented by a function rate(nT ), where T is a constant sampling interval and n is an integer in the range (n1 ; n2 ) such that ?1 n1 and n2 1. The transformation process defined above is illustrated by the block diagram in Figure 4. Input rate(nT ) and adapted input rate0 (nT ) are generally referred to as the excitation and response signals of the transformation, respectively. In their original senses, input rate(nT ) is the original ordered sequence of rateS [i] of a specific QoS profile, and adapted value rate0 (nT ) is the transformed response series rate0 S [i], corre0 sponding to the transformed QoS Profile S according to Equation (16). rate(nT)
Transformation Process
(excitation)
rate’(nT) (response)
Passive Adaptation Task
Figure 4: Applying adaptation process to the input QoS metrics of the Target Task Obviously, the response is related to the excitation by some rule of correspondence. We can indicate this fact notationally as:
rate0(nT ) = rate(nT )
(17)
where is an operator. Equation (17) can be treated as a generic definition for Passive Adaptation Tasks. Like other digital systems, Passive Adaptation Tasks can be classified with respect to time-invariance, causality, linearity and recursiveness [20]. In this paper, we only address the analysis and configuration of a subset of tasks that are time-invariant, causal, linear, and non-recursive. We characterize this subset with difference equations [11]. Assuming the above, we can express Equation (17) as a Nth-order linear difference equation as Equation (18), where rate(nT ) is represented alternatively as rate(n):
N
X rate0(n) = ai rate(n ? i) i=0
(18)
where ai are significance weights given to past input values rate(n ? i). In our notation used to define P 0 the Task Control Model introduced in Section 3.2, u0 (n) = N i=0 ai u(n ? i), with u (n) as adapted input QoS parameters, and u(n ? i) as past input QoS values. 3.4.2
Reasoning about Adaptation Agility
Passive adaptations, as formally presented in the previous section, are in essence some form of transformations, so that the quality of a specific metric may improve. The series of QoS metric values are modeled by discrete-time values, or signals, and the transformation can be modeled by difference equations as in Equation (18).
10
One of the important factors that should be configurable for Adaptation Tasks is adaptation agility. First introduced in [18], it is defined as the ability of Adaptation Tasks to promptly respond to sudden and unexpected perturbations in the time domain. If the agility of an Adaptation Task is high, it means that the task frequently and promptly reacts to short term fluctuations. On the other hand, a system shows low agility if it only reacts to long term moving trends in the changes of a specific metric, and eliminates most of the short term fluctuations. Obviously, systems of low agility are often desired for most applications, as short term fluctuations naturally need to be eliminated. However, a system that has very low agility may consume too much temporary resources such as buffer spaces in order to transparently adapt to most of the fluctuations in the excitation signals and keep the response undisturbed, the amount of temporary resources may not be readily available on the end system. This tradeoff decision should be left to the application as an important part of the QoS specification. An illustration for the concept of adaptation agility is shown in Figure 5. original input in the time domain
original input in the time domain
adaptor with a higher agility
adaptor with a lower agility
Figure 5: Adaptation agility for configurable Passive Adaptation Tasks Utilizing theories in control systems, It is easy to quantitatively express the frequency spectrum of the excitation signal and the frequency response of the transformation by analyzing the adaptation process in the frequency domain, and by applying a Discrete Fourier Transform without energy loss of the signal 1 . Figure 6 shows the complete transformation process. Allocated resources
Conversion from QoS signature to QoS metrics
input QoS metrics
Conversion from Time Domain to Frequency Domain
Adaptation
Conversion from Frequency Domain to Time Domain
adapted input QoS
Conversion from QoS metrics to QoS signature
Adaptation task Measurements Observation Task
Observation Task
output
Target
QoS
Task Target Task
Figure 6: Complete Transformation Process with the Passive Adaptive Task Once we are able to model signals and transformations in the frequency domain, we can model the adaptation functionality that filters the rapid perturbations and high frequency short-term fluctuations from the long-term trends of changes in the excitation signal. This filtering capability can be best expressed in the frequency domain as a low pass filter, the transformation of which screens the incoming frequency spectrum and only passes low frequency components, eliminating all high frequency components of the signal. The time-domain effects of this transformation is that all the high frequency short-term perturbations are eliminated to stress the long-term low frequency changes, which is precisely the desired adaptation effects for the Passive Adaptation Tasks. 1 Note that the transformation from time domain to frequency domain occurs after QoS signatures are transformed to the sequence of QoS metrics (e.g., rate[i]).
11
H( Ω) 1.0
- Ω off
passband
Ω off stopband
Ω
Figure 7: An ideal low-pass Passive Adaptation Task with cut-off frequency off Given above, the adaptation agility of a Passive Adaptation Task can be defined as the cut-off frequency
off of the frequency response of the transformation, illustrated in Figure 7. Defined as such, we can therefore configure the Adaptation Task to provide a specific agility specified by the application. Once the theories in digital control systems are applied, there are numerous ways to configure and design the Passive Adaptation Tasks so that they conform to a certain agility requirement. One of the simplest approaches that works on non-recursive difference equations is the application of Discrete Fourier Transform and its inverse transform, which may be found in some references on digital filters [11]. In order to improve the quality of the generated result after Inverse Fourier Transform, we may need to use more complex windowing functions such as the well known von Hann window or the Hamming window [11]. Since the configuration process operates in the frequency domain, we need to convert the result back to time domain in the form of difference equations. After the Passive Adaptation Tasks are configured, they can be activated to perform the specified adaptation agility.
3.5 Active Adaptation Control As stated in Section 3.2, The Task Control Model also allows Active Adaptation Control policies to be embedded in the Adaptation Task. We refer to these Adaptation Tasks as Active Adaptation Tasks. In this subsection, we develop active adaptation control policies to control the behavior of the Target Task, based on task states feedback observed by the Observation Task. The Task Flow Model stated in Section 3.1 can characterize a wide variety of tasks. We will demonstrate active adaptation on the following scenario: Let us assume multiple tasks competing for a shared resource pool with the capacity Cmax . Each task makes requests for resources in order to perform their actions on inputs with input qualities and produce outputs with output qualities. These requests may be granted or outstanding. If a request is granted, resources are allocated immediately. Otherwise, the request waits in the outstanding status until it is granted. The system is granting requests from multiple tasks with a constant request granting rate c. The mapping between the abstract notation resource requests and the actual services processing the resource requests varies among different types of system resources. For temporal resources, such as processing bandwidth and transmission throughput, where the resources are shared in a temporal fashion, outstanding resource requests may be mapped to the waiting queue, and granted requests may be mapped to allocated temporal resources, such as bandwidth. For spatial resources, such as volatile or non-volatile storage capacity, outstanding requests may be mapped to the actively used and occupied capacity, and granted requests may be mapped to the reclaimed capacity by the system due to inactivity. The active adaptation framework presented in this section applies to both cases. Figure 8 illustrates the above scenario and a comparison between the classic control and Active Adaptation Control. Naturally, if the Target Task is greedy and makes an excessive number of resource requests in a short period of time, it is not fair to other tasks sharing the same resource pool. Thus, the request rate need to be throttled by the Adaptation Task. What the Active Adaptation Task tries to control is the resource request rate made by the Target Task, so that it does not exceed its fair share. In this scenario, we define the following notions for the system with a Target Task Ti : 12
control input Reference
Error
Controller
disturbance Plant
Output
Input
Throttled Value Reference Input Adaptation Task c u(k) x (k)
Outstanding Requests x(k) r(k) New Resource Requests Target Task
Feedback Path
c
Shared Resource Pool Observation Task
Output
x(k) (observed)
Feedback Path
Figure 8a: A block diagram in a classic control system
Figure 8b: Active Adaptation Control System
Figure 8: A Comparison between a classic control system and the Active Adaptation Control System 1. tc is a constant sampling time interval, which is the time elapsed in interval instants;
[k; k + 1], k being time
[k; k + 1]; ri(k) is the actual number of requests made by Ti in [k; k + 1]; ui(k) is the allowed number of requests in [k; k +1] allowed by the Adaptation Task of Ti to enter the
2. c is the number of granted requests in interval 3. 4.
outstanding queue, which is referred to as the adapted request rate. 5. 6. 7. 8. 9. 10.
x(k) 2 is the total number of outstanding resource requests made by all tasks at time k; xc(k) is the reference value for expected number of outstanding resource requests in interval [k; k +1]; M (k) is the total number of active tasks competing for resources in the system; A(k) is the set of tasks at time k whose request rate is throttled by their respective Adaptation Tasks, N (k) is the set of other tasks that are not affected by the Adaptation Tasks; l(k) is the number of tasks in A(k), M (k) ? l(k) is the number of tasks in N (k). We assume that both M (k ) and l(k ) stays constant within one time interval [k; k + 1]. wi is the static weight of Ti showing its relative priority or importance compared to other tasks.
As mentioned in Section 3.2, unlike Passive Adaptation Tasks, Active Adaptation Tasks enforce desired and stable output QoS of the Target Task by enforcing internal adjustments. Thus, ui (k ) in this subsection represents the adapted resource request rate of task Ti , which is different in meaning from uTi , representing the input QoS metric parameters. Using the above notation, the derivative of outstanding resource requests can be described as follows:
x_ = x(k) ? x(k ? 1) =
MX (k?1) i=0
ui(k ? 1) ? c
(19)
The Difference Equation (19) depicts the internal dynamics of the adaptive system and it is a concrete example of the Equations (1) and (4). The objective of the control is to maintain the number of outstanding requests x to stay around a specific reference value xc (k ). Under the assumption that the dynamics of the active adaptive system behave according to Equation (19), we can derive a control algorithm/policy in the Adaptation Task for Ti to calculate 2
Note that ri (k), c, and x(k) contribute to the internal task states s as introduced in Section 3.2.
13
adapted input QoS ui (k ) values, which will lead to the desired values for x. For example, if a standard proportional-integral-derivative (PID) control [6] 3 is engaged, then ui (k ) obeys the equation
ui(k) = ui(k ? 1) + [xc(k) ? x(k)] + f[xc(k) ? x(k)] ? [xc(k ? 1) ? x(k ? 1)]g (20) where and are configurable scaling factors. This is one of the many effective control algorithms illustrating the ability of the Active Adaptation Control Model to capture the adaptation dynamics and map these dynamics onto a classic control model.
3.6 Reasoning about Equilibrium, Stability, Fairness and Adaptation Agility This section continues with a rigorous analysis of the equilibrium, stability, fairness and adaptation agility properties of the Active Adaptation Control Model characterized by the Target Task in Equation (19) and the PID control algorithm in Equation (20), in order to prove the validity of our approach using this model. We assume in our analysis that the controllable parameter of task Ti is the request rate ri (k ). The Adaptation Task may control ri (k ) at a lower rate ui (k ), namely, ui (k ) ri (k ). The PID control algorithm presented in Equation (20) becomes:
ui(k) = ri(k) f ui(k ? 1) + (xc(k) ? x(k)) + [(xc (k) ? x(k)) ? (xc(k ? 1) ? x(k ? 1))] g (21) Where t (x) is defined as: 8 > < 0 if x < 0, (22) t(x) = > t if x > t, : x otherwise. In addition, since at time k we assume that, among all tasks, l(k ) tasks are throttled by their respective Adaptation Tasks, and M (k ) ? l(k ) tasks are not affected, we conclude that the total number of outstanding resource requests in the system shows the following dynamic property, which is an extension to Equation (19):
8 9 < = X X x(k) = Cmax :x(k ? 1) + ui(k ? 1) + ri(k ? 1) ? c; T 2A(k?1) T 2N (k?1) i
(23)
i
= Cmax fx(k ? 1) + l(k ? 1)u(k ? 1) + R(k ? 1) ? cg , where X R(k) = ri(k), and Ti 2N (k)
(24) (25)
ui(k) = i (k) l(k) u(k) (26) (k) is the average rate for all ui(k) that satisfies ui(k) < ri(k). In this equation,
i(k) is the where u P dynamic weight of task Ti which indicates priority for resource requests, and satisfies Ti 2A(k) i (k ) = 1. The dynamic weight of Ti can be derived from the static weight wi of Ti , with the following calculation:
i(k) = P wi w (27) Tj 2A(k) j 3
PID control is a classic control algorithm where the control signal is a linear combination of the error, the time integral of the error, and the rate of change of the error.
14
Combining Equation (21) and Equation (24), we obtain the complete characterization of the adaptation system. Associated with each task Ti , we have a static weight wi , and three internal task states:
T
si (k) = xc(k) ? x(k); xc(k ? 1) ? x(k ? 1); i (k ? 1) l(k ? 1) [u(k ? 1) ? c ?l(Rk (?k 1)? 1) ]
(28)
Where xc (k ) and c?l(Rk()k) are the equilibrium values of x(k ) and u k , respectively. The detailed analysis of the equilibrium states is given in Section 3.6.1. 3.6.1
Equilibrium Analysis
Now that we have established the control algorithm in the Adaptation Task, we start to analyze the exact value that the system stays at equilibrium. The ideal case is that x(k ) always stays the same as the reference xc(k). Let us assume that for a specific period of time [k1 ; k2 ], xc(k), l(k), M (k) and R(k) are all stable and stay at constants xcs , ls , Ms and Rs , respectively. Then we show the following properties: Theorem 1: Within [k1 ; k2 ], the number of outstanding resource requests x in the system, established by Equation (21) and (24), will converge to an equilibrium value which equals to the reference value xcs . In addition, the system also fairly shares resources among competing tasks according to their static weights. s be the equilibrium values corresponding to the system established by Equation Proof: Let xs and u (21) and (24).
xs = Cmax fxs + lsus + Rs ? cg
i ls us = ri f i ls us + (xcs ? xs)g
(29) (30)
Ignoring the threshold cases, the solution to Equation (29) and (30) is
us = c ?l Rs
(31)
s xs = xcs
(32)
Equation (32) directly proves the first part of the theorem. Assume the stable set of throttled tasks is As , Equation (31) can be rewritten for task Ti at equilibrium as follows:
(
)
(Ms ? ls) Mcs ? Rs c ? R w l c w l s i s i s =P + (ui )s = i ls us = P (33) ls Tj 2As wj ls Tj 2As wj Ms Equation (33) presents the following weighted max-min fairness property. Each task Ti can be granted at least a wi share of the resources; In addition, if Ms ? ls tasks request less than their fair share, namely, only ls tasks are adapted, then the free portion (MsM?sls)c ? Rs can be distributed among those who are throttled and thus need these resources, according to their static weights, which identify their relative priority and importance. This concludes the proof. 2
3.6.2
Stability Analysis
The concept of stability has a two-fold meaning. First, in an environment of multiple tasks simultaneously sharing the limited availability of resources, the ensemble of the adaptation activities in all tasks need to be stable, which means that when the number of active tasks is fixed, system resources allocated to each task settle down to an equilibrium value in a definite period of time. This definition also implies that, if a 15
new task becomes active, existing active tasks will adjust their resource usage so that after a brief transient period, the system settles down to a new equilibrium. Second, stability implies that with respect to variations in resource availability due to unpredictable and physical causes, for example a volatile wireless connection, adaptation activities do not suffer from oscillations, which are undesirable because they cause both fluctuations in user-perceptible qualities, and an excessive amount of adaptation attempts that may occupy too much resource to overload the system. In order to converge to the equilibrium of the system regardless of disturbances and statistical multiplexing, we need to prove that the system is stable. Due to the nonlinear nature of the system given by Equation (21) and (24), we are unable to derive a global and absolute stability condition, which is the case for most systems with nonlinear properties. However, formal conditions for local asymptotic stability can be addressed analytically. We present the following theorem related to local asymptotic stability conditions. Theorem 2: The Active Adaptation Control system established by Equation (21) and (24) is asymptotically stable for task Ti around a local neighborhood, under the condition that > 0; > 0, and + 2 < 4 i . Proof: Given the states defined in Equation (28), we define
e(k) = xc(k) ? x(k) u^i(k) = i l(k) [u(k) ? c ?l(Rk)(k) ]
(34) (35)
In order to examine the asymptotic stability properties, we simplify the dynamic equations (21) and (24) in the neighborhood of equilibrium by: (1) removing the nonlinearities introduced by t (x) at both thresholds; (2) treating l(k ) and R(k ) as constants in the neighborhood of the equilibrium. Thus, Equations (21) and (24) become: u^i (k) = u^i(k ? 1) + e(k) + [e(k) ? e(k ? 1)] (36)
x(k) = x(k ? 1) + 1 u^(k ? 1)
(37)
1 [( + )z ? ] D ( z ) G ( z )
i i Fi (z) = 1 + D (z)G (z) = 2 i i i z + ( i + i ? 2)z ? ( i ? 1)
(38)
i
We perform z-transform on Difference Equations (36) and (37) to obtain Di (z ) and Gi (z ), respectively. Thus, the transfer function Fi (z ) of the entire system is [6]:
We then consider the discrete characteristic equation of the above:
z2 + ( + ? 2)z ? ( ? 1) = 0 i
i
i
(39)
According to theorems in the digital control theory [6], in order for the system to be stable, all roots of Equation (39) need to be within the stability boundary, which is the unit circle. In other words, for any root z, we need jzj < 1. It can be proved that this property holds if the following condition is valid (the proof is omitted for space limitations): > 0; > 0; and + 2 < 4 i (40)
Equation (40) concludes the proof. 2 It is obvious to see from Theorem 2 that the asymptotic stability of the adaptation for task Ti is determined by an appropriate choice of and . It then follows that in order to guarantee that the entire system is stable, we need to choose and so that for any task Ti with any static weight values wi , stability is ensured. 16
Corollary: There exist appropriate values of parameters and so that all the tasks in the system are stable, for any pre-determined static weight wi for task Ti . Proof: Assume wmin is the minimum value among all pre-determined wi . and can be chosen to satisfy > 0; > 0; and + 2 < 4 Pwminw < 4 P wi w ; 8i; k (41) 8i i Tj 2A(k) j It follows from Theorem 2 that if these conditions hold, the system will be stable for any task Ti with a static weight wi . 2 3.6.3
Configuration of Adaptation Agility 20
20 average total outstanding requests Task i
average total outstanding requests Task i
15 Number of Resource Requests
Number of Resource Requests
15
10
5
10
5
0
0 0
100
200
300
400
(a) = 1;
500 k
600
700
800
900
1000
0
100
= 0:09
200
300
400
(b) = 0:1;
20
500 k
600
800
900
1000
= 0:45
20 average total outstanding requests Task i
average total outstanding requests Task i
15 Number of Resource Requests
15 Number of Resource Requests
700
10
5
10
5
0
0 0
100
200
300
400
500 k
(c) = 0:015;
600
700
800
900
1000
0
= 0:5
100
200
300
400
(d) = 0:7;
500 k
600
700
800
900
1000
= 0:25
Figure 9: Illustrations of Configurable Agility and Dynamic Responses In addition to stability requirements, It is also desired that the system responds quickly to changes in both resource availability and QoS requirements of the tasks. Adaptation agility is determined by the configurable parameters in control algorithm. In the case of a PID control algorithm in Equation (21), and are configurable as long as the stability conditions in Theorem 2 hold. The actual configuration is tailored to the needs of the system. 17
Four illustrations are given in Figure 9(a) - 9(d) to show the effects of different configurations on the system. In all four graphs, we simulated the system established by Equation (21) and (24) for 1000 time intervals. The changes of l(k ), R(k ) and xc (k ) are given in Table 2: Time k
l(k) R(k) xc(k)
0-100 2 3 9
100-200 2 3 11
200-300 4 3 11
300-400 5 3 11
400-500 3 3 11
500-700 3 7 11
700-850 3 4 11
850-1000 3 4 14
Table 2: The values of l(k ), R(k ) and xc (k ) used in the illustration It can be seen from these illustrations that the dynamics of the system is affected significantly by different configurations of the Adaptation Task. In Figure 9(d), it even starts to oscillate in the interval [300; 400]. The configuration in Figure 9(b) reaches equilibrium much faster than Figure 9(c), and both of them do not show the oscillating transient response shown in Figure 9(a). Overall, the illustrations show that the Adaptation Task is configurable according to the needs of the system. For the PID control algorithm in Equation (21), there are two parameters to configure. However, for more complex control algorithms, there will be more dimensions for finer tuning of the transient responses.
3.7 Active Adaptation Control in a Distributed Environment We proved that the control theoretical approach presented in Section 3.6 is stable, fair to all participating tasks and configurable with respect to adaptation agility. However, this approach is only applicable when the Observation Task can observe full system states, and feed them back to the Adaptation Task in a timely fashion. This is true if the Target Task utilizes local resources only, such as local processing power and local storage capacity. However, in a distributed environment, there may be cases that tasks share global resources in a distributed fashion. This renders it hard or impossible for the Observation Task to locate and observe full system states information. In one example, the Target Task is a transmission task, which relocates data between different sites in a distributed environment. The resource it uses is transmission throughput, and it is shared by other tasks. The quantity and behavior of these tasks may be unpredictable and unknown to the Observation Task. In the approach proposed in previous sections, the Observation Task needs to provide x(k ), which is the total number of outstanding requests for all tasks. This is naturally impossible given an unpredictable distributed environment. The Active Adaptation Control Model still applies to this scenario. However, the fairness property cannot be guaranteed for the lack of global state information. In order to demonstrate this statement, we take the example that the transmission task is in charge of transmitting data between two end systems. By analyzing this example we conclude that the same PID control algorithm in Section 3.5 can still be applied, i.e. it preserves equilibrium and stability properties. Only the model for the Target Task needs to be slightly modified. We assume that the transmission throughput allocated to the transmission task, Ti , is not fixed and will vary according to the global state of the distributed environment, such as activities of other tasks sharing the same resource. Rather than considering x(k ) as the total number of outstanding requests for all tasks, we consider x(k ) as the number of outstanding requests made by task Ti . This is the number of data units in flight in Ti before reaching destination and its Target Task Tj . Figure 10 shows the Active Adaptation Control in a distributed environment. Assume u(k ) is the number of new requests made in Ti for resources. This is modified by the Adaptation Task, if necessary, in order to control Ti so that x(k ) stays at the reference value xc (k ). Also assume c(k ) is 18
Source Active Adaptation Task
u(k)
Destination
Sending Target Task T(i)
Receiving Target Task T(j)
Active Adaptation Task
Observation Task
Observation Task
x(k) Network
c(k-p max )
Figure 10: Active Adaptation Control in a Distributed Environment the number of granted requests in [k; k + 1]. Because allocated throughput for Ti varies, c(k ) will change accordingly. In implementation, u(k ) can be mapped to the number of data units sent into the transmission path in [k; k + 1], and c(k ) can be mapped to the number of data units sent to the destination in [k; k + 1]. We now can give the equation characterizing the Target Task Ti :
x(k) = x(k ? 1) + u(k ? 1) ? c(k ? 1)
(42)
In order to apply the PID control algorithm proposed in Section 3.5, we need the Observation Task for Target Task Ti to estimate local x(k ) and the Adaptation Task to adjust local x(k ) based on the feedback from the destination (Observation Task for Task Tj ). Implementation-wise, there are various mechanisms to solve this problem, such as the utilization of resource management cells in an ATM network. We take one of the solutions as an example. Assume that the destination acknowledges all the received data units to the source, and assume E (k ) is the total number of data units unacknowledged at source at time k . In addition, assume that pmax equals to the maximum propagation delay of one data unit between source and destination in either direction. Assume that the Observation Task at the destination sends the number of granted requests at the destination as feedback information to the source Adaptation Task, where the number of granted requests at the destination can be defined as
k?d pmax e
Xtc p max c(i) c^(k ? d t e) = c i=k?d 2pmax e
(43)
xlocal (k) = E (k)
(44)
tc where tc is the constant sampling time interval. The right side of this equation illustrates the number of pmax received data units in the interval [k ? d 2ptmax c e; k ? d tc e]. With these assumptions, we can estimate local x(k ) in the Observation Task at source by:
xlocal (k) represents the total number of unacknowledged data units which are either in flight from source to destination, or received by destination, but not acknowledged. Equation (44) characterizes the local Observation Task. The Adaptation Task adjusts x(k ) based on xlocal (k ) and the remote feedback from the destination as follows: x(k) = xlocal (k) ? c^(k ? d pmax t e) c
(45)
The PID control algorithm for the Adaptation Task can thus be given as:
u(k) = u(k ? 1) + e(k) + [e(k) ? e(k ? 1)], where 19
(46)
e(k) = xc(k) ? x(k)
(47)
Equations (42) and (46) fully characterize the adaptation system. We have the following theorems about equilibrium analysis and asymptotic stability around a local neighborhood. Theorem 3: Within the time interval when xc (k ) remains at a constant Xsc , the number of data units in flight x in the system established by Equation (42) and (46) will converge to an equilibrium value which equals to the reference value xcs . In addition, u will converge to an equilibrium value which equals to c. Proof: Let xs , us and cs be the values at equilibrium of x, u and c. We then have
xs = xs + us ? cs ) us = cs and us = us + [xcs ? xs] + [xcs ? xs ? (xcs ? xs)] ) xs = xcs Equations (48) and (49) conclude the proof. 2
(48) (49)
Theorem 4: The adaptation system established by Equation (42) and (46) is asymptotically stable for task Ti around a local neighborhood, under the condition that > 0; > 0, and + 2 < 4. ^(k) = u(k) ? cl , we have Proof: Around a local neighborhood, assume c(k ? 1) = c(k ) = cl . Let u
u^(k) = u^(k ? 1) + e(k) + [e(k) ? e(k ? 1)] x(k) = x(k ? 1) + u^(k ? 1)
(50) (51)
Equations (50) and (51) are identical to Equations (36) and (37). The proof follows from Theorem 2. 2 To conclude, we believe that the Task Control Model still yields asymptotic stability and agility configurability, despite of incomplete task state information. It is possible to apply the same PID control algorithm in the Adaptation Task to these situations, if the models for the Target Task and Observation Task are appropriately established.
4 A Control-Based Middleware Framework The work in this section associates values obtained by control theoretical approaches in the Task Control Model presented in Section 3 with the relevant control actions and adaptation mechanisms with respect to the applications. We propose a framework of software control components in the middleware layer to activate these control actions and mechanisms. In this section, we first discuss the different category and degrees of controllability of an application, then show the design of our framework for middleware control, and finally analyze in greater details the internal algorithms used in the Middleware Control Framework.
4.1 Controllability of Applications The ideal objective of QoS adaptation is to adapt the application behavior with the presence of resource availability variations and application QoS requirement changes. Utilizing the Task Control Model, the Observation Tasks and Adaptation Tasks are in charge of observing current system variations and determining the optimal state of the application according to a control algorithm, respectively. On the other hand, it is the responsibility of another type of middleware components, which we refer to as Enforcement Tasks, to follow adapted request rate values ui (k ) determined by the Adaptation Tasks and activate appropriate control actions or adaptation mechanisms directly affecting the application behavior. In the Task Control Model, the Enforcement Task can be treated as a part of the Target Task, which accepts adapted request rate values ui (k ) from the Adaptation Task and decide control actions based on these values. The Enforcement Tasks can only enforce appropriate control actions when the application is controllable. Controllability has a two-fold meaning. First, it means that the behavior of the application can 20
be modified by external forces, in our case the Enforcement Tasks; Second, it means that the changes in the application behavior will lead to changes in the resource requirements made by the application. With this definition of controllability, it is possible to change resource requirements by each application by directly enforcing control actions on the application. There are two ways that the application can be controllable. First, an application can be quantitatively controllable, which means that the behavior of the application can be parameterized, and one or more parameters that characterize the behavior can be scaled on the fly during execution time. For example, in the Visual Tracking Example mentioned in Section 3, both the frame size of the tracking window and the frame rate that the frame grabber generates are controllable parameters of the application, so the Visual Tracking application is quantitatively controllable with regards to frame size and rate parameters. Second, an application can be reconfigurable. As noted in Section 3, in the Task Flow Model, an application is modeled as an ensemble of tasks with their topology modeled by the Task Flow Graph. In this graph, a directed link from task Ti to Tj shows that the result of Ti is the input of Tj . We define reconfigurability as the ability to change the topology of the Task Flow Graph of all tasks in an application. If the application is reconfigurable, it is possible to remove existing tasks, include additional tasks, or change the topology of the Task Flow Graph for existing tasks. Figure 11 illustrates the reconfiguration process of an application, again taking the distributed Visual Tracking application as an example. In this case, the Visual Tracking application is said to be reconfigurable. Frame Digitization
Image Compression
Image Encryption
Camera Orientation Control Remote Frame Capturing Server
Frame Transmission
Control Transmission Transmission Network
Image Decryption
Object Identification
Image Decompression
FrontEnd Feedback
Visual Tracking
User Specification of Tracking Objects
Local Visual Tracking Client
Figure 3a: The distributed Visual Tracking application: Before Reconfiguration Process Frame Digitization
Frame Transmission Remote Frame Capturing Server
Transmission
Visual Tracking
Object Identification Local Visual Tracking Client
Figure 3b: The distributed Visual Tracking application: After Reconfiguration Process
Figure 11: The Reconfiguration Process of an Reconfigurable Application We argue that the reconfiguration process is closely related to the adjustments of quantitatively controllable parameters. At most times the Target Task should be quantitatively controlled by the Enforcement Task by adjusting its quantitatively controllable parameters. However, when this approach cannot maintain a stable output QoS within a certain range for the Target Task, it is often desired to adopt a more drastic approach of reconfiguration to bring the Target Task back to a certain stable output QoS range. In summary, the purpose of controlling the application, either by quantitatively controlling its parameters or by reconfiguring the topology of the Task Flow Graph, is to control the resource demands of the application with respect to various resource types of concern. It is the responsibility of the Enforcement Tasks to control the applications, following adapted request rate values established by the Adaptation Tasks (Figure 2). In this scenario, we assume that the application to be controlled is either quantitatively controllable or reconfigurable.
21
4.2 Design of the Middleware Control Framework We propose to build our three major tasks, namely the Adaptation Tasks, Observation Tasks and Enforcement Tasks, as components into a coherent framework located in the middleware layer. The advantage of introducing our control framework within the middleware layer is that all the tasks in this framework can have knowledge of both applications and underlying systems. With knowledge of applications the Enforcement Tasks can enforce adaptation policies and algorithms in applications, and with knowledge of the system the Observation Tasks can observe the current states of the system and provide this information to the Adaptation Tasks for processing. Figure 12 shows the architecture of our framework. Application Level
Controllable Distributed Application
Application Task 1
Service Enabling Platform for heterogeneous environments Service Enabling Platform (CORBA)
Application Task 2
Application Task 3
(e.g. CORBA, Real-time CORBA, DCOM, COM+)
System States
(all interaction through service enabling platform)
control policies Middleware Control Components
System Level
Adaptation Task (Control Algorithm)
Enforcement Task Target Task
Enforced Control Actions
Observation
Observation
Task
and monitoring
Operating Systems with Resource Management [CPU scheduling, memory allocation and transport protocols]
Figure 12: The Architecture of the Middleware Control Framework within the End System Our objective is to enable support by the Middleware Control Framework for a wide range of distributed applications, written in different programming languages and using different OS, transport protocols and resource management schemes. This is made possible by building our control tasks beyond a distributed service enabling platform for heterogeneous environments, for example CORBA [22], Real-time CORBA [19] DCOM [1] or COM+ [12]. We do not intend to extend the services of these available enabling platforms, our control tasks are built to use the services provided by them. These control tasks interact with each other and with the application tasks through the enabling platforms such as CORBA, so that heterogeneity with respect to implementation languages and OS platforms is solved by the service enabling platform, and does not remain to be a concern with the middleware control framework. This relationship is also illustrated in Figure 12. Since our proposed middleware control framework interacts with the applications only through services provided by the service enabling platform, there are no limitations on the behavior of the application. For example, the application can implement all communication between servers and clients using traditional TCP or UDP sockets; or, as an alternative, by using RPC calls. In both cases, the middleware control framework will still support the application as long as it is controllable. Another advantage of implementing all control interactions through service enabling platforms such as CORBA is to make it possible for the application tasks and middleware control tasks to physically run on different end systems. The transparency provided by the service enabling platforms makes sure that tasks running on different end systems interact with each other in the same way as if they are on the same end system. However, due to the performance tradeoff introduced, we only consider the case when different end systems run on a local area network or similarly fast network technologies. Figure 13 shows a global view with the middleware control framework in place. To conclude, our middleware control framework operates on the basis of service enabling platforms such as CORBA, handles internal interaction and interaction with applications through the services provided by underlying service enabling platforms, and puts no limitations on the specific implementations of applica22
Application: Server implementation
Application: Client implementation
Middleware Control Framework (observation, enforcement and adaptation tasks)
Middleware Control Framework (observation, enforcement and adaptation tasks)
Service enabling platform (CORBA, etc) OS and Resource Management
Service enabling platform (CORBA, etc) data transfer
Transport Protocols
OS and Resource Management Transport Protocols
Server Site: may use multiple end systems
Client Site: may use multiple end systems
Figure 13: The Global View with the Middleware Control Framework tion. These characteristics enable support of a wide variety of distributed applications by our middleware control framework.
5 Decision Making of Control Actions: A Fuzzy Logic Approach In previous sections, we show that the control policies in the form of theoretical values ui (k ) generated by the Adaptation Tasks will be used in the Enforcement Tasks as a guideline to determine appropriate control actions. In this section we propose a fuzzy logic approach to associate the guideline values established by the Adaptation Tasks with the decision of control actions.
5.1 Adjustment of Controllable Properties In order to control the application, the middleware control framework is aware of the controllable properties presented in the application. In the case of adjusting quantitative controllable parameters in a task of an application, Enforcement Tasks in the middleware control framework calls the corresponding adjustment functions exported by the task itself. It is the responsibility of the Target Task itself to export proper interfaces for adaptation controls, and to modify internal data structures to adequately adjust these parameters, which is a requirement for controllable applications. The more parameters the middleware control framework can change, the more adaptive is the application. When the need for reconfiguration arises, there are two choices for the middleware control framework. If the application itself provides alternative implementations with different resource requirements in the form of alternative tasks, the middleware control framework helps the application to replace current tasks in use with alternative tasks at the time of reconfiguration. Otherwise, the middleware control framework will provide standard tasks useful for a wide variety of applications, or alternatively, reconfigure the topology of the Task Flow Graph by bypassing a subset of the tasks in use. Section 6 will discuss implementation issues using a distributed Visual Tracking application and the CORBA platform as an example.
5.2 A Fuzzy Logic Approach to Deciding Control Actions Using the Task Control Model, Adaptation Tasks can establish adapted request rate values ui (k ) for task Ti for a specific type of resource. These values are passed to the Enforcement Tasks to determine the appropriate control actions at time k . There are two purposes for adopting a fuzzy logic approach in the process of making this decision. First, in the case of a quantitatively controllable parameter, since the decision needs to balance between the precision of control actions to follow ui (k ) values and the frequency of control, the balancing decision should be configurable and tuned to the requirements of different applications. The simple approach of engaging threshold values are not sufficient. Second, in the case of a 23
reconfigurable application, the choices among different reconfigurable possibilities depend on the current ui(k) values from the Adaptation Tasks and the resource requirements for each reconfigurable possibility. The optimal decision on which reconfigurable possibility to use is a decision making process with multiple objectives, each objective reflecting the adapted request rate values ui (k ) of a different type of resources. These complications warrant a fuzzy logic approach to make the appropriate decisions. Assume that there are several Adaptation Tasks in the middleware control framework for Target Task Ti , each one corresponding to a type of resource shared by task Ti . Also assume that we have three different types of resource, CPU, memory storage and transmission bandwidth. Associated with Ti , we have three respective adapted request rate values generated by three Adaptation Tasks for the three types of resources: uci(k), umi(k) and ubi (k), respectively, at time k. Similarly, we also have three values corresponding to the actual new requests made by Ti , namely, ric (k ), rim (k ) and rib (k ). 5.2.1
Deciding Quantitative Control Actions
It is assumed that all quantitative controllable parameters are associated with a single task Ti , which defines the corresponding adjustment functions. We propose to utilize fuzzy logic and fuzzy set theories to map adapted request rate values to quantitative control actions as follows. Without loss of generality, we take CPU resource type and its corresponding uci (k ) and ric (k ) as an example. Assume task Ti defines a pair of control actions: a function Fu that can increase CPU usage in Ti , and a function Fd that can decrease CPU usage in Ti . We also define control error values as follows:
eci (k) = ric(k) ? uci(k) (52) Obviously, the universe of discourse U in the fuzzy set theory [8] corresponds to the set of all possible values of eci (k ). We can thus define the membership function PositiveError of a fuzzy set PositiveSet as a function of:
PositiveError : U +
! [0; 1]: (53) Where U + is the positive half of U . So, every element eci (k ) from U + has a membership degree PositiveError (eci (k )) 2 [0; 1], where PositiveSet is completely determined by the set of tuples PositiveSet = f(eci (k ); PositiveError(eci (k ))) j eci (k ) 2 U g
(54)
Similarly, we can define membership functions NegativeError and Correct for fuzzy sets NegativeSet and CorrectSet. The relationships of these membership functions and eci (k ) values are illustrated in Figure 14, where a simple linear membership function is shown. NegativeError 1
PositiveError
c
0 Correct
e (k) i
Figure 14: The Membership Functions and Fuzzy Sets related to eci (k ) With definitions shown above, we design the following algorithm to decide appropriate control actions: switch maxfNegativeError(eci (k )), Correct(eci (k )), PositiveError(eci (k ))g begin 24
case NegativeError(eci (k )): ActivateControlAction(Fu , eci (k )). case PositiveError(eci (k )): ActivateControlAction(Fd , eci (k )). case Correct(eci (k )): No changes. end. where ActivateControlAction calls the function Fu or Fd with a scaling factor eci (k ), which determines the adjustment extent inside Fu or Fd . This fuzzy logic approach to make a decision is fully configurable according to the application’s needs, by changing membership functions NegativeError, Correct and PositiveError. For example, if the application wishes to adapt only in extreme cases, both functions NegativeError and PositiveError can be specified to cover only those values at extreme ends. 5.2.2
Deciding Reconfiguration Control Actions
Normally, reconfiguration only needs to be performed in extreme cases with small probabilities. The Enforcement Task also determines when reconfiguration should take place. It is straightforward to extend our fuzzy logic approach for the quantitatively control decisions in order to determine the appropriate activation time of the reconfiguration process. However, if there are multiple reconfiguration choices, a selection algorithm is needed to choose the optimal selection of one reconfiguration alternative. We assume a universe of reconfiguration alternatives A and a collection fO g of selection objectives, each objective corresponding to a type of resource. The goal is to evaluate how well each alternative satisfies each objective, and to combine the weighted objectives into an overall decision function in some plausible way. We define a universe of n alternatives, A = fa1 ; a2 ; : : : ; an g and a set of j objectives, O = fO1 ; O2 ; : : : ; Oj g. Let Oi indicate the ith objective. The degree of membership of alternative a in Oi, denoted Oi (a) is the degree to which alternative a satisfies the criteria specified for this objective. We seek a decision function that simultaneously satisfies all of the decision objectives; hence, the decision function, D, is given by the intersection of all the objective sets,
D = O 1 \ O2 \ \ O j Therefore, the grade of membership that the decision function, D , has for each alternative
(55)
a is given by
D (a) = minfO1 (a); O2 (a); : : : ; Oj (a)g
(56)
D (a) = maxa2A (D (a))
(57)
The optimum decision, a , will then be the infimum alternative that satisfies We now define a set of values, fGg, which we will constrain to being linear and ordinal. These values are originally the adapted request rate values established by the Adaptation Task, and later scaled to a predetermined linearly ordered scale, e.g. [?1; 1], [1; 10], etc., according to the maximum and minimum values in the respective domain of resource types. These scaled values will be attached to each of the objectives to quantify the influence that each objective should have on the chosen alternative. Let the parameter, gi , be contained on the set of scaled values fGg, where i = 1; 2; : : : ; j . Hence, we have for each objective a measure of how important it is to the decision. The decision function, D , now takes on a more general form when each objective is associated with a weight expressing its importance to the decision. This function is represented as the intersection of j -tuples, denoted as a decision measure, M (Oi ; gi ), involving objectives and preferences, 25
D = M (O1 ; g1 ) \ M (O2 ; g2 ) \ \ M (Oj ; gj ) (58) A key question is what operation should relate each objective, Oi , and its guidance value, gi , that preserves the linear ordering required of the guidance value set fGg, and at the same time relates the two quantities in a logical way where negation is also accommodated. it turns out that the classical implication operator satisfies all of these requirements. Hence, the decision measure for a particular alternative, a, can be replaced with a classical implication of the form,
M (Oi (a); gi ) = gi ! Oi (a) = :gi _ Oi(a) Therefore, a reasonable decision model will be the joint intersection of j decision measures, D=
\j i=1
(:gi [ Oi )
(59)
(60)
and the optimum solution, a , is the alternative that maximizes D . If we define
Ci = :gi [ Oi hence Ci (a) = max[:gi (a); Oi (a)]
(61)
the optimum solution, expressed in membership form, is given by
D (a ) = maxa2A [minfC1 (a); C2 (a); : : : ; Cr (a)g] (62) This model is intuitive in the following manner. As the ith objective becomes more important in the final decision, gi increases, causing :gi to decrease, which in turn causes Ci (a) to decrease, thereby increasing the likelihood that Ci (a) = Oi (a), where now Oi (a) will be the value of the decision function, D , representing alternative a. As we repeat this process for other alternatives, a, Equation (62) reveals that the largest value Oi (a) for other alternatives will eventually result in the choice of the optimum solution, a . This is exactly how we would want the process to work.
5.3 Conclusions We have presented a control-based middleware framework for controlling the behavior of the application. Along with the Adaptation Tasks and the Observation Tasks, we proposed algorithms to be used in Enforcement Tasks, which makes adaptation decisions based on the theoretical guidance values calculated by the Adaptation Task. These algorithms are fully configurable to the requirements of the application, which determines the frequency of control and the selection criteria among different reconfiguration choices.
6 Experimental Results 6.1 Distributed Visual Tracking Application A relatively complex application is vital for the evaluation of the control-based middleware framework design. We have built a distributed Visual Tracking system based on the XVision project [9]. We have extended the original XVision system to be a client-server model, the Task Flow Graph of which is shown in Figure 1(b). In this application, the Visual Tracking Server grabs live video frames from a video camera, and sends the video feed over the transmission network to the Visual Tracking Client. The client executes a complicated kernel tracking algorithm, which identifies and tracks the object of interest to the user. The tracking 26
result is presented to the user as a visual rectangle showing the coordinates of the tracked object. The visual output of this application is that once a user selects the interested object, a colored visual rectangle will precisely follow the movements of the interested object at all times. We have successfully implemented this application on the Windows NT 4.0 platform in Visual C++, using Windows Sockets 2 API for the network transmission. The Visual Tracking application needs adaptation capabilities in the following ways. First, the network bandwidth between the Tracking Server and the Tracking Client may include fluctuations. This directly affects the frame rate of the live video feed, which is important for maintaining tracking precision. Experiments show that when the frame rate drops below 1-2 fps the kernel tracking algorithm will lose track of the object. The threshold minimum frame rate is determined by both the CPU processing power of the Tracking Client, and the speed at which the tracked object moves. Moreover, the CPU share allocated to the Tracking Client also affects the tracking precision. For example, if other CPU intensive applications are started that share CPU resources with the tracking kernel, the tracking precision may also drop and eventually lose track of the object. The ultimate objective of middleware adaptation controls for the Visual Tracking System is to maintain tracking precision at all times during a tracking connection, i.e., the tracking kernel should never lose track of the kernel. In order to fulfill this requirement, and for the purpose of evaluating our middleware framework, we implemented an Active Adaptation Control system in the middleware control framework as described in the previous section. This system includes several middleware components to extend the adaptation capabilities of the Visual Tracking application with regards to network bandwidth availability. The goal of this active adaptation control system is to maintain the tracking precision of the tracking kernel, so that the object will be tracked at all times, both visually and by quantitative measurements, regardless of transmission throughput fluctuations. All experiments with the distributed visual tracking system are conducted on a dual Pentium Pro 200 MHz workstation running Windows NT Server 4.0. We use Matrox Meteor as the frame grabber card, and the network between the client and server is a regular 10Mbps Ethernet.
6.2 Experimental Setup We choose CORBA as the basis for the middleware control framework. Specifically, we use OmniBroker 2.0.4, one of the implementation choices that supports OMG CORBA 2.0 specification. As mentioned earlier, the middleware control framework is not specific to any particular service enabling platform. Although we have not implemented the framework on any other alternatives, we believe it is possible to use DCOM, COM+ or other middleware services. The framework that our experiments operate in is shown in Figure 12 and 13.
Adaptation Component: The Adaptation Component is implemented to fulfill the responsibilities of the Adaptation Task in the Task Flow Graph. It interacts with the Visual Tracking application and other middleware components via CORBA. Its main responsibility is to calculate the current throttled value for new resource requests in the application, based on the feedback from the Observation Component. This value is then used by the Enforcement Component to enforce adaptation in the application. Observation Component: The Observation Component is implemented in the place of the Observation Task. It observes the current throughput at a particular network socket that the application uses, and supplies accurate instant throughput information when queried by the adaptation component, It exports its own interface in the form of CORBA IDL. Enforcement Component: It controls the frame rate in the Visual Tracking application by calling relevant interfaces exported by the application. Among the many ways to change the frame rate, our 27
experiments adjust the frame size being transmitted between the client and server. With the same throughput, the smaller the frame size, the better the frame rate. The enforcement component uses the fuzzy logic approach described in earlier sections to reduce frequency of adaptation actions. In the implementation, the Adaptation Component and Enforcement Component are implemented in C++, and the Observation Component is implemented in Java. By successfully combining Java and C++ in the implementation, we demonstrated the flexibility in terms of implementing the middleware framework, by leveraging multiple language support from CORBA and its IDL compiler implementation. A set of specific parameters in our experiments are designed as follows. In the Adaptation Tasks, scaling factors and in Equation (21) are configured as = 0:01 and = 0:45. In the Enforcement Tasks, the membership functions PositiveError, NegativeError and Correct for the bandwidth resources can be configured according to Figure 15. NegativeError
1
-512
-400
Correct
0
PositiveError
400
512
b ei (k) (KBytes/s)
Figure 15: Configurations for the Membership Functions Finally, in order to simulate fluctuations in an actual transmission network, we have also implemented a network simulator, which simulates packet delay through a transmission path of multiple network routers, each of them implementing the FIFO scheduling algorithm. Because of the bursty nature of cross traffic, fluctuations in packet delay may occur at various times over the connection.
6.3 Experimental Results We evaluated the effects of the middleware control framework on one of the quantitative controllable parameters in the distributed Visual Tracking system: the tracking precision. The objective is to keep track of the interested object at all times, despite of network fluctuations. With the Enforcement Component, the frame size of the application is adjusted when necessary in order to maintain the tracking precision. For the purpose of repeating the same set of experiments with ease and for measurements of tracking precision, we have used a computer generated image sequence instead of live video feed. The computer generated image sequence shows a white moving rectangle on black background, the moving speed is configurable. For the experimental results shown in Figure 16, the moving speed of the rectangle is set at a constant 3 pixels per second continuously. In addition, there are no other CPU intensive process running in the background on the same platform. This is for the purpose of simplifying the experiments and concentrating on a single type of resource. In Figure 16, the four graphs on the left are for the case without any adaptation. The four graphs on the right are for the case with adaptation support from the middleware control framework. We can easily observe that by changing the frame size of the visual tracking application, the tracking precision will be preserved without any tracking error at all times during the connection. In contrast, without adaptation, when the network throughput degrades to a certain degree, the tracking algorithm is not able to keep track of the object, the error accumulates rapidly verifying that the tracking algorithm loses the object. This proveof-concept system proves that the approach we have taken is effective in preserving tracking precision in an hostile environment with fluctuating throughput between the Tracking Client and the Tracking Server. From Figure 16(f), we can observe that the frame rate of the visual tracking application always fluctuates around 2 frames per second. This is exactly the desired frame rate to maintain tracking precision in our 28
experimental setup and for the object moving speed of 3 pixels per second. In the case without adaptation, there are prolonged periods that the application stays at well below 2 fps, this generally leads to bad tracking precision or loosing track of the object. This experiment was repeated more than a hundred times for various random environment generated by the network simulator, with the same computer generated video feed of a moving rectangle. We have not experienced any failure to the above stated experimental result: when middleware adaptation control framework is not activated, the visual tracking application will lose track of the object when the network throughput is below a minimum tolerable value. In contrast, when the middleware adaptation control framework is activated, we have never noticed any occurrences that the tracking application loses track of the interested object. In order to preserve the tracking precision, the frame size has to be adjusted. This normally leads to disturbances in user perception, which is frequently treated as another quality parameter at the user level. In this case, the adaptation process constitutes a tradeoff between the tracking precision and user perception. If the user prefers that the frame size should not be adjusted unless when absolutely necessary, our framework for the Enforcement Task allows the flexibility to configure the middleware, however the user risks loosing tracking precision when extreme cases in network bandwidth availability happens.
7 Conclusion We presented a control framework as a viable approach to reason about and model the control of the application adaptive behavior. This framework includes three major tasks. The Adaptation Task follows control algorithms based on the Task Control Model. The Enforcement Task, as part of Target Task model, takes adapted input QoS metrics values from Adaptation Tasks and makes decisions on control actions based on a fuzzy logic approach. The Observation Task monitors the current system state and provides a basis for the passive and active control approaches. All tasks in our control framework are embedded in the middleware level of a distributed system and utilize for their communication (i.e., communication among Adaptation, Enforcement, Observation Tasks and Applications) standard service enabling platforms such as CORBA. The analytical and experimental results show that our framework improves the adaptive abilities of the application, while the adaptive actions are highly flexible and configurable according to the needs of individual applications. Especially, we want to stress important analytical results coming out of this framework. We are now able to reason about and validate such properties as stability, agility, system equilibrium and fairness for adaptive timing behavior within distributed systems, which was not possible before. Traditional analytical models for distributed systems such as queueing theory, process algebra, petri nets and other frameworks allow us to model and analyze properties such as deadlock, starvation or worst case timing upper bounds, but do not allow easy and straight-forward reasoning and proofs of adaptive timing properties in distributed systems. Furthermore, our experimental results using distributed visual tracking application strongly validate our analytical results and show the feasibility and practicality of this control-based middleware framework.
References [1] N. Brown and C. Kindel. Distributed Component Object Model Protocol – DCOM/1.0. http://www.microsoft.com/oledev/olecom/draft-brown-dcom-v1-spec-02.txt, 1998. [2] A. Campbell and G. Coulson. QoS Adaptive Transports: Delivering Scalable Media to the Desk Top. IEEE Network, 1997. 29
[3] S. Cen, C. Pu, R. Staehli, C. Cowan, and J. Walpole. A Distributed Real-Time MPEG Video Audio Player. Proceedings of the 5th International Workshop on Network and Operating System Support of Digital Audio and Video (NOSSDAV’95), April 1995. [4] Z. Chen, S. Tan, R. Campbell, and Y. Li. Real Time Video and Audio in the World Wide Web. Proceedings of Fourth International World Wide Web Conference, 1995. [5] J. DeMeer. On the Specification of End-to-End QoS Control. Proceedings of 5th International Workshop on Quality of Service ’97, May 1997. [6] G. Franklin and J. Powell. Digital Control of Dynamic Systems. Addison-Wesley, 1981. [7] F. Goktas, J. Smith, and R. Bajcsy. Telerobotics over Communication Networks: Control and Networking Issues. 36th IEEE Conference on Decision and Control, 1997. [8] B. Graham and A. Ollero. An Introduction to Fuzzy Control. Springer, 1996. [9] G. Hager and K. Toyama. The XVision System: A General-Purpose Substrate for Portable Real-Time Vision Applications. Computer Vision and Image Understanding, 1997. [10] D. Hull, A. Shankar, K. Nahrstedt, and J. Liu. An End-to-End QoS Model and Management Architecture. Proceedings of IEEE Workshop on Middleware for Distributed Real-time Systems and Services, December 1997. [11] D. Manolakis J. Proakis. Digital signal processing, principles, algorithms, and applications. Prentice Hall, 1996. [12] M. Kirtland. Object-Oriented Software Development Made Simple with COM+ Runtime Services. http://www.microsoft.com/msj/1197/complus.htm, 1997. [13] B. Li and K. Nahrstedt. A Control Theoretical Model for Quality of Service Adaptations. Sixth International Workshop on Quality of Service, 1998. [14] S. Lu, K.-W. Lee, and V. Bharghavan. Adaptive Service in Mobile Computing Environments. Proceedings of 5th International Workshop on Quality of Service ’97, May 1997. [15] K. Nahrstedt, H. Chu, and S. Narayan. QoS-aware Resource Management for Distributed Multimedia Applications. accepted to Journal on High-Speed Networking, 1998. [16] R. Rajkumar, C. Lee, J. Lehoczky, and D. Siewiorek. A Resource Allocation Model for QoS Management. 18th IEEE Real-Time System Symposium, 1997. [17] D. Rosu, K. Schwan, S. Yalamanchili, and R. Jha. On Adaptive Resource Allocation for Complex Real-Time Applications. 18th IEEE Real-Time System Symposium, 1997. [18] M. Satyanarayanan. Fundamental Challenges in Mobile Computing. Proceedings of the ACM Symposium on Principles of Distributed Computing, 1996. [19] D. Schmidt, D. Levine, and S. Mungee. The Design and Performance of Real-Time Object Requests. Computer Communications Journal, 1997. [20] S. Shinners. Modern Control System Theory and Design. John Wiley and Sons, Inc., 1992.
30
[21] N. Tran and K. Nahrstedt. Active Adaptation by Program Delegation in VOD. IEEE International Conference on Multimedia Computing and Systems, 1998. [22] S. Vinoski. CORBA: Integrating Diverse Applications Within Distributed Heterogeneous Environments. IEEE Communications Magazine, 1997. [23] N. Yeadon, F. Garcia, A. Campbell, and D. Hutchison. QoS Adaptation and Flow Filtering in ATM Networks. Proceedings of the Second International Workshop on Multimedia: Advanced Teleservices and High Speed Communication Architectures, 1994.
31
1.2e+06
1.4e+06 Observed Throughput (Bytes/s)
Observed Throughput (Bytes/s) 1.2e+06
1e+06
1e+06 throughput (Bytes/s)
throughput (Bytes/s)
800000
600000
800000
600000
400000 400000
200000
200000
0
0 0
20
40
60
80
100 time (s)
120
140
160
180
0
200
(a) Observed Throughput
50
100
150
200 time (s)
250
350
400
(b) Observed Throughput
350000
350000 Frame Size (bytes)
Frame Size (Bytes)
300000
300000
250000
250000
frame size (bytes)
frame size (bytes)
300
200000
150000
200000
150000
100000
100000
50000
50000
0
0 0
20
40
60
80
100 time (s)
120
140
160
180
0
200
(c) Controllable Parameter: Frame Size
50
100
150
200 time (s)
250
300
350
400
(d) Controllable Parameter: Frame Size
4
6 Frame Rate (frames/s)
Frame Rate (Frames/s)
3.5 5 3
frame rate (frames/s)
frame rate (frames/s)
4 2.5
2
1.5
3
2 1 1 0.5
0
0 0
20
40
60
80
100 time (s)
120
140
160
180
0
200
50
(e) Frame Rate
100
150
200 time (s)
250
350
400
(f) Frame Rate
20
20 Tracking Precision: Error
Tracking Precision: Error
15
15
10
10
Tracking Error (pixels)
Tracking Error (pixels)
300
5
0
-5
5
0
-5
-10
-10
-15
-15
-20
-20 0
20
40
60
80
100 time (s)
120
140
160
180
0
200
(g) Tracking Precision
50
100
150
200 time (s)
250
300
350
400
(h) Tracking Precision
Figure 16 (Left): Experiments without adaptation support
Figure 16 (Right): Experiments with adaptation support
Figure 16: Experiments with the Distributed Visual Tracking Application 32
