QoS and Contention-Aware Multi-Resource Reservation.
To provide Quality of Service (QoS) guarantee in distributed services, it is necessary to reserve multiple computing and communication resources for each service session. Meanwhile, techniques have been available for the reservation and enforcement of various types of resources. Therefore, there is a need to create an integrated framework for coordinated multi-resource reservation. One challenge in creating such a framework is the complex relation between the end-to-end application-level QoS and the corresponding end-to-end resource requirement. Furthermore, the goals of (1) providing the best end-to-end QoS for each distributed service session and (2) increasing the overall reservation success rate of all service sessions are in conflict with each other. In this paper, we present a QoS and contention-aware framework of end-to-end multi-resource reservation for distributed services. The framework assumes a reservation-enabled environment, where each type of resource can be reserved. The framework consists of (1) a component-based QoS-Resource Model, (2) a runtime system architecture for coordinated reservation, and (3) a runtime algorithm for the computation of end-to-end multi-resource reservation plans. The algorithm provides a solution to alleviating the conflict between the QoS of an individual service session and the success rate of all service sessions. More specifically, for each service session, the algorithm computes an end-to-end reservation plan, such that it guarantees the highest possible end-to-end QoS level under the current end-to-end resource availability, and requires the lowest percentage of bottleneck resource(s) among all feasible reservation plans. Our simulation results show excellent performance of this algorithm.
Introduction
With the advances in resource reservation and scheduling
techniques, it is possible to provide end-to-end Quality
of Service (QoS) guarantees for distributed applications
and services. Various resource reservation and scheduling
frameworks have been proposed for individual system resources
such as CPU [7, 5], network bandwidth [11], disk
I/O bandwidth [9], and memory [7]. Now it becomes necessary
to create an environment where all these resources can
be reserved and scheduled in an integrated manner. In such
an environment, an end-to-end multi-resource reservation
will be performed for each client requesting a distributed
This work was supported by the National Science Foundation under
contract number 9870736, the Air Force Grant under contract number
F30602-97-2-0121, National Science Foundation Career Grant under contract
number NSF CCR 96-23867, NSF PACI grant under contract number
Infrastructure grant under contract
number NSF EIA 99-72884, NSF CISE Infrastructure grant under contract
number NSF CDA 96-24396, and NASA grant under contract number
NASA NAG 2-1250.
service, so that it can be guaranteed a certain level of end-
to-end QoS. A key question in creating such an environment
is: for a distributed service, how to determine the best end-
to-end QoS level and the corresponding multi-resource re-
quirement, under the constraint of current end-to-end multi-resource
availability.
One difficulty in answering the above question is: the relation
between an end-to-end QoS level and the corresponding
end-to-end resource requirement can be very complex.
Both the QoS level and the multi-resource requirement are
generally expressed as partial-ordered multi-dimensional
vectors. Every resource contributes to the end-to-end QoS,
and there may exist trade-offs between different resources
for the same end-to-end QoS level. In this case, the multi-resource
requirement can not be determined by looking at
these resources separately. Instead, it must be determined
by a coordinating entity placed on top of these resources.
Another difficulty is: even in a reservation-based envi-
ronment, there is still resource contention. Different applications
and services need to reserve from the same pool of
resources, inevitably causing the reservations for some ap-
plications/services to fail. In fact, the goals of (1) increasing
the overall success rate of multi-resource reservations for
different service requests, and (2) achieving the best end-to-
end QoS for each service request, are in conflict with each
other.
In this paper, we propose a solution to the difficulties
discussed above. We present a QoS and contention-
aware multi-resource reservation algorithm for distributed
and component-based services. The algorithm computes an
end-to-end multi-resource reservation plan, which achieves
the highest possible end-to-end QoS level under the constraint
of current resource availability. In the meantime, the
multi-resource reservation plan tends to cause low bottle-neck
resource contention among all feasible resource reservation
plans which lead to the same level of end-to-end
QoS.
The rest of the paper is organized as follows. In Section
2, we describe an enabling system architecture for multi-resource
reservation, and a QoS-resource model on which
our algorithm is based. In Section 3, we present the QoS
and contention aware multi-resource reservation algorithm.
In Section 4, we show the performance of this algorithm by
simulation. Finally, we conclude this paper in Section 6.
System Architecture and QoS-Resource
Model
2.1 Distributed and Component-Based Services
The distributed services studied in this paper are
component-based. With distributed object programming
techniques, a distributed service can be implemented as a
set of collaborating service components. A service component
is a functional unit participating in the service delivery.
For example, in a distributed video streaming service with
object tracking functionality, besides streaming a video to a
client, the service can also track an object of interest in the
video for the client. The client host will be able to playback
the video, and there will be a rectangle around the object being
tracked. In this service, the service components include
a VideoSender service component running on a video server,
an ObjectTracking service component running on a tracking
server, and a VideoPlayer service component running
on each client host. Each service component in a distributed
service is able to achieve one or more levels of service qual-
ity, depending on the amounts of resources reserved for this
component. The service quality achieved by each individual
service component finally leads to the end-to-end QoS
provided for the client.
2.2 An Architecture for Multi-Resource Reserva-
tion
In order to deploy such a distributed and component-based
service in a reservation-enabled environment, we introduce
an enabling system architecture. The architecture
is shown in Figure 1. It involves the following entities:
Resource Brokers (RBs), QoSProxies, and service compo-
nents. On each host in the environment, there is one or
more RBs managing individual resources, one for each type
of resource. A QoSProxy runs on each host, coordinating
the reservation activities of local RBs. The multi-resource
reservation algorithm will be executed by the QoSProxies
on the hosts involved in a distributed service.
A RB is responsible for the reservation and scheduling
of a resource 1 . The basic functions of a RB includes:
(1) reporting current resource availability, (2) making
1 For end-to-end network bandwidth, we look at it as one resource - a
pipe from the sender to the receiver. To be compatible with RSVP, we
assume that the network RB of the receiver is always responsible for initiating
an end-to-end bandwidth reservation.
component
Service
component
Service
QoSProxy
component
Service
QoSProxy
Translation function
QoSProxy

Figure

1. An Architecture for Multi-Resource
Reservation
and enforcing reservations, (3) releasing reservations,
and (4) reporting possible reservation degradations.
A QoSProxy is responsible for coordinating the reservation
activities of individual RBs on the same host. Its
basic functions include: (1) collecting resource availability
information from individual RBs, (2) executing
the multi-resource reservation algorithm and dispatching
the resultant reservation plan to individual RBs,
and (3) starting the service component on the same
host when the multi-resource reservation is completed.
A QoSProxy has to understand the relation between the
QoS levels and the corresponding resource requirements of
a service component, in order to compute a resource reservation
plan. However, this relation is highly application-
specific. For this reason, our architecture allows service developers
to provide translation functions as plug-ins for the
QoSProxies, as shown in Figure 1. Each translation function
the relation between the multiple QoS levels
and their resource requirements of a service component (the
formal definition of a translation function will be given in
Section 2.3). Therefore, a QoSProxy can call the translation
function during the execution of the multi-resource reservation
algorithm.
2.3 QoS-Resource Model
To express the relation between a service component's
QoS and its resource requirement, we adopt a QoS-resource
model. This model was originally proposed in [8]. Each service
component c is associated with both the input quality
Q in and the output quality Q out . Q in and Q out are both
represented as vectors of multiple QoS parameters. Their
QoS parameter sets may not be identical. For simplicity, we
assume that each parameter takes discrete values. There-
fore, Q in and Q out of each service component are enumer-
able. To compare two QoS vectors, they must have the same
parameter set. For two QoS vectors Q a and Q b , Q a  Q b
holds if and only if for each QoS parameter, the corresponding
value of Q a is not larger than that of Q b .
For a service component c, the resource requirement
to achieve a certain output quality Q out , given an input
quality Q in , is computed by the translation function T c
R). The resource requirement is
formally represented as a resource requirement vector R.
Therefore, given a pair (Q in ; Q out ), we have:
The resource requirement vector
M) is the required amount of the mth re-
source. To compare two resource requirement vectors, they
must have the same set of resources. For two resource requirement
vectors R a and R b , R a  R b holds if and only if
for each type of resource, the corresponding value of R a is
not larger than that of R b .
For a distributed service, the participating service components
organize themselves into a dependency graph. In
general, the dependency graph is a Direct Acyclic Graph
(DAG). Nodes of a dependency graph represent service
components. Edges of a dependency graph represent the dependencies
among the service components. Figure 2 shows
an example of the dependency graph. An edge from service
components c to c 0 indicates that the output of c is the input
of c 0 ; and the Q out of c is equivalent to the Q in of c 0 . In
addition, for a node with no in-coming edges (for example,
c 1 in

Figure

2), its Q in represents the original quality of the
source data involved in this service (for example, a stored
video clip or a live video source involved in a multimedia
service); for a node with no out-going edges (for example,
c 3 in

Figure

2), its Q out represents the resultant end-to-end
QoS.
out in out in
in
Figure

2. Example Dependency Graph of a
Distributed Service
3 Multi-Resource Reservation Algorithm
After introducing the system architecture for multi-resource
reservation and the QoS-resource model, we now
present the QoS and contention-aware multi-resource reservation
algorithm. Given a service request, the algorithm
computes an end-to-end resource reservation plan for service
components participating in this distributed service, so
that the best end-to-end QoS can be delivered to the client,
under the constraint of current end-to-end resource availability
observed by the client. The goals of our algorithm
involve both QoS-awareness and contention-awareness:
QoS-awareness Each service component may accept
multiple levels of Q in , and achieve multiple levels of
Q out . The algorithm must compute a resource reservation
plan by selecting appropriate levels of Q in and
Q out for each service component, so that it will lead
to the best possible end-to-end QoS for the client-side
service component according to the dependency graph.
Contention-awareness Resources may be shared by
other services and applications on a competitive basis.
Therefore, resource contention may exist during resource
reservation. The degree of resource contention
varies from time to time, from resource to resource. It
may affect the overall success rate of resource reservations
in the environment 2 . The algorithm must find a
resource reservation plan among all possible reservation
plans, such that it will reserve only the minimum
amount of bottleneck resource(s). Therefore, if every
multi-resource reservation is disciplined by this algo-
rithm, the overall resource contention in the environment
will be alleviated.
In the following subsections, we first define QoS-
Resource Graph (QRG) - a key data structure to study the
multi-resource reservation problem. We then study the special
case in which the dependency graph of a distributed
service is a chain. Finally, we extend the algorithm to deal
with the general case in which the dependency graph of a
distributed service is a DAG.
3.1 QoS-Resource Graph
We formally define the multi-resource reservation problem
using a QoS-Resource Graph (QRG). For a distributed
service, a QRG is generated for each service request at run-
time, based on the dependency graph of the requested ser-
vice. However, the definition of a QRG is different from
that of a dependency graph. A node in a QRG represents
a QoS level for the Q in or Q out of a service component
c. An edge in a QRG from a node Q in to a node Q out
represents the corresponding resource requirement vector
computed by the translation function T c . However, such
an edge exists if and only if the current resource availability
(also represented as a vector) is no less than the resource
requirement vector. Figure 3 shows an example QRG generated
from the dependency graph in Figure 2. The dotted
rectangles in the QRG represent the corresponding service
components in the dependency graph.
We assume that a multi-resource reservation is not successful, if at
least one resource can not be reserved.
For simplicity (without lowering the problem's complex-
ity) , we further assume that the original quality of the
source data associated with a service request has a single
QoS level. We define the node representing this QoS level
as the source node of a QRG (for example, Q a in Figure 3).000.50.60.50.6

Figure

3. Example QRG (weights of the edges
are shown)
For the client-side service component, whose Q out
nodes represent the end-to-end QoS levels (for example,
service component c 3 in Figure 3), we define its Q out nodes
as the sink nodes of a QRG (for example, Q l and Qm in

Figure

3). We also assume that the sink nodes (i.e. the
end-to-end QoS levels) can be ranked in a linear order. The
linear ranking can be determined by a client's preferences,
and may be subjective. For example, when two end-to-end
QoS levels are not comparable, the client requesting the
distributed service can arbitrate that the QoS level with a
smaller delay parameter value is better than the one with a
larger value.
We now define the weight of each edge in a QRG. The
weight will reflect the degree of resource contention caused
by the resource requirement represented by the edge. For
an edge from a node Q in to a node Q out , let R
[r req
M ] be the corresponding resource requirement
vector (computed by calling T c (Q in ; Q out )). On the
other hand, let
M ] be the current
resource availability vector (collected by querying the
RBs). We first define a contention index i to evaluate how
'competitive' it is to reserve r req
i amount of resource r i , under
the constraint of availability r avail
i . In this paper, we
choose a simple definition of as follows:
r req
r avail
Intuitively, the larger the percentage of a resource one tries
to reserve under the current availability constraint, the less
likely the reservation will succeed 3 . Now, we can further
3 In fact, there are other definitions for which also exhibit this charac-
define the weight for the edge as:
r req
r avail
For an edge from a node Q out to a node Q in , it only
represents their equivalence - the output quality of a service
component is the input quality of its dependent service com-
ponent. Therefore, the weight of such an edges is defined
as zero (shown in Figure 3).
3.2 Algorithm: the Chain Case
After defining the QRG, we are now ready to present the
algorithm. We first consider the special case in which the
dependency graph of a distributed service is a chain.
In a QRG, an edge with non-zero weight exists if and
only if the corresponding R req  R avail , i.e. the reservation
of resources according to R req is feasible. There-
fore, we have the following observation: every path from
the source node to one of the sink nodes represents a feasible
end-to-end resource reservation plan - in other words, if
we reserve resources according to the resource requirement
vectors represented by the non-zero-weight edges on the
path, the end-to-end QoS represented by the sink node will
be guaranteed. Furthermore, the best achievable end-to-end
QoS under the current resource availability is represented
by the sink node which has the highest ranking among all
'reachable' sink nodes from the source node. For example,
in

Figure

3, if we assume that Q l ranks higher than Qm ,
then Q l is the best achievable end-to-end QoS level.
However, there are multiple paths from Q a to Q l , i.e.
there exist more than one feasible resource reservation plans
to achieve Q l . To minimize resource contention, our algorithm
will select a path such that the value of P is the
smallest among these paths - P is defined as:
(each edge e on path P )
e (4)
By definition, it is easy to see that P represents the
contention index of the bottleneck resource on the path (note
that the bottleneck resource on each path may be different).
To find a path from Q a to Q l whose bottleneck resource
has the smallest contention index, our algorithm finds the
shortest path from Q a to Q l , with operator '+' re-defined
as 'max'. This is done by running Dijkstra's algorithm on
the QRG. Figure 4 shows such a shortest path (shown by
the thicker edges). The value inside each node is generated
during the execution of Dijkstra's algorithm.
The computation complexity of the reservation algorithm
in the chain case is O(KQ 2 ). K is the number of service
components in the dependency graph of a distributed
teristics. Fortunately, it is easy for our algorithm to adopt a different (and
more accurate) definition in the future.
f
Qm000.50.60.50.6

Figure

4. The Shortest Path from Q a to Q l
(representing the end-to-end reservation plan
computed by the algorithm)
service. Q is the maximum number of Q out levels (nodes)
among the service components. For example, in Figure 4,
(which is the number of Q out nodes of
Fortunately, K and Q usually have fairly small values
in practice (for example, K, Q  10). Therefore, scalability
is not a major concern for the multi-resource reservation
algorithm.
The number of Q out levels of a service component is set
by the service developer in the translating function of the
service component. Our experience shows that this number
can be effectively controlled by limiting the number of
possible values for each QoS parameter.
3.3 Algorithm: the DAG Case
We now consider the more general case in which the dependency
graph of a distributed service is a DAG. For a
DAG dependency graph, we first extend the definition of a
service component's QoS levels:
For a service component with more than one out-going
edge, its Q out will become the Q in of each service
component on the other end of the out-going edge (as
shown in Figure 5). We call the service component
with more than one out-going edges a fan-out service
component. For example, c 2 in Figure 5 is a fan-out
service component.
For a service component with more than one in-coming
edge, its Q in is defined as the concatenation
of the Q out of service components on the other end of
the in-coming edges. We call the service component
with more than one in-coming edges a fan-in service
component. For example, c 5 in Figure 5 is a fan-in
service component.
An example QRG generated from this DAG dependency
graph is shown in Figure 6. A feasible end-to-end reser-
out in C3
out
out in
out in
out
q 33, . ]
[q q . ]
out
41, 43,
q 33, .
C1in

Figure

5. Example DAG Dependency Graph of
a Distributed Service
vation plan is now represented by an embedded graph in
the QRG such that: (1) for each service component, among
the edges from a Q in node to a Q out node, there is one -
and only one edge that belongs to the embedded graph; (2)
within the embedded graph, the sink node (representing the
end-to-end QoS level achieved by this reservation plan) is
reachable from each node in the embedded graph. The goal
of our reservation algorithm is to compute a feasible end-to-
reservation plan, represented by an embedded graph G,
such that (1) the sink node in the embedded graph has the
highest QoS ranking; and (2) the value of G is the smallest
both among all feasible end-to-end reservation plans. G
is defined as follows:
(each edge e in G) e (5)00.530.30.20.60000000.60.80.70.40.450.5Q a
c cc
c
c

Figure

6. Example QRG Based on a DAG Dependency
Graph
It can be shown that such a problem is NP-complete.
Therefore, we focus on providing an efficient and effective
heuristics to compute an end-to-end reservation plan that
achieves the best end-to-end QoS, while trying to maintain
a low value of G . Our heuristics is based on the following
two-pass procedure on the QRG.
Pass I on the QRG is similar to the reservation algorithm
in the case of chain dependency graph. It also runs
Dijkstra's algorithm to explore the 'shortest path' from the
source node to the sink nodes of the QRG. As an example,

Figure

7 shows the result of pass I on the QRG in Figure
6. Notice that when generating the value in a Q in node of
a fan-in service component (for example, node Q r of c 5 ),
we set the value as the maximum of the values in Q out
nodes on the other end of the in-coming edges (for exam-
ple, nodes Q n and Q p ). This is different from Dijkstra's
algorithm. By our definition, Q r is the concatenation of Q n
and Q p . Therefore, the resource contention to reach Q r is
the maximum of resource contention to reach Q n and Q p ,
respectively.
s
c
c
c

Figure

7. Running the Heuristics: Result of
Pass I
Pass II on the QRG proceeds in the reversed direction of
pass I. Starting from the reachable sink node with the highest
QoS ranking (for example, Q v ), we backtrack the edges
toward the source node, according to the result of pass I.
This is to determine the embedded graph that represents the
resultant end-to-end reservation plan. However, the back-tracking
may encounter the following problem: when arriving
at a fan-out service component, the backtracked edges
do not converge at the same Q out node. For example, in

Figure

7, the backtracked edges (the thicker ones in the
Figure) lead to different Q out nodes Q h and Q i . In our
heuristics, we use the following method to resolve this non-convergence
locally:
For the service components dependent on the fan-out
component (for example, c 3 and c 4 ), fix their Q out nodes
that have been backtracked (for example, nodes Q n and
select such a Q out node of the fan-out service
component: it causes the lowest resource contention to
reach the fixed Q out nodes of the dependent service com-
ponents. For example, in Figure 7, Q i will be selected (in-
stead of Q h ), because for Q i to reach Q n and Q p , the resource
contention is 0.6, while for Q h to reach Q n and Q p ,
the resource contention is 0.7.
e
c c
c
c
c

Figure

8. Running the Heuristics: the Embedded
Graph Representing the Resultant Reservation
Plan
By using this two-pass heuristics, an end-to-end reservation
plan can be computed for the QRG in Figure 7. The
embedded graph representing the reservation plan is shown
in

Figure

8. The limitation of this heuristics is: for a sink
node of the QRG which is reachable in pass I, the heuristics
may not necessarily find a feasible reservation plan in
pass II to guarantee the end-to-end QoS level represented
by the sink node. Furthermore, due to the local (instead
of global) nature of the non-convergence resolution in pass
II, the reservation plan computed by the heuristics may not
incur the lowest bottleneck resource contention among all
feasible reservation plans.
4 Simulation Results
In this section, we evaluate the success rate of multi-resource
reservations achieved by the proposed reservation
algorithm. The results in this section are initial, and obtained
by simulation. We simulate a simple scenario: there
is a distributed service which involves three service components
In our simulated environment, c 1
runs on one host. c 2 runs on another host. c 3 is the client-side
service component, and runs on each client host. Resource
contention exists on the hosts where c 1 and c 2 ex-
ecute. In addition, we introduce background computation
task on each client host, so that resource contention also
exists between the execution of c 3 and the background task.
For simplicity, we assume that each service component
only requires one type of resource. The QoS levels and the
corresponding resource requirements are shown in figure 9.
Each value in the brackets denotes the required amount of
resource for the corresponding (Q in ; Q out ) pair. We also
assume that Q l has a higher QoS ranking than Qm . Notice
that

Figure

9 is not a QRG.
The total amount of resource on the host where c 1 executes
is 800 units. The total amount of resource on the
host where c 2 executes is 400 units. The total amount of
resource on each client host where c 3 executes is 1 unit. We
assume that at the beginning of the simulation, all these resources
are free. We also assume that for each client host,
right before it makes a service request, a background computation
task will begin to run with a 0.5 probability, and
the amount of resource it consumes is uniformly distributed
between 0.25 and 0.75 unit.
[1.5]
[2.5]
[1.0]
[0.3]
[0.3]
[x]: Amount of Resource Required

Figure

9. QoS Levels and Resource Requirements
of the Simulated Service Components
In the first experiment, we simulate multi-resource reservations
made for 16000 service requests spreading over 400
minutes. The duration (i.e. resource holding time) of each
service session varies uniformly between 5 and 50 minutes.
Service requests from different clients arrive at an average
rate of 40 requests per minute. The success rates of multi-resource
reservations are shown in Figure 10 - each point
represents the success rate in a 5-minute interval. Here,
we compare our algorithm with a random algorithm, which
randomly selects a feasible multi-resource reservation plan
represented by a path from Q a to Q l in Figure 9. During
the 400-minute period, the overall success rate using our algorithm
is 96.33%, while the random algorithm achieves an
overall success rate of only 78.06%.
In the second experiment, we simulate different average
request arrival rates for the same distributed service. For10305070900 50 100 150 200 250 300 350 400
Success
Rate
of
Multi-Resource
Reservations
(%,
Time (minutes)
'Our Algorithm'
'Random Algorithm'

Figure

10. Multi-Resource Reservation Success
Rate over the 400-Minute Period
each average arrival rate, we measure the overall success
rate over a 400 minute period using our algorithm and using
the random algorithm. Figure 11 shows the overall multi-resource
reservation success rate under different service request
arrival rates. The results show that our algorithm constantly
achieves higher overall success rate than the random
algorithm.
5 Related Work
The problem of multi-resource reservation has been addressed
from different angles. In [3] and [4], a resource
co-allocation architecture and its mechanisms for alloca-
tion, configuration, monitoring, and control are presented.
It is suggested that resource co-allocation should be an integral
part of the resource management architecture for Grid
environments. In addition, an advance reservation mechanism
is also proposed. One of our next steps is to extend
our algorithm to accommodate advance reservation. In
[6], the problem of apportioning multiple finite resources to
satisfy the QoS needs of multiple applications along multiple
QoS dimensions is studied. However, their solution
is based on a static set of applications to be executed at
the same time, and they do not consider the dynamic arrival
and completion of applications. Therefore, their solution
is not contention-aware. In the Darwin Project [1], a
hierarchical service and resource brokerage architecture is
Success
Rate
of
Multi-Resource
Reservations
(%,
overminutes)
Arrival Rate of Multi-Resource Reservation Requests (requests/min)
'Our Algorithm'
'Random Algorithm'

Figure

11. Multi-Resource Reservation Success
Rate under Different Request Arrival
Rates
introduced. In order to compose value-added services, allocation
of multiple resources is needed. The signaling protocol
during multi-resource allocation is the Beagle signaling
protocol [2]. However, this protocol is not contention-aware
either. In our earlier work of Qualman system [7], different
QoS-aware resource brokers are proposed. They are responsible
for the reservation and enforcement of CPU, network
bandwidth, and memory resources, respectively. However,
there is no coordination among these resource brokers, and
no algorithm is proposed to compute multi-resource reservation
plans to guarantee end-to-end application level QoS.
Finally, in [10], we study the multi-resource reservation
problem only in the case of chain dependency graph. In this
paper, we extend our solution to deal with the more general
case of DAG dependency graph.
6 Conclusion
In a reservation-based environment where every type
of resource can be reserved, we need system support to
compute end-to-end multi-resource reservation plans and to
make corresponding reservations in an integrated and systematic
manner. In this paper, we first propose a system
architecture that enables such an integrated multi-resource
reservation for distributed and component-based services.
We then present a QoS and contention-aware multi-resource
reservation algorithm that computes a reservation plan for
each distributed service request, such that (1) it achieves
the highest level of end-to-end QoS under the constraint of
current resource availability, and (2) it causes the least bottleneck
resource contention in the case of chain dependency
while it tends to cause low bottleneck resource contention
in the case of DAG dependency graph. Our future
work includes the extension to support advance reservation,
and the study of reservation fairness among service requests
with highly heterogeneous resource requirements and service
durations.



--R

Resource management for value-added customizable network service
A signaling protocol for structured resource allocation.
Resource co-allocation in computational grids
A distributed resource management architecture that supports advance reservations and co-allocation
CPU reservation and time constraints: efficient
A scalable solution to the multi-resource QoS problem


A disk scheduling framework for next generation operating systems.
Multimedia service configuration and reservation in heterogeneous environ- ments
RSVP: A new resource reservation protocol.
--TR

--CTR
Ashish M. Mehta , Jay Smith , H. J. Siegel , Anthony A. Maciejewski , Arun Jayaseelan , Bin Ye, Dynamic resource allocation heuristics that manage tradeoff between makespan and robustness, The Journal of Supercomputing, v.42 n.1, p.33-58, October   2007
Jong-Kook Kim , Sameer Shivle , Howard Jay Siegel , Anthony A. Maciejewski , Tracy D. Braun , Myron Schneider , Sonja Tideman , Ramakrishna Chitta , Raheleh B. Dilmaghani , Rohit Joshi , Aditya Kaul , Ashish Sharma , Siddhartha Sripada , Praveen Vangari , Siva Sankar Yellampalli, Dynamically mapping tasks with priorities and multiple deadlines in a heterogeneous environment, Journal of Parallel and Distributed Computing, v.67 n.2, p.154-169, February, 2007
resource contention;distributed service;resource reservation