The Internet Encyclopedia (Volume 3)

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

718 WEBQUALITY OFSERVICE

In the context of time-related performance metrics, it

is interesting to classify the convergence guarantee loops

depending on the performance variable being controlled.

As is the case with physical plants, the controlled output

of interest affects the model of the system and whether

the control loop is linear or not. Because most of control

theory was developed for linear processes, the ability to

satisfy the convergence guarantee is often contingent on

the ability to approximate the server well by a linear

model.

To a first approximation, rate metrics and queue length

are easiest to control because they result in linear feed-

back loops. Rate can be controlled in much the same

way physical flow is controlled in pipes. Queue length is

simply the integral of rate, and therefore is also linear.

Delay guarantees are more difficult to provide. This is be-

cause delay is inversely proportional to flow. If a request

arrives at a queue of lengthQ, with a dequeueing rate

ofr, the queuing delay,d, of the request isd=Q/r. The

inverse relation between the manipulated variable (rate)

and the delay makes the control loop nonlinear. At present,

providing convergence guarantees on delay remains an

active research topic.

Challenges

In the previous section we outlined the semantics of the

most important types of performance guarantees. Next we

describe challenges that are common to achieving these

guarantees in Web servers.

Admission Control

A common enforcement mechanism of many QoS guar-

antee types in Web servers is client admission control.

An important decision in the design of an admission con-

troller is to choose the entity being admitted or rejected.

In a Web server, admission control can operate on indi-

vidual requests, individual TCP connections, or individual

client sessions.

Per-request admission control is the simplest to imple-

ment, but has serious limitations. Consider an overloaded

server operating at 300% capacity. Statistically, this means

that two out of three requests must be rejected on average.

For simplicity assume that all clients belong to the same

class. Because client browsers typically issue multiple

requests over the duration of the client’s interaction with

the server (even when downloading a single page), per-

request admission control will uniformly cause each client

to encounter failures in two thirds of the accesses. Such

service is virtually unusable. Per-request admission con-

trol discriminates against longer sessions. This has very

negative implications, especially from an e-commerce

perspective. For example, it has been shown in many

studies that those e-shoppers who eventually complete a

purchase from an online server typically have longer ses-

sions with the server than occasional visitors who do not

buy. Hence, discriminating against longer sessions gives

a lower QoS precisely to those users who are more likely

to generate revenue.

A better admission control scheme is to select a consis-

tent subset of clients to admit. Those clients are admitted

as long as they continue to send requests to the server

within a specified time interval. The rest are consistently

rejected. This scheme succeeds in making the service

usable by at least some consistent subset of clients.

This scheme is commonly calledsession-based admis-

sion control. It was first analyzed at length for Web

servers by Cherkasova and Phaal (1999) and continues

to be an important research topic (Chen & Mohapatra,

2002). Session-based admission control is more difficult

than per-request admission control because at the time a

session is admitted the server has no knowledge of the

future load that it may impose. Hence, it is difficult to

decide how many sessions can be admitted before server

capacity is exceeded. Different clients can impose sub-

stantially different load demands. For example, if the ad-

mitted client is a Web crawler, it may impose a much

larger load than a human user. This difficulty is usually

resolved by adding feedback into the admission control

loop. The admission controller must continuously refine

the subset of clients to be admitted based on measure-

ments of resulting load. Feedback-based admission con-

trol schemes work very well in practice.

Client Authentication

An issue related to admission control is that of client iden-

tification. The simplest scheme is to identify the clients

by their IP addresses. This identification, however, is not

accurate. In several cases, the IP address of the client is

unavailable to the server. For example, it is possible that

the client is behind a firewall or a proxy. In this case, it is

the proxy’s IP address that is seen by the server, not the

client’s.

To identify clients, Web servers may use “cookies,”

which work similarly to passwords. The server sends a

cookie to a client upon the first access. The client’s browser

automatically presents the server with this cookie when

subsequent accesses are made. The server is therefore able

to identify accesses that belong to the same client and sep-

arate them from those of another. This capability may be

used to implement session-based admission control. In

general, cookies have several security flaws. For exam-

ple, it is possible for cookies to be copied, allowing a third

party to impersonate the client. Moreover, cookies are sent

in plain text. A better mechanism would be to encrypt the

transfer. Such encryption may be provided at a lower level

such as the secure socket layer.

Rejection Cost

Another issue tightly related to admission control is the

cost of rejecting an incoming request. If admission con-

trol is based on the client identity obtained from browser-

supplied cookies, a connection cannot be classified early

inside the kernel. Instead, all requests have to reach the

application layer, where the server process can interpret

the cookies and identify them as belonging to a particular

class. Now imagine an overloaded server, which decides to

admit all requests of class A and reject all requests of class

B. Because the kernel cannot tell the two classes apart,

all requests are forwarded to the application layer after

being processed in the kernel. Kernel processing, as men-

tioned before, takes a nonnegligible overhead. This over-

head is incurred whether the request is accepted or not. In

particular, it is incurred for each rejected request. It is