A protocol for improved user perceived QoS

in Web transactional applications

A Technical Seminar Report
Submitted in partial fulfilment of the requirements for the award of the

Degree of

Bachelor of Technology

in

COMPUTER SCIENCE AND ENGINEERING

By

P.UDAYASRI

(10191A0544)

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

JNTUA COLLEGE OF ENGINEERING
PULIVENDULA-516390
ABSTRACT
 Quality-of-Service (QoS) provisioning in the Internet has been a topic of active research
in the last few years. However,due to both financial and technical reasons, the proposed
solutions are not commonly employed in practice. As a consequence, the Internet architecture
is still mainly oriented to a best effort delivery model, which does not provide any guarantee
neither on the message delivery latency, nor on the probability that a service residing at some
host becomes temporarily unreachable due to network congestion.
Application level protocol tailored for Web transactional applications, which attempts
to reduce the impact of network congestion on the latency experienced by the endusers. The
intuition underlying this proposal is to exploit the intrinsic potential of parallelism commonly
exhibited by Application Service Provider (ASP) infrastructures, where the application access
point is replicated over a large number of geographically distributed edge servers. At this
purpose,we allow privileged classes of users to concurrently contact multiple, replicated
access points so to increase the probability to timely reach at least one of them and to
promptly activate the application business logic for the interaction with a back-end database
system. We complete our proposal with an efficient mechanism that prevents multiple,
undesired updates on the back-end database and, at the same time, strongly limits the
additional load on the ASP infrastructure due to the increased amount of requests from the
privileged users.

INTRODUCTION
The Web has undergone a deep and rapid evolution such that, nowadays, browsers are no
longer a tool used just to display and navigate contents.They have become the access point to
transactional applications, such as on-line stock/equity trading, banking or auctions, for
which the level of service perceived by the endusers is an issue even more critical than in
classical content delivery. Specifically, for some of those applications, reduced
responsiveness or service unreachability may translate in loss of revenue and/or customer
loyalty, and may possibly give rise to legal implications.

BACKGROUND

The need for QoS specifications in Web services is driven by two demands. Clients aim to
experience a good service performance, e.g. low waiting time, high reliability, and
availability to successfully use the service whenever the need arises. On the other hand, when
it comes to e-business, service providers need to formulate QoS-aware offers in order to gain
the highest possible profit from their business. Examples are high throughput
guarantees and low response time through dynamic capacity allocation, resource allocation,
and load balancing in order to serve a high number of clients with assured QoS. Moreover,
crucial transactions such as payment should experience prioritized execution realized by
transaction differentiation. Service providers will strive to find an optimal relation between
user satisfaction and system utilization.

MOTIVATION

Addressing the problem of improving the user perceived QoS in transactional applications
over the Web is more complex than the case of content delivery for several reasons.One of
them is the end-user behavior. Specifically, in case of content delivery applications, low
system responsiveness might induce the end-user to simply resubmit its request, possibly to a
different edge server. This cannot be straightforwardly admitted in case of Web transactional
applications since it might result in duplicate execution of a transaction at the origin server.

In well known protocols for Web cache sharing,such as the Internet Cache Protocol (ICP,
whereeach edge server is allowed to multi-cast query messages to other servers to discover
whether they can promptly provide a valid copy of the content requested by the end-user. In
case of a transactional application, a multi-cast based approach to increase the likelihood of
promptly reaching the transactional logic residing at some, among multiple, edge servers
cannot be used without introducing additional mechanisms to avoid multiple updates of the
database at the origin server.

SCOPE:

In this paper we address the problem of how to exploit replication of the edge servers, each
one offering access to the transactional logic, to achieve higher levels of responsiveness,while
ensuring that the transaction associated with each end-user request is committed exactly one
time at the origin server. More precisely, we present a protocol that allows privileged classes
of users, i.e. those users for which we want to improve the perceived QoS, to concurrently
contactmultiple edge serves in order to activate the transactional logic they host. This allows
increasing the probability that at least one of those edge servers is promptly reached to
absence of congestion or overload on that network path.
LITERATURE REVIEW

Existing works on the simulation of web QoS provisioning abound, a review of few of these
follows:A Parallel Invocation Protocol for Transactional Applications over the Web was
designed which exploits the path-diversity along the end-to-end interaction toward the origin
sites by concurrently routing transactional requests toward multiple-edge servers. Request
processing is finally carried out by a single-edge server, adaptively selected as the most
responsive one depending on current system conditions.Romano,P,Qualia,F;Ciciani,B were
propose a simple and lightweight parallel invocation protocol for distributed transactions over
the Web, which addresses all issues such as (i) non-idempotent business logic and (ii)
increase of the workload on the data centers in a scalable manner by requiring no form of
coordination among (geographically spread) edge servers. Menasce and Bennani(2003)
reported a model that selfadjusts configuration parameters of a web server to meet QoS
requirements using C/C++ language. The model however, did not consider different classes
of requests.

ARCHITECTURE
Target System Architecture
As shown in Figure , the architecture of our target system consists of an origin Web server,
hosting a centralized database system, and of a set of geographically distributed edge servers,
connected to the origin server through a (virtual) private network, or even through the
Internet. Each edge server hosts the transactional business logic for the access to the database
on the origin server, and (possibly) performs some form of caching of the contents/query
results retrieved by the origin server. End-users access the transactional logic residing at
some edge server through a client(e.g. an applet running in a browser), which interacts with
the edge server side of the application via the Internet. The processing of the client request at
the edge server consists in the execution of a transaction on the centralized database system
residing at the origin server, and in the computation of a response to be delivered to the client
itself, which depends on the state of the database and on the transaction
outcome.
A relevant instance of such a system architecture is represented
by Application Delivery Networks (ADNs) For this type of architectures, the ASPs have the
possibility to ensure agreed levels of QoS only within the infrastructure they own and control,
typically formed by the edge servers, the (virtual) private network and the origin server.
However, as pointed out in the Introduction, the QoS perceived by end-users may be reduced
just due to the fact that the client side of the application interacts with the edge serverside
through the Internet, where load, and thus latency, are typically unpredictable. Improving the
end-user perceivedQoS by reducing the potential impact of overload on Internet
network paths is the objective of our proposal.

The Protocol
This section is devoted to the presentation of our protocol.For simplicity, we first
introduce and motivate the basic intuition underlying it. Next, we provide a detailed
description by discussing the behavior of the client, of the edge server and of the origin server
hosting the database. An infrastructure like the one described in Section 2 exhibits a large
potential of parallelism. Such an assertion is justified by simply considering that it may
replicate the access point to a given service over hundreds or thousands of geographically
distributed edge servers. the basic idea underlying our proposalconsists in allowing a client
belonging to a privileged class to submit a request concurrently to multiple (as an extreme all
the) edge servers in the proximity set. Since request messages targeted at different edge
servers are likely to be routed through different Internet network paths, the objective of
contacting multiple edge servers concurrently for a single request from a privileged client is
to increase the probability to reach at least one edge server without incurring a congested path
on the Internet, with clear benefits for the user perceived QoS in terms of system
responsiveness (e.g. prompt activation of the application business logic). this approach is
complemented by a simple and efficient mechanism ensuring that,independently of the
number of edge servers contacted by the client, the requested manipulation on the database
residing at the origin server takes place only once. More precisely, the fastest edge server that
starts the execution of the transaction on the database at the origin server (possibly due to the
fact that it is reached more quickly than the others by the client request), prevents all the other
edge servers from executing that same transaction. This is done only by exploiting standard
primary key constraints on the database at the origin server, thus no explicit coordination
among the edge servers contacted by the client is required. Overall, our solution allows the
end-to-end interaction to be completed by letting the client request be entirely processed only
by the edge server that (depending on the current state of Internet) is more responsive than all
the others that have been contacted. All the other edge servers stop processing that request
just after they have carried out very few work on it, thus producing minimal increase of the
computational load on the ASP infrastructure.
Client Behavior
The pseudo-code for the client behavior.
As the first step, the client computes a set of edge servers close to its location, namely the
proximity set.

determine the proximity set;

set a new request identifier id;
while (true) {
send Request[id,req] to each eadge server in the proximity set;
set Timeout;
wait until ( receive Response[id,res] or Timeout expires );
if (a Response message is received ) return res;
}
Figure: Client Behavior.
Then the client selects a value to be used as unique identifier for its request, namely id.
Afterwards, the client sends the request,together with its unique identifier, to all the edge
servers in the proximity set, and waits for the first reply from one of them. Upon the arrival of
the first reply, the client returns the transaction output to the end-user. In case
no reply gets in within a predefined timeout, the client simply re-sends the request to the edge
servers in the proximity set.
The client has the ability to compute a set of edge servers close to its location is actually very
practical in current conventional technology, especiallywhen considering that the client logic
may be implemented as an applet. In this case, viable alternatives exist to address this issue.
A first alternative would be to make the applet aware of those edge servers at download time.
Specifically, the set of close edge servers could be selected as a function of the location from
which the applet download is performed,thus it could be specified within the applet code so
to make it directly available to the client (1). Another alternative would be, for example, to
rely on recently proposed service discovery mechanisms (e.g. UDDI) specifically tailored
for the Web-Service architecture.
Similarly, the selection of a unique identifier could be implemented in a variety of
practical ways. The simplest approach is probably to let the edge server initialize the applet,
at download time, with an identifier UID uniquely associated with the applet itself (e.g. by
using the naming rules specified for OSI CCR atomic action identifiers[20]). Hence, the
applet could generate a unique identifier for the user request by simply attaching to its own
UID, a monotonically increasing sequence number.
Edge and Origin Server Behavior
Our protocol ensures that, independently of the number of edge servers concurrently
contacted by the client for accessing the transactional logic, the manipulation of the database
residing at the origin site takes place only once. This must be ensured since a client request
generates a transaction that cannot be assumed to be idempotent.
we propose a simple and efficient mechanism based on the idea of leaving a trace of
transaction execution, from now on TTE, within the database residing at the origin site. By
exploiting the TTE, we force a conflict among the transactions associated with the same
client request, activated by the multiple edge servers contacted by the client. Such a conflict
ensures that only one among those transactions is committed. To allow the use of our
protocol with off-the-shelf products, we propose to rely on standard integrity constraints
validation mechanisms, universally embedded in commercial databases. More precisely, the
information maintained by the TTE simply consists in the unique identifier associated with
the client request,which is treated as a primary key for the database at the origin site. Hence,
only one among the multiple transactions that attempt to record the TTE within the database
is a legal transaction. All the others are automatically aborted by the database server which is
able to notify the abort event to the edge server through a proper exception. All the edge
servers that receive the notification of the exception simply terminate the processing of the
request. On the other hand, the edge server executing the only legal transaction will take
care of completing the end-to-end interaction by reporting the result to the client.
we provide the pseudo-code for the edge server behavior (single threaded for simplicity
of presentation).

wait receive Request[id,req] from client {

start a transaction;
try { insert (id); }
catch (DuplicatePrimaryKeyException) {terminate;}
res=process(req);
commit the transaction;
send Response[id,res] to client;
}
Upon the receipt of a client request, the edge server starts a new transaction on the
database at the origin site. As the first action within this transaction (i.e. before actually
executing the application business logic) the edge server performs an insert operation of the
request unique identifier id (i.e. attempts to write the TTE) within a user level table upon
which a primary key constraint on the request identifier itself is defined. If a
DuplicatePrimaryKeyException is raised, the edge server simply terminates processing the
client request since we know some different edge server must have already started the
transaction associated with that same client request. On the other hand, if the insertion of the
request identifier succeeds, the edge server knows it is the first one attempting the insertion,
thus it knows it is the most responsive in satisfying the end-user submitting the request.
The situation is slightly different in case of optimistic concurrency control. Specifically,
this type of concurrency control does not block concurrent transactions conflicting on the
same data; it ensures serializability by only validating the transactions at some point of their
execution. In case transaction validation is done at commit time, the employment of our
protocol exhibits the risk of an increase in the real computational load on the database system
since concurrent transactions associated with the same client request might be entirely
executed before we detect a conflict on the access to the TTE tuple. A simple work-around to
this problem is to exploit the well-known technique of earlyvalidation of transactions,
actually supported by many off the- shelf databases, which consists in checking the validityof
the transaction after the execution of each single operation,and not only at commit time.
This protocol might cause unbounded growth of the database table maintaining the TTEs.
However, in practice we can prevent this problem, e.g. by associating with each TTE a Time-
To-Leave (TTL) after which deletion from the database table can be performed. This might
be performed by an apposite garbage collection process residing at the origin server, which
periodically executes SQL queries on the TTE table to remove information that has expired.
Issues on Fault Tolerance Capabilities
A typical problem for transactional applications is the so called “loss of the outcome” [8].
This problem arises in case of crash of the instance of the edge server process after the
commit of the transaction at the origin server but before the client is notified of the
transaction outcome. In this case, the wisest choice for the final user would be executing the
appropriate operations to determine whether the database was actually updated, but this is not
always possible, or easy, or desirable.
In this context, the idea of leaving a trace of transaction execution underlying our protocol
may actually be exploited to address the loss of the outcome problem in a simple and efficient
way. To achieve this goal, it is sufficient to extend the TTE information so to include,together
with the request identifier, also the result message to be delivered to the client. With this
solution, fail-over of the edge server can be implemented by simply relying on a timeout
based retransmission logic of the client request. This is because, independently of the number
of re-transmissions, no more than one transaction is eventually committed at the back-end
database thanks to the treatment of the request identifier within the TTE as a primary key. At
the same time, in case a primary key violation is detected by an edge server processing an
instance of the request re-transmitted by the client upon timeout, this implies that the request
has already been processed but the client was not timely notified about the outcome, possibly
because of crash of the edge server originally taking care of transaction processing.In this
case the edge server notified of the primary key violation can simply retrieve from the TTE
table the transaction outcome and return it to the client itself. Overall,TTE including both the
request identifier, treated as a primary key, and the transaction outcome allows solving the
loss of the outcome problem without the need for using redirection mechanisms within a
clustered environment for the edge servers or transactional queues plus distributed
coordination.

ANALYSIS

Analysis of this protocol is done by considering two scenarios.Thefirst one (Scenario-A) is

representative of a baseline protocol,according to which the client contacts a single edge
server and then waits for the outcome of the transaction from this server. In this case no TTE
insertion is performed by the edge server since no trace of transaction execution must be left
within the database to prevent multiple commits for transactions associated with a same client
request. In the second scenario (Scenario-B), the client employs our protocol by contacting
in parallel two different edge severs, and then waiting for the reply from the most responsive
one.
There is a delay in the communication between client and edge servers, and between
edge servers and the origin server hosting the database. We denote as RTTc/es and
RTTes/os the round trip times between client and edge server, and between edge server and
origin server,respectively. The value of RTTes/os has been fixed at 100 msecs, reflecting the
fact that the ASP infrastructure typically offers guarantees on the communication latency
between an edge server and the origin server. Instead, a different approach has been adopted
for the case of RTTc/es, since this parameter is representative of the communication latency
between the client and the edge server via public networks over the Internet, which might be
unpredictably influenced by possible overload or congestion. We have modeled RTTc/es by
means of two distributions capturing, respectively, normal and congested network situations.
These distributions are as follows:
Normal Situation:
RTTc/es follows an exponential distribution with a minimum value of 100 msecs and mean
value equal to 250 msecs. The chosen values appear reasonable when considering historical
studies of RTT over the Internet.
Congested Situation:
RTTc/es follows a heavy tail distribution, i.e. a Pareto, ranging from 1000 msecs, and with
2500 msecs as the mean value, i.e. an order of magnitude greater than for normal behavior.
We denote as Pcongestion the probability to incur network congestion (i.e. the
probability that RTTc/es follows the Pareto distribution). Pcongestion is treated as an
independent parameter in our study, so to capture a wide range of environmental contexts.

Figure :Comparison of UserPerceived Response Times in Scenario-A and Scenario-B

while Varying Pcongestion (Light System Load).

To evaluate the performance benefits from the proposed protocol, we initially studied
the case of light system load(i.e. client requests submitted one at a time). In this study, whose
results are reported in Figure , we varied Pcongestion in the range [0.0-0.1] and measured a
set of performance parameters providing indications not only on the average values of the
user perceived (end-to-end) response time, namely E[resp time] in Figure but also on the
degradation of the system responsiveness perceived by those users who experience a response
time greater than E[resp time].At this purpose we chose to evaluate, for both Scenario-A
and Scenario-B, the mean value of the response time on all the samples which resulted
greater than the overall average response time, we denote this parameter as
E[resp time|resp time > E[resp time]],

and also the additional delay percentage (ADP), defined as

which is an indicator of the additional delay experienced by the client in case the system
performs worse than the average.As an example, ADP=50% means that the end-to-end
latency perceived by “unlucky” clients (i.e. clients experiencing response time above the
average) is fifty percent worse than the average response time.The measures reported in
Figure show the effectiveness of this proposal in improving the user perceived QoS,
especially in the presence of network congestions.Specifically, in case of non-minimal
congestion probability(i.e. Pcongestion=0.1) the average end-to-end latency in Scenario-B
is about a half than in Scenario-A (517,95msecs in Scenario-B vs 1006.00 msecs in
Scenario-A),whereas the ADP is +384,49% in Scenario-A and only +53,71% in Scenario-B.
The advantages of simultaneously contacting a pair of edge servers remain remarkable even
for lower values of Pcongestion (i.e. Pcongestion=0.01) and are still meaningful also in
absence of congestion (i.e.for Pcongestion=0), where the average response time in
Scenario-B is about 14% less than in Scenario-A.

CONCLUSION
In this paper,an application level protocol for improving user perceived responsiveness of
Webvbased transactional applications is presented. Specifically,the problem of how to exploit
replicated access points to the transactional logic to achieve higher levels of
responsiveness,while ensuring that the transaction associated with each end-user request is
committed exactly one time at the origin server is addressed.The underlying idea is to allow
privileged classes of users to simultaneously contact multiple edge serves, thus increasing the
probability to reach at least one of those servers quickly due to absence of congestion or
overload on that network path. At the same time, we rely on the universally supported
primary key constraint mechanisms to avoid multiple updates on the database at the origin
server. We complete our proposal by introducing a technique to limit the impact of multiple
client request transmissions on the consumption of resources at the origin server,i.e. the
natural bottleneck of the considered system architecture.Roughly speaking, this protocol is
designed such in a way that only the quickest instance, among the repliecated client requests,
is allowed to be entirely processed.
REFERENCES
References
[1] http://www.akamai.com
[2] W. Almesberger, T. Ferrari and J.Y. Le Boudec, “Scalable Resource
Reservation for the Internet (work in progress)”, Internet Draft,
1997.
[3] Y. Bernet, P. Ford, R. Yavatkar, F. Baker, L. Zhang, M. Speer, R.
Braden, B. Davie, J. Wroclawski and E. Felstaine, “A Framework
for Integrated Services Operation over Diffserv Networks”, RFC
1998, November 2000.
[4] P. Bernstein, M. Hsu and B.Mann, “Implementing Recoverable Requests
Using Queues”, Proc. ACM Int. Conference on Management
of Data (SIGMOD), 1990.
[5] R. Braden, D. Clark and S. Shenker, “Integrated Services in the Internet
Architecture: an Overview”, IETF RFC 1633, June 1994.
[6] http://www.digisle.com
[7] S. Frolund and R Guerraoui, “Implementing e-Transactions with
Asynchronous Replication”, IEEE Trans. on Parallel and Distributed
Systems, vol.12, no.2, 2001.
[8] S. Frolund and R Guerraoui, “e-Transactions: End-to-End Reliability
for Three-Tier Architectures”, IEEE Trans. on Software Engineering,
vol.28, no.4, 2002.
[9] D. Grossman, “New Terminology and Clarifications for Diffserv”,
IETF RFC 3260, April 2002.
[10] “Internet Traffic Report”,
http://www.internettrafficreport.com
[11] K. Johnson, J. Carr, M. Day, and M. Kaashoek, “The Measured
Performance of Content Distribution Networks”, Proc. of Int. Web
Caching and Content Delivery Workshop, May 2000.