IEEE TRANSACTIONS ON SERVICES COMPUTING, VOL. 2, NO.

1, JANUARY-MARCH 2009 3

A QoS Control Mechanism to Provide

Service Differentiation and Overload
Protection to Internet Scalable Servers
Daniel F. Garcı́a, Member, IEEE, Javier Garcı́a, Joaquı́n Entrialgo, Manuel Garcı́a,
Pablo Valledor, Rodrigo Garcı́a, and Antonio M. Campos

Abstract—Nowadays, enterprises providing services through Internet often require online services supplied by other enterprises. This
entails the cooperation of enterprise servers using Web services technology. The service exchange between enterprises must be
carried out with a determined level of quality, which is usually established in a service level agreement (SLA). However, the fulfilment of
SLAs is not an easy task and requires equipping the servers with special control mechanisms which control the quality of the services
supplied. The first contribution of this research work is the analysis and definition of the main requirements that these control
mechanisms must fulfil. The second contribution is the design of a control mechanism which fulfils these requirements and overcomes
numerous deficiencies posed by previous mechanisms. The designed mechanism provides differentiation between distinct categories
of service consumers as well as protection against server overloads. Furthermore, it scales in a cluster and does not require any
modification to the system software of the host server, or to its application logic.

Index Terms—QoS, quality of service, Web services, Internet servers, overload protection, service level agreement, SLA,
cluster computing.

1 INTRODUCTION

N OWADAYS, enterprises providing services through Inter-

net must use online services supplied by other
enterprises to compose the final services required by their
end clients. Therefore, the Internet servers of several
enterprises must work in cooperation to provide the
required services.
In order to ensure that the quality of service (QoS)
perceived by end clients is acceptable, the servers must
include techniques and mechanisms that guarantee a
minimum level of QoS. Although QoS has multiple aspects
such as response time, throughput, availability, reliability,
and security, the primary aspect of QoS considered in this
work is related to response time.
The type of operational environment where the QoS
control mechanism presented in this paper is intended to
work is designed for an enterprise server (or cluster)
working as a Web services provider, which supplies a
. D.F. Garcı´a, J. Garcı´a, J. Entrialgo, and M. Garcı´a are with the Department
of Computer Science and Engineering, University of Oviedo, Campus
Universitario, Edificio 1, 33204 Gijón, Spain.
E-mail: {dfgarcia, javier, joaquin, mgarcia}@uniovi.es.
. P. Valledor is with the R&D Technological Centre—KiN (CDT),
ArcelorMittal R&D Technological Centre, Centro de Desarrollo Tecnoló-
gico, PO Box 90, 33400 Avilés, Spain.
E-mail: pablo.valledor-pellicer@arcelormittal.com.
. R. Garcı´a and M.A. Campos are with the Departamento I+D+i, CTIC
Foundation, Parque Cientı´fico Tecnológico de Gijón, Edificio Centros
Tecnológicos, 33203 Cabueñes, Gijón, Spain.
E-mail: {rodrigo.garcia, antonio.campos}@fundacionctic.org.
Manuscript received 29 July 2008; revised 22 Dec. 2008; accepted 19 Jan.
2009; published online 27 Jan. 2009.
For information on obtaining reprints of this article, please send e-mail to:
tsc@computer.org, and reference IEEECS Log Number TSC-2008-07-0070.
Digital Object Identifier no. 10.1109/TSC.2009.3.
1939-1374/09/$25.00 ß 2009 IEEE
collection of services through Internet to servers of other
enterprises. In this paper, we refer to the server providing
services as the provider server and to the servers consuming
services as consumer servers. The services are deployed
using Web services technology. The consumer servers
usually belong to enterprises which provide online services
to end clients. In this operational environment, the con-
sumer servers consume the services delivered by the
provider server in order to respond to the requests carried
out by the end clients. This operational environment defines
C2B connections between end clients and consumer servers,
and B2B relationships between consumer servers and
provider servers.
In order that consumer servers can provide end clients
with the appropriate quality of service, they must be
guaranteed a determined QoS from the provider server.
To this end, a Service Level Agreement (SLA) is established
between each consumer server and the provider server. The
SLAs specify the maximum response time of each service
delivered by the provider. The SLAs also specify the
consumer server category, which states the degree of QoS
that the consumer receives from the provider.
In this type of operational environment, the interactions
between the consumer servers and the provider server are
mainly carried out in secure mode using the SSL protocol.
To avoid the great overhead entailed by negotiating an
independent secure session for each request, all the requests
of each consumer server (occurring in a determined period
of time) are usually grouped in a single secure session. In
this paper, the collection of interactions carried out between
a provider and a consumer server within a single secure
session is called a business session.
Published by the IEEE Computer Society
4 IEEE TRANSACTIONS ON SERVICES COMPUTING, VOL. 2, NO. 1, JANUARY-MARCH 2009

has been tested and the experimental results. Finally,

Section 7 concludes the paper.

2 REQUIREMENTS OF THE QOS CONTROL

MECHANISM
After analyzing the different QoS mechanisms presented in
the literature (described in Section 3) and taking into
account the operational environment in which they must
work, we propose a set of requirements that a QoS
mechanism for an application server should address. These
requirements are the following.

. Requirement 1 (R1): The QoS control mechanism must be

Fig. 1. Load balancing cluster implementation of a provider server.
The provider server may be implemented by means of a
single server or a cluster server. In the latter case, a load
balancing cluster is used. This kind of cluster (shown in
Fig. 1) is made up of a set of nodes which execute the same
application logic, supplying the same set of Web services to
the consumer servers.
The application logic of the provider server is commonly
implemented using a Web server, as well as other
components which provide a wide variety of services, such
as connectivity with databases and handling of commu-
nications with other applications. The systems implement-
ing Web services with the support of these environments
are currently known as applications servers. Therefore, the
provider server depicted in Fig. 1 must also be considered
an application server.
Much research effort in the QoS control of servers has
been oriented to Web servers. In spite of this, many
techniques available in the literature are inapplicable to
real systems. As an example, in overloading periods, many
techniques discard Web requests arriving at the server
without considering that these requests are integrated in the
navigation sessions of the clients.
Furthermore, very little effort has been devoted to the
QoS control of application servers, as will be discussed in
Section 3. The research presented in this paper fills a gap by
providing useful QoS control techniques suitable for a
broad range of application servers. The research results
presented in this paper are also important due to the
increasing deployment of application servers operating
with Web services technology which must fulfill QoS
requirements. The QoS control mechanism presented in
this paper has been designed for an application server,
providing a useful improvement in the QoS control of this
type of server.
The research topics addressed through this paper are
described below with the following organization. Section 3
states the general requirements demanded for any useful
QoS control mechanism. Section 3 analyzes the QoS
mechanisms described in previous research work, showing
their deficiencies. In Section 4, the proposed design of a new
QoS mechanism is explained. Sections 5 and 6 describe the
experimental environment in which the QoS mechanism
able to manage several simultaneous services with a
specific response time limitation for each service (not a
single limitation for all the services as used in other
research works). This is because SLAs usually specify
an individual response time limitation for each
service. In accordance with the current usage, the
response time limitations applied to services must be
expressed in terms of the 90 percentile.
. Requirement 2 (R2): The QoS control mechanism must
supply service differentiation in the service provided to the
consumers. This means that the requests of prefer-
ential consumers must have a high degree of
probability of being serviced, even when the load
supported by the provider server is high. However,
the requests of less important consumers may be
rejected (especially, when the load is high) to reserve
the computational resources of the provider server
for the preferential consumers. In this way, the QoS
control mechanism supports the concept of consu-
mer category, usually used in SLAs.
. Requirement 3 (R3): The QoS control mechanism must
support the grouping of interactions (between the provider
and the consumers) in sessions. The reason for this is
that in most cases, the interactions between provider
and consumer servers must be carried out in secure
mode using SSL and other security technologies.
. Requirement 4 (R4): The QoS control mechanism
integrated in the provider server should not require
modifications in the system software of the server. In this
way, the QoS mechanism is independent of the
underlying computing platform. Some research
works propose modifications to the system software
to implement QoS. However, this is only possible in
open source systems, in which the source code of the
system is accessible. In many commercial systems,
such modifications are not possible.
. Requirement 5 (R5): The QoS control mechanism
integrated in the provider server should not require
modifications in the application logic of the server. Thus,
the QoS mechanism can be incorporated into the
server easily, because it does not require any change
in the software of the server.
. Requirement 6 (R6): The QoS control mechanism should
be easy to configure. This facilitates its integration in
production servers.
. Requirement 7 (R7): The QoS control mechanism must be
scalable to operate in both a single server and a cluster
GARCIA ET AL.: A QOS CONTROL MECHANISM TO PROVIDE SERVICE DIFFERENTIATION AND OVERLOAD PROTECTION TO INTERNET...
server of any number of nodes. Nowadays, scalability is
a fundamental issue in the design of provider
servers, since these must be designed to adapt to
possible increases in the demand of service requests.
Because of this, the QoS control mechanism must be
designed to scale with the server in which it
operates.
. Requirement 8 (R8): The QoS control mechanism must
provide protection against overloads. Under overload
conditions, the SLAs may not be fulfilled, so overload
situations must be properly managed. To handle
such situations, an admission control procedure
must be included in the QoS control mechanism.
All these requirements have guided the design of the
QoS control mechanism presented in this paper.
3 RELATED RESEARCH WORK
There are many research works which deal with QoS
control mechanisms for provider servers. Most of the
mechanisms try to fulfill one of two objectives: either the
differentiation of the service provided to the consumers or
the management of the overload controlling the admission
of new service requests. There are also mechanisms that try
to fulfill the two objectives simultaneously. Below, the main
research works on QoS control mechanisms are analyzed.
3.1 Service Differentiation and Prioritization
The initial works [1], [2], [3] first classified the consumers or
their requests in classes, and then, scheduled the requests
of each class with different priorities. Pradhan et al. [4]
developed a system to classify the Web requests according
to their IP connection parameters, and then, share the CPU
between the classes to achieve the response time goals of
each class. Sharma et al. [5] proposed a mechanism to
manage the QoS by prioritization of the requests that arrive
at the server.
Schroeder and Harchol-Balter [6] proposed the SRTP
scheduling mechanism to improve the response times of
Web servers when they support transitory overloads. The
Web requests are classified automatically by the size of the
requested file, giving the highest priority to requests for
smaller files. McWerther et al. [7] developed prioritization
mechanisms of the transactions performed in database
environments to assure the QoS perceived by high
priority consumers. Later, Schroeder et al. [8] continued
this research by developing a transaction scheduler, which
operates interposed between the consumers and the server
to guarantee the fulfillment of the QoS requirements of
the transactions.
Totok and Karamcheti [9] developed a mechanism which
dynamically assigns higher priorities to the requests that
provide potentially a higher reward, typically higher
economic revenue. Wei et al. [10] developed a mechanism
that uses the slowdown metric, which is defined as the
relation between the waiting time suffered by the requests
and their service time.
There is also a set of mechanisms [11], [12], [13], [14]
based on the classic control theory whose objective is to
maintain the processing time of the requests around a
5
reference value independent of the load supported by the
server. These mechanisms combine feedback control loops
with feed-forward control actions based on the predictions
generated by queuing models. Lu et al. [15] demonstrated
that these mechanisms can also be used to provide a
relative differentiation of the processing time of the
requests of different consumers. Wei et al. [16] developed
similar mechanisms using a fuzzy control approach. Wei
and Xu [17] developed a double self-tuning controller to
adjust the processing rate of the requests of premium
customers, so these requests experience a processing delay
equal to the specified SLA. Wang et al. [18] developed the
AutoParam controller to adjust the processing capacity of
three virtual machines installed in the same physical server
in order to maintain the mean response time of transac-
tions around a reference value, called the Service Level
Objective (SLO).
When the server is a cluster organized in layers, the
utilization of these techniques is very difficult, because they
require a complex queuing model of the underlying cluster
that must be developed and adjusted for each particular
system. Some researchers try to avoid the problem of
building complex models of multitier servers using
identification techniques. Liu et al. [19] developed a
controller to maintain predefined ratios between QoS
metrics of several request classes. It uses an online recursive
least-squares estimator to obtain the parameters of a linear
MIMO model. This controller maintains the ratios under
overload conditions, and therefore, provides service differ-
entiation, but it is not able to guarantee the absolute SLA of
preferential requests.
3.2 Admission Control
One of the initial works on admission control was
developed by Cherkasova and Phaal [20]. They designed
an admission controller for Web servers that considered
the consumer sessions. Chen et al. [21] implemented a
mechanism similar to that proposed by Cherkasova and
Phaal, but they did not consider the concept of session.
Elnikety et al. [22] proposed the insertion of an admission
controller between the Web server and the database server
of an e-commerce server. The objective is to maximize the
throughput, which is not directly linked with the QoS
perceived by the consumers.
Kamra et al. [23] proposed an admission controller that
uses a PI controller and tested its behavior with the TPC-W
benchmark, but using a single SLA for all the requests
classes of the benchmark. Welsh and Culler [24] proposed a
mechanism to manage overloads in servers organized in
multiple logical and physical layers. It requires the assign-
ment of a maximum percentile of the response time to each
layer, which is difficult to specify.
Lee et al. [25] proposed a mechanism whose objective is
to maintain a predefined ratio between the waiting times
obtained for the requests corresponding to different
consumer categories when the load conditions of a Web
server vary. Other researchers [26], [27], [28] approach the
QoS control problem as an optimization problem of the
server operation.
6 IEEE TRANSACTIONS ON SERVICES COMPUTING,
TABLE 1
Related Work
3.3 Combination of Service Differentiation
and Admission Control
Bhatti and Friedrich [29] developed the WebQoS mechan-
ism to control the QoS in Web servers. It classifies the
requests into basic and premium classes. Basic requests
can be rejected to maintain the QoS of premium requests.
Bhoj et al. [30] developed the Web2K mechanism, which
also provides differentiated QoS to two types of requests.
Li and Jamin [31] designed an algorithm to distribute the
network bandwidth and the processing capacity of a Web
server among several classes of consumers. The requests
of a consumer class that do not have resources available
are rejected.
Urgaonkar and Shenoy [32] proposed an admission
control mechanism specifically designed to remain opera-
tional under extreme overloads. It increases its efficiency by
sorting out the requests in classes and admitting or rejecting
sets of requests instead of individual requests. Later,
Urgaonkar [33] introduced the concept of session into the
mechanism. Yue and Wang [34] developed a session-based
admission control system for e-commerce servers classify-
ing the clients into two classes: premium if they have
purchased products previously and basic if not. Under
overload conditions, the system first rejects the basic clients.
3.4 Analysis of the Mechanisms
Table 1 has been compiled to compare the QoS mechanisms.
Each column represents one QoS mechanism, labeled by its
reference number. Each row describes the level of fulfill-
ment of one of the requirements stated in Section 2. In the
table, there are three groups: the mechanisms focused
on service differentiation are on the left (those mainly based
on control theory are shadowed), those focused on admis-
sion control are in the centre, and the mechanisms focused
on both are on the right. A brief summary of the results of
Table 1 is given below.
Only a few mechanisms consider different classes of
requests (R1). There are also a few mechanisms that
consider several categories of customers (R2) and apply
service differentiation. Only two of the analyzed mechan-
isms consider both requirements simultaneously (R1 and
R2), although this is a great advantage.
The concept of consumer session (R3) is only considered
by a few mechanisms, although it is essential for Web
VOL. 2, NO. 1, JANUARY-MARCH 2009
applications (C2B environments) and is very useful for
secure Web services (B2B environments).
Most of the mechanisms analyzed are not independent of
the computing platform on which they operate (R4). Some
of them require modifications of the operating system,
and also many of them require modifications to the Web
server software. On the other hand, few of the mechanisms
require modifications to the Web applications running on
the server (R5).
The configuration of many QoS control mechanisms is not
easy (R6), because the manager must know its internal
operation and the configuration parameters are not related to
variables with physical meaning. Most of QoS control
mechanisms have been designed for a Web server operating
in a single computer, and only a few mechanisms have been
specifically designed including the capability of operating in
clusters (R7).
Finally, only the mechanisms that implement an admis-
sion control strategy are capable of managing sustained
overloads (R8).
As shown, most of the QoS control mechanisms analyzed
above fail to fulfill many of the requirements stated in
Section 2. The QoS control mechanism presented in this
paper provides specific solutions to the difficulties posed by
the previous QoS control mechanisms. Furthermore, it can
be applied to any kind of complex server, that is, not only to
Web servers, but to application servers as well.
4 DESIGN OF THE QOS CONTROL MECHANISM
To control the quality of service provided by a server,
sensors and actuators must be integrated in the server (see
Fig. 2). The sensors measure the controlled variables, such
as the response time of requests and the utilization of the
resources of the server. The actuators operate on the control
variables to modify the operation of the server, for example,
by changing the priority or the number of the server threads
which provide service to the requests.
The standard operation of a controller is based on
comparing the information received from sensors with the
objectives established by the administrator of the server.
Then, the controller executes a control algorithm which uses
the results of the comparisons to calculate the values of the
control variables that will be sent to the actuators.
GARCIA ET AL.: A QOS CONTROL MECHANISM TO PROVIDE SERVICE DIFFERENTIATION AND OVERLOAD PROTECTION TO INTERNET...
Fig. 2. Elements of a standard QoS control mechanism for a server.
In the following sections, we describe how the standard
QoS control mechanism has been adapted to our particular
environment, and how our proposed design for the QoS
control mechanism fulfils the requirements stated in
Section 2.
4.1 Architectural Design
Our proposed architectural design for the QoS control
mechanism is based on two components: a monitor and a
controller. The monitor is a software component which
encapsulates the sensors and the actuators of the QoS control
mechanism. The sensors are developed using measurement
functions provided by the run-time environment of the
server, and the actuators are implemented by means of an
admission procedure. The controller is also a software
component, which contains the QoS control algorithms.
When the QoS control mechanism is deployed in a
cluster server, there must be one monitor for each node of
the cluster, but only one controller is required for the whole
cluster. The controller is usually hosted in one of the nodes
Fig. 3. Deployment of the QoS control mechanism in a cluster server.
7
of the cluster, although it could be located in any other
computer connected to the cluster. Fig. 3 shows the
deployment of the QoS control mechanism in a load
balancing cluster, such as the one depicted in Fig. 1
(Requirement 7). In Fig. 3, the components of the QoS control
mechanism (the monitors and the controller) are repre-
sented in gray, and the flows of information between these
components and the other elements of the cluster are
depicted using dotted arrows.
As can be seen in Fig. 3, the monitors are located between
the application logic of the server and the consumers
(through the load balancer device). In this way, the
monitors can intercept the consumers’ requests for service,
as well as the responses supplied by the application logic of
the server. For each request and each response, the monitor
takes measurements and sends them to the controller,
which uses these measurements to calculate the response
times of the provided services.
With the proposed architectural design, the QoS control
mechanism operates as a front end subsystem of the server,
which is independent of the system software of the server
(Requirement 4) and its application logic (Requirement 5).
To take into account the grouping of requests in
business sessions (Requirement 3), whenever a consumer
demands the opening of a new session, the monitor sends a
new session request to the controller, which determines if
the session should be admitted or rejected. Then the
controller sends a message with this information to the
monitor, which admits or rejects the opening of the session
as required.
8 IEEE TRANSACTIONS ON SERVICES COMPUTING,
Fig. 4. Calculation procedure of the 90 percentiles of the response times.
4.2 Controller Design Strategy
A standard controller operates periodically, generating the
necessary values of one or more control variables to control
the evolution of one or more controlled variables. In the
case of our controller, the controlled variables are the
90 percentiles of the response times of all the Web services
provided by the server. The objective of the controller is to
maintain these percentiles under the predefined values
established in the SLA. To achieve this objective, the control
variable used by the controller is the available processing
capacity of the server, measured in business sessions
and differentiating between various consumer categories.
This variable controls the admission procedure located in
the monitors of the QoS control mechanism. Managing the
admission of new sessions, the number of concurrent
sessions processed by the server can be limited, so that
the maximum percentiles established in the SLA are not
surpassed. In the case of the SLA including requirements
of minimum throughputs, they could only be satisfied
for highest priority business sessions during server
overload periods.
The 90 percentiles of the response time are calculated
using the response time of the Web services completed
within a temporal window, which is displaced in time using
a tracking period, as shown in Fig. 4. In our experimental
environment, after carrying out a series of tests, we have
chosen the values of 100 seconds for the temporal window
and 10 seconds for the tracking period. These values make it
possible to detect load changes quickly while maintaining
an acceptable variance of the 90 percentiles.
The controller must calculate a new value of the control
variable (number of concurrent sessions) periodically.
Following the classic control theory, the common approach
to calculate new values of the control variable would
be based on the differences between the measured
90 percentiles and their maximum admissible values
defined by the SLA. However, the common approach poses
a serious problem, because the 90 percentile is a response
time metric which evolves with a significant delay with
relation to the load of the server, making this an unsuitable
variable on which to base the control on, since it would lead
to a delayed actuation with relation to that required.
Furthermore, the percentile is a noisy variable, which is
also an undesirable characteristic for a variable used as the
basis of a control system.
In the classic control theory, the usual procedure to
control the output variables of a system that can only be
VOL. 2, NO. 1, JANUARY-MARCH 2009
measured with delay is to use as an input-output model of
the system. The model is employed to estimate the values of
the outputs in a future time as a function of the current
inputs. Then, the estimated values of the outputs are used
by the controller instead of the real outputs, which are
not known.
The construction of an input-output model of the server
to estimate the 90 percentiles poses two main problems:
1) the delay of the 90 percentile is different for each service
and varies with the load of the server and 2) the dynamic
behavior of each service is quite different from the others.
Due to these problems, the construction of a dynamic model
of the server that provides the evolution of the 90 percentiles
over time is a complex task. Typical dynamic models
are simulation programs and linear difference equations
whose parameters must be reestimated periodically.
A more practical alternative to the dynamic model is the
construction of a static input-output model, which supplies
the expected steady-state values of the 90 percentile of each
service for any number of business sessions processed by
the server. In this way, this static model supplies the same
solution that would be provided by a dynamic model when
their output reaches the steady state. This approach, based
on a static model, is very reasonable to control a system
with a single input and multiple output variables, when the
behavior of the output variables differs greatly.
To obtain the model of the server, our approach is based
on characterizing the input-output behavior of the server
using a measurement technique. To this end, a sequence of
load experiments is carried out. In each experiment, the
server processes a fixed number of concurrent sessions, and
at the end of the experiment, the 90 percentile of the
response time of each Web service provided by the server is
calculated. After finishing all the experiments and calcula-
tions, a curve is generated for each service, which relates the
90 percentile of the response time of the service with the
number of sessions being processed. Then, using a regres-
sion technique, a fourth-order polynomial is fitted to each
curve. The set of calculated polynomials constitutes a
single-input multiple-output (SIMO) model. This model
provides the expected 90 percentiles of the response times
of all the Web services provided by the server as a function
of the concurrent sessions it processes.
Our approach is to use the SIMO model to determine the
maximum number of concurrent sessions that the server
can process, so that the maximum 90 percentiles established
in the SLA are not surpassed. This has an essential
advantage: the number of concurrent sessions is known
by the controller instantaneously, while the 90 percentiles
can only be known with delay. Therefore, the control based
on the concurrent sessions will lead to a more precise and
faster actuation. We refer to the maximum number of
concurrent sessions as the maximum admissible sessions.
Fig. 5 represents the curves of the SIMO model
corresponding to the Web services of the server, as well as
the calculation procedure of the maximum admissible
sessions using these curves. Each curve relates the number
of concurrent sessions being processed (S) with the
90 percentile of the response time of the corresponding
Web service (Pi ). In Fig. 5, the maximum 90 percentile
GARCIA ET AL.: A QOS CONTROL MECHANISM TO PROVIDE SERVICE DIFFERENTIATION AND OVERLOAD PROTECTION TO INTERNET...
Fig. 5. Calculation procedure of the maximum admissible sessions.
established in the SLA for the Web service i is called Pim .
Introducing each Pim in its corresponding curve, the number
of concurrent sessions (Sim ) corresponding to this percentile
is obtained. To guarantee the fulfilment of the SLA of all the
Web services provided by the server, the minimum value
obtained from all the Sim must be chosen as the maximum
admissible sessions. We refer to this value as S m .
Using the SIMO model, our mechanism is able to
manage different classes of Web services, each one with
its specific SLA (Requirement 1), simultaneously.
4.3 Controller Design and Operation
The controller has been designed to operate periodically. In
each control period, the controller calculates a new value of
the control variable (the available processing capacity).
After carrying out several tests, we have chosen a value of
10 seconds for the control period.
Fig. 6 depicts the controller design, showing the main
functional blocks of the controller and the flows of
information between them. Some functional blocks of the
controller are executed periodically, once each control
period. These functional blocks are depicted in black in
Fig. 6. Other functional blocks are executed asynchronously,
each time they have to respond to a determined event.
These functional blocks are depicted in gray.
The collector of measurements receives the measure-
ments sent by the monitors. The measurements contain the
measured response times of the Web services, and records
of the beginnings and ends of business sessions. The
collector of measurements stores the measured response
9
times in Buffer A. The calculator of the 90 percentiles
accesses this buffer periodically to calculate the percentiles
corresponding to each control period. The beginnings and
ends of sessions are forwarded to the session tracker, which
is in charge of calculating the instantaneous concurrent
sessions being processed by the server. This variable is
stored in Buffer B and represents the actual load processed
by the server.
The calculated 90 percentiles are not used in the control,
for the reasons stated in the previous section, but they are
supplied by the controller for information purposes.
Using these percentiles, the administrator of the server
can monitor the server behavior and verify that the
90 percentiles established in the SLA are fulfilled.
In each control period, the SIMO model of the server is
used to obtain the number of maximum admissible sessions
which can be accepted by the server. However, this is not
currently necessary, because the model could be used
offline to obtain the maximum admissible sessions and
eliminated from the controller. The reason for incorporating
the SIMO model of the server in the controller is to obtain a
controller design prepared for a future evolution of the
controller, in which the current fixed model (that is, a model
which does not change in time) will be substituted by an
adaptive model, which self-adjusts to slight variations in
the server behavior. In this future scenario, the model will
have to be used online.
At the beginning of each control period, the controller
compares the instantaneous concurrent sessions with the
maximum admissible sessions, and it obtains the current
admissible sessions, which are the sessions that the server
can admit during the current control period, so that the
maximum 90 percentiles are not surpassed. The value of the
current admissible sessions is supplied to the capacity
distributor, which calculates the differentiated available
processing capacity of the server. This value indicates the
number of sessions of each consumer category that can be
admitted in the server during the current control period.
Finally, the admission/rejection calculator is the element
in charge of admitting or rejecting the new session requests
sent from the monitors. This calculator uses the differen-
tiated available processing capacity to determine how
many sessions of each consumer category can be admitted
during the current control period. The available processing
capacity is recalculated at the beginning of each control
period and during the rest of the period the calculator
operates asynchronously, admitting or rejecting the new
session requests as they are received.
The detailed operation of the capacity distributor and the
admission/rejection calculator, as well as the algorithms
they use to manage the capacity of the server are described
in the following section.
4.4 Management of the Server Capacity
At the beginning of each control period, the available
capacity of the server is calculated by subtracting the
instantaneous concurrent sessions from the maximum
admissible sessions. The difference between these two values
becomes the total “entrance tickets” to the server for the
current control period. We call this value T0 . The value of T0
is sent to the capacity distributor (see Fig. 6), which is in
10 IEEE TRANSACTIONS ON SERVICES COMPUTING, VOL. 2, NO. 1, JANUARY-MARCH 2009

Fig. 6. Controller design.

charge of distributing the available capacity of the server (T0 ) Fig. 7 shows the algorithm which carries out the capacity
between the different categories of consumers trying to open distribution. The algorithm uses an auxiliary variable Taux ,
new business sessions in the server. To illustrate the which is initialized with the available tickets (T0 ), and then,
operation of our controller, three consumer categories are used to achieve the ticket distribution. After a set of
considered: gold, silver, and bronze. Nevertheless, our initializations, the algorithm begins reserving a number of
controller can operate with any number of categories.
The capacity distributor also uses the records stored in
Buffer C by the session tracker. This buffer holds the new
session requests, corresponding to each consumer category,
which have arrived in a determined number of past control
periods. By applying a moving average technique to the
records stored in Buffer C, the capacity distributor estimates
the new session requests corresponding to each consumer
category that are likely to arrive at the server during the
current control period. The estimated new session requests
for gold, silver, and bronze consumers are denoted by RG ,
RS , and RB , respectively.
Once RG , RS , and RB have been calculated, the capacity
distributor executes the algorithm which generates the
capacity distribution. This algorithm uses T0 , RG , RS , and
RB as inputs and generates TG0 , TS0 , TB0 , and TR0 as outputs.
TG0 , TS0 , and TB0 are the calculated entrance tickets for gold,
silver, and bronze consumers, respectively, and TR0 denotes
the remaining tickets, that is, the tickets that are left over
after the available tickets (T0 ) have been distributed among
the three consumer categories. Fig. 7. Capacity distribution algorithm.
GARCIA ET AL.: A QOS CONTROL MECHANISM TO PROVIDE SERVICE DIFFERENTIATION AND OVERLOAD PROTECTION TO INTERNET... 11

tickets for gold consumers equal to the estimated new

session requests of gold consumers for the current control
period RG . However, if the estimation RG is greater than the
available tickets T0 , all the tickets are reserved for gold
consumers. Next, the number of available tickets (stored in
Taux ) is decremented by the number of tickets already
reserved for gold consumers. The reservation procedure
continues with silver consumers and then with bronze
consumers. If there are tickets left at the end of the
reservation procedure, they are assigned to the remaining
tickets (TR0 ). These tickets can be used by consumers of any
category during the current control period.
The functional block that determines whether a new
session request should be admitted or rejected is the
admission/rejection calculator (see Fig. 6). This calculator
uses four variables to maintain the number of available
tickets of each consumer category, as well as the number of
remaining tickets, at every instant during the control
period. These variables are called TG , TS , TB , and TR . At
the beginning of the control period, these variables are
initialized with the distribution of entrance tickets calcu-
lated by the capacity distributor (TG0 , TS0 , TB0 , and TR0 ).
Thus, TG is initialized with TG0 , TS with TS0 , and so on.
Later, during the rest of the control period, variables TG ,
TS , TB , and TR are used by the calculator to determine
whether to admit or reject each new session request. When a
new session request arrives at the controller, the calculator Fig. 8. Algorithm for the returned ticket assignment.
first establishes the category of the consumer making
0
the request. Then, it checks the appropriate variable to uses three variables, called TG0 , TS0 , and TB , which, as in the
determine if there is an available ticket for that consumer case of TG , TS , and TB , are also initialized with values TG0 ,
category. If there is a ticket, the session is admitted and the TS0 , and TB0 at the beginning of the control period.
corresponding variable is decremented by one. If there are The algorithm for the returned ticket assignment starts
no available tickets, the calculator checks variable TR to by applying two security conditions to assure that gold
determine if a remaining ticket is available. If so, the session consumers and then silver consumers always have a
is admitted and TR is decremented. If not, the session minimum number of tickets. The minimum number of
is rejected. tickets for gold consumers is held in variable TGmin , and for
The admission/rejection calculator also manages the silver consumers, in variable TSmin . Both variables have been
end of each session. At the end of the sessions, the initialized with a value of one in the algorithm shown in
capacity of the server increases by one session, and Fig. 8. However, these variables could also be initialized
therefore, a new entrance ticket is generated. We refer to with a greater number to minimize the rejection of sessions
this ticket as the returned ticket. Then, the calculator must of these consumer categories. The next three conditional
assign the returned ticket to the available tickets of any of statements applied by the algorithm are the statements used
the consumer categories (TG , TS , or TB ) or to the remaining to complete the ticket reservation. The completion process
tickets (TR ). To achieve this assignment, the calculator in a category finishes when the total assigned tickets to the
0 0 0
executes the algorithm for the returned ticket assignment category (TG , TS , or TB ) reaches the number of estimated
shown in Fig. 8. The strategy followed by this algorithm to new sessions of the category for the control period (RG , RS ,
assign each returned ticket to a category is based on the or RB ). Finally, if the returned ticket has not been used to
completion of the ticket reservation carried out by the satisfy any of the previous conditions of the algorithm, it is
capacity distributor at the beginning of the control period. assigned to the remaining tickets (TR ).
The capacity distributor generates the ticket reservation
(TG0 , TS0 , and TB0 ), allocating the available tickets (T0 ) to
the different consumer categories, according to the 5 EXPERIMENTAL ENVIRONMENT
estimated new session requests for the three categories in The proposed QoS control mechanism has been tested on a
the control period (RG , RS , and RB ). If the number of representative B2B environment: the TPC-App benchmark
available tickets (T0 ) is less than the total estimated deployed on a cluster server. This benchmark emulates a
requests in the control period (RG þ RS þ RB ), the ticket transactional application server which provides services to
reservation is incomplete. The objective of the algorithm is other servers in a B2B environment. Fig. 9 shows a schematic
to complete this reservation, assigning each returned ticket representation of the interactions implemented in the TPC-
first to gold, next to silver, and finally to bronze App benchmark. As can be seen in the figure, the benchmark
consumers. To assign the returned ticket, the algorithm supplies seven Web services to the service consumers, and
12 IEEE TRANSACTIONS ON SERVICES COMPUTING,
Fig. 9. Interactions in the TPC-App benchmark.
uses four other external Web services, which emulate services
provided by external enterprises. All the services supplied by
the TPC-App use a database to store and retrieve data.
Additional information about the design and implementa-
tion of the TPC-App can be found in [35].
Fig. 10 shows the experimental environment. This is
made up of the TPC-App benchmark, the emulator of
service consumers, and the emulators of external services,
as well as their corresponding computing platforms. As can
be seen in the figure, the benchmark is deployed in a cluster
Fig. 10. Experimental environment.
VOL. 2, NO. 1, JANUARY-MARCH 2009
of two layers: the application layer and the data layer. The
application layer is arranged in a load balancing cluster of
three nodes, and the data layer, in a single server. Both the
load balancing cluster and the single server make up the
complete cluster executing the TPC-App. All the computers
of the complete cluster are identical biprocessors based on
Pentium Xeon 1 GHz running the Windows Server 2003
operating system. In addition to the complete cluster, two
additional single servers are used to host the emulator of
service consumers and the emulators of external services.
The application logic of the benchmark has been
implemented using the support of the WebLogic run-time
environment of BEA Systems, which provides a set of
clustering facilities. This environment uses a load balancer
to distribute the Web service requests between the nodes of
the cluster using round-robin scheduling. The load balancer
is located in a different node from the nodes executing the
TPC-App application logic. In this way, the two nodes
executing this logic support the same average load. Fig. 10
also shows (shaded in gray) the integration of the
components of the QoS control mechanism in the load
balancing cluster. One monitor is located in each node
executing the TPC-App application logic, and the controller
is placed in the load balancing node.
The QoS control mechanism requires that the service
consumer emulator includes two pieces of information in
each service request: the consumer category making the
request (gold, silver, or bronze) and the type of request,
which indicates if this starts, finishes, or is within a business
session. These pieces of information are inserted in the
header of the SOAP protocol used to encapsulate the request.
Thus, the software of the application logic of the benchmark
does not require any modification, and therefore, the QoS
control mechanism behaves as a transparent element with
relation to the application executed by the cluster.
GARCIA ET AL.: A QOS CONTROL MECHANISM TO PROVIDE SERVICE DIFFERENTIATION AND OVERLOAD PROTECTION TO INTERNET... 13

6 EXPERIMENTAL RESULTS
Before beginning the experimentation to demonstrate
the correct operation of the QoS control mechanism, a
reasonable set of values for the parameters of the controller
must be determined. These parameters are the length of the
temporal window and the tracking period used to calculate
the 90 percentiles, the maximum 90 percentiles (SLA), the
control period, and the length of the moving average filter
used to estimate the RG , RS , and RB values (introduced in
Section 4.4).
At this stage of the experimentation, the length of the
temporal window and the tracking period used to calculate
the 90 percentiles are already known, because they were
determined during the experimentation carried out to
calculate the SIMO model of the cluster. We have chosen
the values of 100 seconds for the temporal window and
10 seconds for the tracking period. With these values, the
calculated percentiles behave without excessive variance,
and the computational cost required for their calculation
is acceptable.
To determine the unknown parameters of the control-
ler, it is advisable to carry out a set of experiments with
the experimental environment depicted in Fig. 10, but with
the QoS control mechanism deactivated. Thus, we obtain a
Fig. 11. Temporal evolution of the concurrent sessions processed by the
view of the behavior of the complete TPC-App cluster
cluster.
without control. Using the information obtained from
these experiments, the values of the unknown parameters
of the controller are established. In the rest of the paper, All the parameters of the controller have clear physical
we refer to the complete TPC App-cluster as simply senses, highly comprehensible for server administrators.
“the cluster.” Moreover, suitable values for all the parameters can be
The first objective of our experimentation is to establish deduced from measurements obtained from the server
the maximum 90 percentiles, that is, the SLA. To achieve operating with the controller deactivated. Due to these
this, we carry out an experiment based on progressively characteristics of the controller parameters, the configura-
incrementing the number of emulated service consumers tion procedure of the controller can be achieved without
until the cluster goes into saturation. At this point, we detect excessive difficulty (Requirement 6).
that the bottleneck resources saturating the cluster are the Once the parameters of the controller have been
CPUs of the nodes executing the TPC-App application logic, determined, the next stage in the experimentation is to test
and we observe that the number of concurrent sessions the correct operation of the QoS control mechanism. Two
being processed is 30. Next, the 90 percentiles of the main aspects of the mechanism are tested: its ability to
response times of the Web services provided by the cluster protect the cluster from overloads and its ability to provide
are calculated. When the load injected in the cluster by the differentiated service to the distinct consumer categories.
emulated service consumers takes the cluster beyond its The QoS control mechanism is activated with the
saturation point (30 sessions), the response times of the Web controller configured using the values of the parameters
services supplied by the cluster begin to degrade signifi- previously discussed, and the service consumer emulator
cantly. Thus, we can consider the number of sessions at this (see Fig. 10) is configured to generate the load depicted in
point as the maximum admissible load for the cluster and the top graph of Fig. 11. This graph shows the evolution of
their corresponding 90 percentiles, a reasonable limit at the number of consumers trying to open new sessions. The
which to establish the SLA. graph begins at second 2,500. The previous seconds, not
An analysis of the behavior exhibited by the cluster in the shown in the figure, correspond to a warming phase of the
previous experiment also allows us to determine a suitable cluster, in which this is exposed to a high load in order to
value for the control period. We have chosen a value of 10 warm its caches and deploy its resources. Later, the graph
seconds. This value is short enough so that the controller can shows that the cluster supports two overload periods: the
react to changes in the load of the cluster with the necessary first one between seconds 3,000 and 4,000, in which
speed. Furthermore, its computational cost is acceptable. 60 consumers try to open new sessions; and the second
Finally, the length of the moving average filter used in one between seconds 5,000 and 6,000, where 90 consumers
the estimation of RG , RS , and RB is set at four control try to open new sessions. The proportion of service requests
periods. With this length, the number of new session corresponding to the different consumer categories is
requests received during this time interval is sufficient to established at 20 percent for gold, 30 percent for silver,
obtain reasonable estimations for RG , RS , and RB . and 50 percent for bronze.
14 IEEE TRANSACTIONS ON SERVICES COMPUTING,
Fig. 12. Evolution of the response times of the seven Web services
provided by the TPC-App benchmark.
The bottom graph of Fig. 11 shows the evolution of
the concurrent sessions processed by the cluster. The
figure demonstrates that during the overload periods, the
controller is able to limit the load of the cluster to
30 concurrent sessions, since this is the limit corresponding
to the established SLA (Requirement 8).
Fig. 12 shows the temporal evolution of the 90 percentiles
of the response times of the seven Web services supplied by
the TPC-App benchmark. In each graph of the figure, the
corresponding maximum 90 percentile defined in the SLA
is depicted using a dashed line. It can be observed that the
controller is capable of limiting the 90 percentiles during the
VOL. 2, NO. 1, JANUARY-MARCH 2009
Fig. 13. Comparison of the new session requests and the admitted
sessions for each consumer category along the successive control
periods.
overload periods. However, as in the case of the concurrent
sessions, the controller limits the average value and not the
instantaneous value of the percentiles. For this reason,
values over and under the SLA can be observed in the
temporal evolution of the percentiles.
In order to verify the correct operation of the QoS control
mechanism, the graphs of Fig. 13 have been constructed.
Each graph of this figure corresponds to a determined
consumer category, and shows a comparison between the
new session requests of that category arriving at the cluster
and the sessions finally admitted. In these graphs, the
values of new session requests are represented by points,
and the values of admitted sessions by squares. Graphi-
cally, a point surrounded by a square means that all
the new session requests arriving at the cluster in the
corresponding period have been admitted. A square placed
between its matching point and the time axis means that
part of the new session requests are admitted and the rest
are rejected. Finally, when the square corresponding to a
point is located on the time axis, this means that all the new
session requests have been rejected.
Fig. 13 shows that all the new session requests are
admitted (squares always surround points) in periods
[2,500-3,000], [4,000-5,000], and [6,000-6,500] for the three
consumer categories. These periods correspond to the
time intervals in which the cluster supports a load of
10 concurrent sessions, which is far from the maximum
load for which the SLA has been defined (30 concurrent
sessions). Therefore, when the current load supported by
the cluster is below the maximum admissible load
determined from the SLA, the QoS control mechanism
does not reject any new session requests.
GARCIA ET AL.: A QOS CONTROL MECHANISM TO PROVIDE SERVICE DIFFERENTIATION AND OVERLOAD PROTECTION TO INTERNET...
Fig. 13 shows that during the first overload period
(interval [3,000-4,000]), very few new session requests
corresponding to gold consumers are rejected. The
number of rejections increases for silver consumers, and
finally, in the case of bronze consumers, most of the
requests are rejected. During the second overload period
(interval [5,000-6,000]), more intense in load, the number
of rejections of new session requests corresponding to
gold consumers increases slightly. This effect is much
more notable for silver consumers, and extreme in the
case of bronze consumers, for which all the new session
requests are rejected.
This experiment demonstrates that the QoS control
mechanism carries out an effective differentiation of the
service provided to consumers, reserving the processing
capacity of the cluster for the preferential consumers
during the overload periods (Requirement 2). Moreover, as
expected, the QoS control mechanism does not produce
overreservation of processing capacity for the preferential
consumers when the cluster operates under normal
load conditions.
7 CONCLUSIONS AND FUTURE WORK
The first relevant contribution of this work is the definition
of the requirements that any QoS control mechanism for a
provider server working in a B2B environment should
address. Most of the current available mechanisms fail to
address many of these requirements.
The second important contribution is the development of
a new QoS control mechanism, specifically designed to
fulfil the established requirements. This mechanism con-
siders classes of requests and categories of consumers; it
groups the requests carried out by consumers in secure
sessions; it also guarantees the SLAs during overloads,
giving priority to the service of preferential consumers; it is
independent of the system software of the server, as well as
of its application logic; and the adjustment of its configura-
tion parameters is very simple.
This research work not only presents a new QoS control
mechanism, but also establishes the basic design principles
for these mechanisms. These principles can be used as a
reasonable starting point in the design of the QoS control
mechanisms in the near future.
The next step in this research will be the substitution
of the fixed SIMO model used in the calculation of the
maximum admissible sessions for an adaptive model. The
input-output behavior of a server can change slightly
during its operation, so an adaptive model can reproduce
the server behavior more precisely than a fixed model can.
REFERENCES
[1] L. Eggert and J. Heidemann, “Application-Level Differentiated
Services for Web Servers,” World-Wide Web J., vol. 2, no. 3, pp. 133-
142, Aug. 1999.
[2] J. Almeida, M. Dabu, A. Manikutty, and P. Cao, “Providing
Differentiated Levels of Service in Web Content Hosting,” Proc.
First Workshop Internet Server Performance (WISP ’98), June 1998.
[3] T.F. Abdelzaher and K.G. Shin, “QoS Provisioning with qCon-
tracts in Web and Multimedia Servers,” Proc. 20th Real-Time
Systems Symp. (RTSS ’99), pp. 44-53, Dec. 1999.
15
[4] P. Pradhan, R. Tewari, S. Sahu, C. Chandra, and P. Shenoy, “An
Observation-Based Approach Toward Self-Managing Web Ser-
vers,” Proc. 10th Int’l Workshop Quality of Service (IWQoS ’02), May
2002.
[5] A. Sharma, H. Adankar, and S. Sengupta, “Managing QoS
Through Prioritization in Web Services,” Proc. Fourth Web
Information Systems Eng. Workshop (WISEW ’03), pp. 140-148,
Dec. 2003.
[6] B. Schroeder and M. Harchol-Balter, “Web Servers Under Over-
load: How Scheduling Can Help,” Technical Report CMU-CS-02-
143, Computer Science Dept., Carnegie-Mellon Univ., 2002.
[7] Y. McWherter, B. Schroeder, A. Ailamaki, and M. Harchol-Balter,
“Priority Mechanisms for OLTP and Transactional Web Applica-
tions,” Proc. Int’l Conf. Data Eng. (ICDE ’04), pp. 535-546, 2004.
[8] B. Schroeder, M. Harchol-Balter, A. Iyengar, and E.M. Nahum,
“Achieving Class-Based QoS for Transactional Workloads,” Proc.
22nd Int’l Conf. Data Eng. (ICDE ’06), p. 153, Apr. 2006.
[9] A. Totok and V. Karamcheti, “Improving Performance of Internet
Services through Reward-Driven Request Prioritization,” Proc.
14th Int’l Workshop Quality of Service (IWQoS ’06), June 2006.
[10] J. Wei, X. Zhou, and C.-Z. Xu, “Robust Processing Rate Allocation
for Proportional Slowdown Differentiation on Internet Servers,”
IEEE Trans. Computers, vol. 54, no. 8, pp. 964-977, Aug. 2005.
[11] L. Sha, X. Liu, Y. Lu, and T. Abdelzaher, “Queueing Model Based
Network Server Performance Control,” Proc. 23th IEEE Real-Time
Systems Symp. (RTSS ’02), pp. 81-90, Dec. 2002.
[12] D. Henriksson, Y. Lu, and T. Abdelzaher, “Improved Prediction
for Web Server Delay Control,” Proc. 16th Euromicro Conf. Real-
Time Systems (ECRTS ’04), pp. 61-68, June 2004.
[13] X. Liu, R. Zhang, J. Heo, Q. Wang, and L. Sha, “Timing
Performance Control in Web Server Systems Utilizing Server
Internal State Information,” Proc. Int’l Conf. Networking and Services
(ICNS ’05), Oct. 2005.
[14] J. Heo, X. Liu, L. Sha, and T. Abdelzaer, “Autonomous Delay
Regulation for Multithreaded Internet Servers,” Proc. Int’l Symp.
Performance Evaluation of Computer and Telecomm. Systems (SPECTS
’06), pp. 465-472, July 2006.
[15] Y. Lu, T. Abdelzaher, C. Lu, L. Sha, and X. Liu, “Feedback Control
with Queuing-Theoretic Prediction for Relative Delay Guaranties
in Web Servers,” Proc. Ninth Real-Time Technology and Applications
Symp. (RTAS ’03), May 2003.
[16] Y. Wei, C. Liu, T. Voigt, and F. Ren, “Fuzzy Control for
Guaranteeing Absolute Delays in Web Servers,” Proc. Second Int’l
Conf. Quality of Service in Heterogeneous Wired-Wireless Networks
(QSHINE ’05), Aug. 2005.
[17] J. Wei and C.-Z. Xu, “eQoS: Provisioning of Client-Perceived End-
to-End QoS Guarantees in Web Servers,” Proc. 13th Int’l Workshop
Quality of Service (IWQoS ’05), pp. 123-135, June 2005.
[18] Z. Wang, X. Liu, A. Zhang, C. Stewart, X. Zhu, T. Kelly, and S.
Singhal, “Autoparam: Automated Control of Application-Level
Performance in Virtualized Server Environments,” Proc. Second
IEEE Int’l Workshop Feedback Control Implementation and Design in
Computing Systems and Networks (FeBID ’07), pp. 2-7, 2007.
[19] X. Liu, X. Zhu, P. Padala, Z. Wang, and S. Singhal, “Optimal
Multivariate Control for Differentiated Services on a Shared
Hosting Platform,” Proc. 46th IEEE Conf. Decision and Control
(CDC ’07), pp. 12-14, Dec. 2007.
[20] L. Cherkasova and P. Phaal, “Session-Based Admission Control: A
Mechanism for Peak Load Management of Commercial Web
Sites,” IEEE Trans. Computers, vol. 51, no. 6, pp. 669-685, June 2002.
[21] X. Chen and P. Phaal, “An Admission Control Scheme for
Predictable Server Response Time for Web Accesses,” Proc. 10th
World Wide Web Conf. (WWW ’01), pp. 545-554, May 2001.
[22] S. Elnikety, E. Nahum, J. Tracey, and W. Zwaenepoel, “A
Method for Transparent Admission Control and Request
Scheduling in E-Commerce Web Sites,” Proc. 13th World Wide
Web Conf. (WWW ’04), May 2004.
[23] A. Kamra, V. Misra, and E. Nahum, “A Self-Tuning Controller for
Managing the Performance of 3-Tiered Web Sites,” Proc. 12th Int’l
Workshop Quality of Service (IWQoS ’04), June 2004.
[24] M. Welsh and D. Culler, “Adaptive Overload Control for Busy
Internet Servers,” Proc. Fourth USENIX Conf. Internet Technologies
and Systems (USITS ’03), Mar. 2003.
[25] S.C. Lee, J.C. Lui, and D.K. Yau, “A Proportional-Delay Diffserv-
Enabled Web Server: Admission Control and Dynamic Adapta-
tion,” IEEE Trans. Parallel and Distributed Systems, vol. 15, no. 5,
pp. 385-400, May 2004.
16 IEEE TRANSACTIONS ON SERVICES COMPUTING,
[26] D. Menasce and M. Benanni, “On the Use of Performance Models
to Design Self-Managing Systems,” Proc. 29th Int’l Computer
Measurement Group Conf., Dec. 2003.
[27] D. Menasce, M. Benanni, and H. Ruan, “On the Use of On-Line
Analytic Performance Models in Self-Managing and Self-Organiz-
ing Computer Systems,” Self-Star Properties in Complex Information
Systems, pp. 128-142, 2005.
[28] M. Bennani, “Autonomic Computing Through Analytic Perfor-
mance Models,” PhD dissertation, Computer Science Dept.,
George Mason Univ., May 2006.
[29] N. Bhatti and R. Friedrich, “Web Server Support for Tiered
Services,” IEEE Network Magazine, vol. 13, no. 5, pp. 64-71, 1999.
[30] P. Bhoj, S. Ramanathan, and S. Singhal, “Web2K: Bringing QoS to
Web Servers,” technical report, Internet Systems and Applications
Laboratory, HP Laboratories, May 2000.
[31] K. Li and S. Jamin, “A Measurement-Based Admission-Controlled
Web Server,” Proc. IEEE INFOCOM, Mar. 2000.
[32] B. Urgaonkar and P. Shenoy, “Cataclysm: Policing Extreme
Overload in Internet Applications,” Proc. 14th World Wide Web
Conf., pp. 740-749, May 2005.
[33] B. Urgaonkar, “Dynamic Resource Management in Internet
Hosting Platforms,” PhD dissertation, Computer Science Dept.,
Univ. of Massachusetts, Amherst, Sept. 2005.
[34] C. Yue and H. Wang, “Profit-Aware Admission Control for
Overload Protection in E-Commerce Web Sites,” Proc. 15th IEEE
Int’l Workshop Quality of Service (IWQoS ’07), June 2007.
[35] D. Garcı́a, J. Garcı́a, M. Garcı́a, I. Peteira, R. Garcı́a, and P.
Valledor, “Benchmarking of Web Services Platforms: An Evalua-
tion with the TPC-App Benchmark,” Proc. Int’l Conf. Web
Information Systems and Technologies (WEBIST ’06), pp. 75-80,
Apr. 2006.
Daniel F. Garcı́a is a professor in the Depart-
ment of Computer Science and Engineering,
University of Oviedo, Spain. Since 1994, he has
been leading the computer engineering area at
the University of Oviedo. His current research
interest is in the area of computer performance
engineering and quality of service of computer
systems. For the last 10 years, he has been
conducting research projects in the area of
information technologies at the national and
European levels. He is a member of the IEEE, the ACM, and the IEEE
Computer Society.
Javier Garcı́a received the PhD degree in
electrical engineering from the University of
Oviedo. He is an associate professor in the
Department of Computer Science and Engineer-
ing, University of Oviedo, Spain, where he
teaches courses in computer architecture. His
research interests are in the performance
evaluation of computer systems and autonomic
computing.
Joaquı́n Entrialgo received the MS degree in
computer science in 1998 and the PhD degree in
2006. He is an associate professor in the
Department of Computer Science and Engineer-
ing, University of Oviedo, Spain. His main
research interests are monitoring of real-time
systems and performance evaluation of compu-
ter systems.
VOL. 2, NO. 1, JANUARY-MARCH 2009
Manuel Garcı́a received the Industrial Engineer-
ing degree and the Ph.D. degree with a thesis
devoted to the analysis and modeling of hybrid
fiber-coaxial (HFC) networks from the University
of Oviedo, Spain, in 1992 and 2003, respec-
tively. From 1993 to 1994, he worked at the
university with a grant. In 1994, he became an
assistant professor, and in 2001, he became an
associate professor in the Department of Com-
puter Science and Engineering, University of
Oviedo. He has taken part in research projects on real-time inspection
systems based on vision techniques and performance analysis of HFC
networks. His current research interests are computer and telecommu-
nications systems performance evaluation.
Pablo Valledor received the MS degree in
computer engineering from the Polytechnic
Engineering School, University of Oviedo, in
2006. He worked for the R&D Department of
CTIC Foundation (Centre for the Development
of Information and Communication Technolo-
gies in Asturias) until February 2007, when he
joined the ArcelorMittal R&D Technological
Centre (CDT) as a research engineer. He also
collaborates with the computer engineering area
at the University of Oviedo. He has participated in several projects using
his expertise in topics like data mining, optimization, semantic Web
technologies, quality of service assurance in cluster environments, and
radioeletric signal simulation.
Rodrigo Garcı́a received the MS degree in
computer science from the University of Oviedo,
Spain, in 2008. He is currently working for the
R&D Department of CTIC Foundation. His
research interests are in the areas of computer
performance engineering and distributed and
Internet computing systems.
Antonio M. Campos received the MS degree in
electronic and automatic engineering and the
PhD degree in computer science from the
Industrial Engineering School, University of
Oviedo, Spain. He is currently responsible for
the Department of R&D of CTIC Foundation,
Gijon, Spain, where he is involved with IT
research projects at the national and European
levels. He is also an associate professor in the
Department of Computer Science and Engineer-
ing, University of Oviedo. He has written and edited many papers and
participates actively in different Spanish and European Industrial
Research Initiatives.