P1: IML/FFX P2: IML/FFX QC: IML/FFX T1: IML
Web ̇QOS WL040/Bidgoli-Vol III-Ch-58 July 16, 2003 9:36 Char Count= 0
714 WEBQUALITY OFSERVICEbudget is said to have expired. When a budget expires,
processes charged to that budget are blocked until the
next replenishment period. Hence, these processes cannot
jointly exceed the CPU allocation specified for their Web
site.
One limitation of the aforementioned technique is the
way accounting is done in the operating system. The party
that the CPU is working for at any given time is identified
in the operating system as either the kernel or a particular
user process. Hence, only total kernel execution time and
the total execution time of any single process can be mea-
sured. In particular, kernel execution time is not properly
broken into independent activities. For example, the
kernel-processing time of incoming requests is not prop-
erly attributed to the site for which the requests are des-
tined and is thus not charged properly to the correct re-
serve. The problem is particularly severe in monolithic
operating systems such as Linux, as opposed to microker-
nels such as RT Mach. In monolithic operating systems
the entire TCP/IP protocol stack processing is done in the
kernel and is therefore not properly accounted for. A dif-
ferent accounting mechanism is needed.
Resource containers (Banga, Druschel, & Mogul, 1999)
have recently been proposed as a new operating system
abstraction for resource reservation and performance iso-
lation in monolithic kernels running server end systems.
The authors of this approach make the observation that
the accounting problem arises from the fact that in tradi-
tional operating systems the resource principal (i.e., the
system entity capable of owning resources) is generally
associated with a protection domain (such as a process).
In server end-systems, this association is not appropriate.
The logical resource principal could be a user or a content
provider. Depending on the server architecture, multiple
processes can serve the same principal, or a single pro-
cess can serve multiple principals. The resource princi-
pals should be charged for processing that occurs both
on the kernel level and in user space. Banga et al. (1999)
propose the abstraction of resource containers to resolve
the dichotomy. In this approach, packet filters are placed
at the lowest level of the protocol stack. These filters
demultiplex incoming traffic into distinct categories, e.g.,
by IP address. All kernel and user-level processing of traffic
in each category is charged to the corresponding resource
container. As before, when the container is exhausted, the
operating system stops processing the corresponding traf-
fic type until the container is replenished. The approach
has been shown to provide excellent isolation. It has also
been shown to be very efficient in isolating denial of ser-
vice attacks.
The need for early demultiplexing presents several
challenges of its own. Such demultiplexing is typically
performed based on fields in the TCP or IP headers. Un-
fortunately, in many Web applications, client classifica-
tion is a little more complex (Menasce, Almeida, Fon-
seca, & Mendes, 2000). For example, if classification is
based on accessed content, the operating system will have
to peek into the HTTP header, which is an application-
layer header, to determine the accessed URL. This clearly
violates the modularity of the layered network architec-
ture and requires the kernel to be aware of application-
specific URL names. A more difficult case is that of aWeb server hosting an e-shopping site, which may wish
to classify clients based on the contents of their shop-
ping carts. A widely quoted example of this policy is giv-
ing clients with more expensive purchases higher priority
at checkout to ensure successful completion of their pur-
chase transactions. In this case, the classification informa-
tion necessary for identifying client priority is not avail-
able to the operating system, because the contents of the
shopping cart are an application-specific data structure.
Designing general-purpose mechanisms to express such
classification constraints at the operating system level is
a challenging task, unless one is willing to sacrifice the
application-independent nature of general-purpose oper-
ating systems.
Another complication is that packets arriving at the
bottom of the protocol stack (e.g., IP fragments) may
not always have an application-layer header, which con-
tains the information necessary for classification. These
headers would be reconstructed higher in the commu-
nication protocol stack, which makes early classification
more challenging. Construction of efficient packet filters
for early classification based on application-specific infor-
mation is therefore an important research challenge.Middleware Approaches
When client classes are defined in an application-specific
manner, a different solution to performance isolation is
to develop middleware that augments generic operating
system support with application-specific middleware poli-
cies. The operating system approach, described in the pre-
vious section, is perhaps the most efficient approach for
fine-grained performance isolation. However, it suffers
from the lack of generality and the lack of portabil-
ity. The former refers to the difficulty of incorporating
application-specific classification policies into the kernel.
The latter (i.e., portability) stems from the fact that sup-
port for time-multiplexed resource reservation described
above is still far from being a standard operating sys-
tem feature. Thus, performance isolation solutions that
do notrequirethis support in the operating system are
often preferred. These considerations lead to middleware
solutions.
Middleware refers to any software layer that runs
below the application and above the operating system.
Generally, there are two types of middleware: that which
is transparent to the application and that which requires
application modification to adhere to a new interface. The
former is more general in that it does not require access
to application source code. Hence, a hosting service, for
example, can develop in-house middleware components
even when the source code for the Web server and the op-
erating system is not available. Similarly, a middleware
vendor can develop its software independently to inter-
operate with multiple Web server and operating system
products without the need to modify their code.
An important challenge in designing transparent mid-
dleware services is to architect their (transparent) interac-
tion with the server software. Such interaction is usually
implemented by instrumenting standard dynamic shared
libraries used by the server. Dynamic shared libraries are
those loaded by the server at run time, as opposed to being
precompiled together with server code. This feature is