<%BANNER%>

Ubiquitous web caching

University of Florida Institutional Repository
, for tables,

and so forth. Tools like Xpath could be used to locate these tags, then insert them in

between the pair of . Certainly, a unique ID, such as foox in

Figure 5-4, should be assigned to the segment for later use.

For each segment, the initial priority value could be assigned in two ways, which

are similar to the above fragmentation methods. If the authors fragment the page

manually, they could also assign the priority values at the same time. In this way, authors

can show their intentions and have some controls on their pages. Otherwise, an

automated program could traverse the whole page and assign value "9" to all the

segments as a default value.

There are 10 priority values that range from 0 to 9 and those values are significant

only within the same page. That means the segment priorities from different Web pages

are not comparable. For each page, the value 9 indicates the highest priority whereas 0

means the lowest. Having been assigned the initial value, the priority will be changed









periodically, based on the number of accesses to a segment collected from client agents.

Figure 5-5 shows the algorithm. Basically, upon each click, two counters are

# Nc: total number of clicks; increment upon each click
# Ns: total number of segments of a page
# t: a function to calculate a specific threshold with parameters
# Pi: priority value for segment i
# Ti: the time stamp to generate the Pi
# Tnow: the current time
# Ci: total number of clicks on segment i
# Ci': total number of clicks on segment i sent from client agent

# executed on each access
for each segment i
{
Ci Ci + Ci';
Nc Nc + Ci';
}

# executed periodically
for each segment i
{
# priority value increment
if ( Ci > t (Ci,Pi,Nc,Ns) and Pi < 9 )
{
Pi Pi + 1;
Ti (- Tnow;
}
# priority value decrement
# expired means the segment hasn not been touched for a period
else if ( Ti expired and Pi > 0 )
{
Pi Pi -1;
Ti (- Tnow;
}


Figure 5-5. Page Segment Priority Value Decision Algorithm.


incremented. One counter keeps track of the number of clicks on the segment. Another is

a page counter which counts how many clicks on that page. There is a back end program









monitoring the segment counter. If its value is greater than a threshold, the segment

priority will be incremented, and the timestamp for the segment is set as the current time.

The threshold is calculated based on the current value of segment priority, the number of

accesses on the segment and the page, and the number of segments of the page. Now we

need to determine how to increment the counters. If a client agent makes the request to a

page, the number of clicks for each segment will be piggybacked, and the total

corresponding numbers would be updated accordingly on the server. The number of

clicks could be 0, 1, or more. The first two values are obvious. But it could be more than

1 because the browser cache or the proxy server can satisfy the request so there is no

packet sent to origin server. Whenever the page on the caches is out of date and the new

page is downloaded, the counts are piggybacked and reset as 0 locally.

Along with each request from the user agent, there is an agent priority value. It is

used to reflect the user's preference, namely, what percent of the whole page would

prefer to downloading. If the value is 0, the complete original page would be sent out. If

the value is 9, only the smallest portion with priority value 9 would be transferred.

Generally, if the value is r, where 0<= r <=9, all the segments with priority value p (p>=r)

would be sent out. The agent priority is calculated on the client side.

Client side. For each downloaded Web page, the client agent is responsible for

counting the number of accesses to each segment, namely, the agent maintains a tuple

for each segment in a page where Cj,i is the number of

clicks for the segment. The algorithm, which is illustrated in Figure 5-6, consists of two

parts. The first part increments two counters by 1 upon each user's click. The counters

are the number of clicks on the specific segment and the number of clicks on the page. If









# Nj,c: total number of clicks on a page; increment upon each click
# Nj,s: total number of segments of a page
# Np: total number of pages
# t: a function to calculate a specific threshold with parameters
# Pj,i: priority value for segment i
# Pj,c: priority value for a page
# Tj,c: the time stamp to generate the Pj,c
# Vk: the total number of pages having priority k, where 0<=k<=9
# Pa: priority value for a client agent
# Ta: the time stamp to generate Pa
# Cj,i: total number of clicks on segment i, page j.

# upon each click
if (new page)
Np < Np +1;
Initialize new (Cj,i)s to 0;
Initialize new Pj,c to 0;
Cj,i < Cj,i + 1;
Nj,c Nj,c + 1;

# at the idle time
for each page j
Pj,c' Pj,c;
# change priority of page
for each segment i
if( Cj,i > t(Nj,c,Nj,s) and Pj,c > Pj,i)
Pj,c (- Pj,i;
Tj,c (- Tnow;
else if( Tj,c expired)
if(Pj,c<9)
Pj,c Pj,c + 1;
Tj,c (- Tnow;
# change priority of agent
if( Pj,c <> Pj,c')
k Pj,c';
Vk Vk -1;
k Pj,c;
Vk (-Vk +1;
if (Vk > t(Np) and Pa > k)
Pa k;
Ta (- Tnow;
else if (Ta expires and Pa < 9)
Pa Pa + 1;
Ta (- Tnow;

Figure 5-6. Client Agent Priority Value Decision Algorithm









it is a new page, the previous two counters need to be initialized to Os and the page

counter is incremented by 1. Based on these data, the client agent changes its request

priority value, which is set to 0 at installation time, namely, to download the whole page

at the beginning. The second part of the algorithm could be running at the agent idle time

without interfering with the user's operation. We first calculate the page priority values

which are the preparation for the calculation on the agent priority. This is based on the

statistic values of segment clicks. If one segment priority is greater than a threshold,

which is evaluated on the total number of clicks and the total number of segments, we say

that segment priority is dominant. So if the page priority is less than the segment priority,

we assign the segment priority value to page priority. For example, if the number of

clicks on a segment with priority value 6 is greater than the half number of all clicks, we

would let page priority value equal to 6. A good function to calculate the threshold value

should not return many dominant segments. On the other hand, if the page priority has

not been changed for some time, it is decremented by 1. Then by collecting the page

priority values of all the visited pages, the priority value of the agent can be determined.

There are 10 variables, VO,V1,...through V9, which keep track of the number of pages

with priority 0,1...9. If the page priority changes, the old Vk is decremented by 1 and the

new Vk is incremented by 1. If a Vk is dominant again, the agent priority is changed to

this value k. Generally, two rules are applied for both page and agent priority decisions:

* If the number of accesses to a segment/page is greater than a threshold, the current
value is decremented.

* If a priority value has not been changed for a long time, the priority value is
incremented.









Therefore, it takes awhile for this algorithm to converge. But it eliminates the ping-

pong effects that priority values change quickly when the system just starts and the

number of clicks is low.

Data structure of priority assignment algorithm

We use a heap as the data structure for our Priority Assignment Algorithm. The

reason to choose it is because its storage size is small and the operations on it are fast and

efficient, which are important for small devices.

A heap is a special kind of rooted tree that can be implemented efficiently in an

array without any explicit pointers where each node in the tree corresponds to an element

of the array. It has two properties:

1. Complete binary tree

2. Heap order

A Complete Binary Tree is a binary tree that is completely filled on all levels with a

possible exception where the lowest level is filled from left to right. The heap order

property is more important for us. For every node v, other than the root, the key stored in

v is greater or equal (smaller or equal) than the key stored in the parent of v. A heap is a

max heap when the relation between every node v (other than the root) and its parent is

the "smaller relation" (v <= parent(v)). The maximum value is stored in the root.

The corresponding array for the heap is shown in Figure 5-7. The heap can be

created and maintained very efficiently. It can be constructed in linear time. And when a

portion of the Web page encounters lots of clicks, its priority may rise or vice versa. The

time complexity is O(logn) in order to maintain the heap order. Inserting a new fraction

follows a path from a leaf to the root of the tree. The tree height is O(log n) yielding

running time of O(log n). To determine which portions of the page to send back, the









program simply locates those elements by the indices i, 2i, and 2i+1 recursively, which is

based on the breadth-first traverse where i is the parent node and 2i and 2i+1 are its

children[BRA96].



1


2 3



45 6 7



a 7s 9
2 4 1


1 2 3 4 5 6 7 8 9 10

16 14 10 8 7 9 3 2 4 1

Array A
Figure 5-7. The heap data structure for priority selection algorithm


In our case, there exists another string field in each array element which stores a

path from the root element to the corresponding section. Then the section can be easily

located by XPath. The primary purpose of XPath is to address parts of an XML

document. In support of this primary purpose, it also provides basic facilities for

manipulation of strings, numbers, and booleans. The XPath uses a compact, non-XML

syntax to facilitate use of XPath within URIs and XML attribute values. XPath gets its

name from its use of a path notation as in URLs for navigating through the hierarchical

structure of an XML document. Given the example in Figure 5-4, we have the XPath:









/PFML/BODY/Priority[@name='foo_2]

to locate the self-introduction part of the page. These paths can serve as the pointers and

be stored in the Array A in Figure 5-7.

Web Caching in Partiality Adaptation

Web caching plays a big role in our partiality adaptation. Priority tags allow

different devices to share the same copy of an XHTML file which is usually stored in the

caching server. A mobile device can take advantage of the copy of a Web page

previously downloaded by some other devices, for example, a desktop, in a caching

hierarchy. Instead of going all the way to the far end of the Internet, the client with less

capabilities can obtain a subset of the page by extracting the content marked with higher

priorities. On the other hand, a device with more capabilities can use the partial copy of a

Web page, which was downloaded previously by a smaller device, and send it to the user

directly. This can shorten the response time. The remaining objects could be downloaded

simultaneously and integrated with the previous part at last. Therefore, letting the mobile

device users and traditional desktop users share the same Web page potentially increases

the chance of a Web cache hit rate, reduces Internet traffic, and lowers the response time

to clients.

Experimental Evaluation

We conducted a series of experiments on the client and proxy sides. On the client

side, we used three types of wireless devices. The first device is a J2ME-enabled

Motorola i85 cellular phone. Nextel service was subscribed, which provided a 19.2 kbps

transfer rate. We consider this as a low-end device in terms of network performance,

CPU power, and display size. The second device is an IBM 390 Thinkpad which uses a

802.11b compatible wireless card to connect to the access point in our lab. The









connection rate was at 11 Mbps. This is considered to be a high-end device. The third

device is an iPAQ 3800 PDA and uses the same network adaptor and network connection

as the laptop but with less computation power and memory. We have also programmed a

proxy server and let it run on a Sun Ultra 60 workstation. The proxy code includes

several modules as a normal proxy server does: a server side module responsible for

setting up a connection with the Web server; a client side module in charge of the

communication with clients; a cache management module; and a PFML parser. The two

Web servers we used were Google.com and CNN.com. The index page of CNN.com is

about 50k and frequently updated. On the other hand, the index page of google.com is

less than 3k and rarely changed.






Laptop compute Internet

Web Server

PDA Proxy Server

Cell phone

Figure 5-8. Experimental environment on partiality adaptation.

We designed three cases, as Figure 5-8 shows, to download a portion of the Web

page to the client which is about 1k size.

1. Remote Case: We download the page from the origin site. The client sends out a
request to our proxy server, then the proxy relays the request to the origin site.
Having received the whole page from the Web, the proxy extracts the first 1k data
and forwards the data to the client.










2. Extracted Case: We put the pages of the Web sites onto the proxy server's local
disk, and inserted some pairs of tags into the origin
pages. Upon the user's request, the parts marked with are
extracted and sent back to the client.

3. Cached Case: We put an extracted copy of the Web site on the proxy, which is
about 1k. When the user's request came, the copy was sent out immediately.

For each of these three cases, we conducted the experiment 12 times at different

time periods of each day. For example, the first experiment was done at 8 a.m. on

Monday morning; the second was at 12 a.m. on Tuesday morning, the third was at 4 a.m.

on Wednesday morning, and so forth. The intervals between two experiments are 16

hours. By doing the experiments at different times on different days, we could get a fair

measurement on traffic of both the Internet and wireless links.

Figure 5-9 shows the raw data of running three-case requests from a cellular phone

to download a suitable copy of the CNN index page. Since there is a significant timing

difference between downloading the largest and smallest datum, we use the logarithmic

scale to illustrate the results. In Figure 5-9(a), each bar shows the complete round-trip

time starting from sending out the first byte of request and ending at receiving the last

100000 Remote
Fragment
10000 -ECached

E 1000



E, 10
'I-





0
-1 2 3 4 5 6 7 8 9 10 11 12
the nth test


(a)


Figure 5-9 is continued on the next page










Remote
100000 Fragment
100 C ached
10000

S1000
u' 0 100
.y .e
10 0
| AAA A A- --
2 1
1 2 3 4 5 6 7 8 9 10 11 12
the nth test


(b)

Figure 5-9. Raw data collected on a 12-day trace. (a) represents the RTT measured on
cellular phone. (b) RTT measured on proxy

byte of the page. In Figure 5-9(b), each node shows the round-trip time beginning at the

proxy receiving the request and finishing when the proxy received and/or processed the

page. We give an overall glance at the data in Table 5-1. The average values are

calculated from all 12 runs. We use the same method to collect other data for PDAs and

laptops.

Table 5-1. Example Data on a 12-day Trace of a Cellular Phone
Case 1 Case 2 Case 3

Phone Proxy Phone Proxy Phone Proxy

Minimum 4910 475 3810 12 3639 3

Maximum 42214 31613 37846 14 36048 4

Average 18824 7568 10033 13 10380 4




Then the method is applied to download the index page of Google. In Figure 5-10,

we show only the average value of different category data. Figure 5-10(a) illustrates the

total time measured between the user's sending out the request and receiving the desired









page. The performances of cached and extracted cases are very similar, whereas the

remote case has one order of magnitude of larger retrieving time. For example, the

average times to download a CNN page to laptop on the three cases are 8258ms, 764ms,

and 756ms. This is mainly because in Case 1 a significant amount of time was spent in

between the proxy and origin server to download pages. To further explain this, Figure 5-

10(b) measured the time which started from getting the user's request and ended at

finishing sending back the copy on the proxy. It illustrates that when the proxy relays the

client request to the origin site, it takes a big amount of time, which is about 7568ms. On

the other hand, if a copy is already cached by the proxy, it takes the least amount of time

on the proxy. The time to parse a PFML page and extract some portions of it varies on

the size of the origin page. It takes about 13ms to process a 50k page and about 4ms to

process a 3k page. It needs about 3ms to send back the ready copy. Figure 5-10(c) deals

mainly with the time spent on the client side, including the time that a client sets up a

connection with the proxy and the time that the client processes the downloaded page.

The wireless links consume significant amounts of time to download pages. They are

10376ms and 8535ms for CNN and Google pages, respectively.

According to the experimental result in regard to the CNN page, the average time

to process a cache hit is about 3ms; to fragment a 50k CNN.com home page is about

15ms; and to download it from the Web on the wired network is approximately 7500ms.

For a smaller page like Google's homepage, which is about 3k, the three values are 3ms,

4ms, and 500ms. The shorter downloading time (500ms) is due to its relatively long

expiration time so that pages can be downloaded from nearby caching proxy servers. In

our program, we force the agent to download the pages without accepting the






71


intermediary copies. But some interception proxy servers are deployed on the Internet so

it is still possible to get a page from proxy, especially for static pages like Google.com.

Figure 5-10 shows a much longer round-trip time to download a page onto a cellular


0610

0Q,
2


'\,


(a) Comparison of total time to download pages to the devices


\OO0

\OO0

\OO


N0


I. .. .o. .o .. .


\e 0 e -*-Remote
o0 0 oo -- Extracted
S--Cached


(b) Comparison of the time spent on the proxy server

Figure 5-10 Simulation results on PFML.
















S\ Remote
S-g--Extracted
'E --Cached

60 09





(c) Comparison of the time spent by the clients

Figure 5-10 Continued.



phone with wireless links. The time spent on wireless links is dominant. So the extracted

and cached time are very similar because the proxy processing time is negligible

compared to the time consumed by the wireless links. But on the other hand, we still see

about 8000ms saved on the extracted and cached cases than downloading from the

original remote site to fetch a 50k CNN.com index page. We see 1500ms saved on

fetching a 3k Google.com index page.

This experiment shows that by allowing different devices to share a cached object

with Priority tags, it saves about 8 seconds in the best case scenario, for example, to fetch

a 50k Web object from the origin site. It also shows that when the wireless network, for

example a Wi-Fi network, transfer rate is comparable with that of the wired lines, the

saved amount of time is significant. In our Google case, it saves 496ms. On the other

hand, when the wireless link transfer rate is at least one order of magnitude lower than

that of the wired line and the size of the Web object is small, for instance 3k, the saved






73


time is less significant compared to the delivering time on the current telecommunication

network. But according to the experiment, it still saved about 1.5 seconds out of 10

seconds total delivering time. Therefore, to draw a more accurate conclusion on the

performance of a priority tag on the slow wireless networks, we measured the delivering

time on the cellular phone by sending out requests to 100 popular Web sites.


20000
18000
16000
14000
12000
10000
8000
6000
4000
2000
0


0 5000 10000 15000 20000

Page Size (bytes)


25000 30000


Figure 5-11 Simulation data on 100 Web sites retrieved by cellular phone.


The sites were collected from www.hotl00.com with more than 10 categories. The

sites are generated using Overture's search rankings for the query contained in the

category. The 10 categories that we chose are listed in Table 5-2.

We used both Remote and Extracted Cases. With remote simulation, the pages

were downloaded to the cell phone from the origin site. The downloading time is shown

by the blue square in Figure 5-11. But this time, in our client code, the intermediary

copies are allowed to fetch. Since the selected Web sites are very popular, pages are most









likely to be downloaded from a proxy server close to client agents. Therefore, this is the

best scenario for the Remote case, namely, users can always download a page very fast.

In comparison, we stored pages on our Unix machine, and when users' requests come in,

the pages are simply read through once and sent back to the phone directly. We did not

extract any contents because we want to deliver the same sizes of the pages, otherwise the

saved transferring time on a wireless network will dominate the overall amount of saved

time. The Extracted Case measurement is shown with pink diamond dots in Figure 5-11.

The average size of downloaded page is 4843 bytes. The average downloading time is

6875ms in remote simulation, whereas it is 5910ms in extracted simulation.

Table 5-2. Distribution on 100 Web Sites.
Categories # of sites

Art&Culture/Books 10

Business/Finance 10

Education/College 9

Gaming/Gambling 8

Entertainment/Music 11

Home/Cooking 10

Lifestyles/Cars 10

News/Newspapers, Magazines 10

Shopping/Electronics 10

Technology/Internet 12









Therefore, by allowing users to share the cached objects among heterogeneous devices

with Priority tags, we are able to save 965ms to download an average-sized Web page.

The performance is improved at least 14%.

Several points need to be taken into account. First, the workload on the proxy is

rather low, which may lead to less processing time of page extraction. Second, the proxy

server is supposed to be put at the spot where the backbone of the Internet and the

cellular network are connected. But in our simulation it was not deployed this way. Third,

most programs were coded in Java language except the one on PDA, which is in C#. But

in [GRI02], C# and Java are proven to be very close in TCP socket performance.














CHAPTER 6
VERSIONING NEGOTIATION

Partiality adaptation mainly concentrates on the XHTML index pages whereas

versioning negotiation is designed to select the right object version efficiently. After the

first round-trip communication between client and server, the objects embedded in the

XHTML page are decided. Then it is time to deliver the appropriate version of each

object.

Content negotiation requires a variant list for every object. The process on a server

needs to select the best representation for a given request when multiple representations

are available, for example, an HTML version or a WML version. The variant lists are

usually stored on the Web server. Whether or not to send out the list and where to send

the list depends on the negotiation mechanism. In our approach, we use fidelity tags to

conduct versioning negotiation. Lists are embedded in an index page and sent out to user

agents.

Design of Fidelity Tags

Fidelity tags convey object variant messages to clients directly and precisely. This

enables users to make their own decision in the first place. Different fidelity descriptions

include different attributes of content objects. For example, a text object has the attributes

such as language and charset, and image attributes include size and resolution. With the

help of fidelity tags, a user agent can easily understand how many different presentations

are associated with one embedded object and their characteristics. A clear decision can

therefore be made directly by an end-user.









Variants of objects and their attributes can be inserted as lists into an XHTML page

where the original Web objects were embedded. The lists are quoted by Fidelity tags.

Choice tags specify each one of the versions of an object and its attributes. All tags are

defined in PFML DTD in Chapter 5. Figure 6-1 shows two types of objects and three

associated variants. The first object is an image file associated with three presentations.

The image in GIF format has the best quality and biggest size. (The quality values are

evaluated by the Web author and we adopt them from [RFC96].) It is the best format for

desktops and laptops. To target PDAs, pictures in Portable Network Graphics (PNG)

format are the best choices because they have a little lower resolution and relatively

smaller size. For pager and cellular phone users, a plaintext can be displayed instead of

the image. In the second example, the document in English and in postscript format is the

best version. The English version in plain text is a worse one. And the French plaintext is

the worst copy in terms of quality. The variant selection can be done on a user agent by

matching device information with the object's attributes because the agent has the

complete knowledge of the user's hardware and software platforms.

Versioning Selection Algorithm

Versioning selection needs two steps. First, several suitable versions can be chosen

according to object's attributes and device capabilities. In regard to images, an user agent

can choose all those with width and length smaller than or equal to some predefined

values. If they happen to be the same, the quality value of the object is not changed,

otherwise, the quality value would be decreased. If the browser agent is aware of the

existence of proxy servers somewhere in between the origin server and itself, the version

with bigger width and height can be chosen because the proxy can do the transcoding on

the fly, but the quality value also needs to be decreased accordingly.















Foo's Home





I am ...











foo











"application/postscript" language= "en" >







Figure 6-1. An Example of using PFML with both Fidelity and Priority tags. (The
attribute values of the above examples are adopted from [RFC96] with some
modification.)









In the second step, the Remote Variant Selection Algorithm (RVSA) [HOL98a]

could be used with the modified quality values. The overall quality Q of a variant is the

value

Q = round( qs qt qc ql qf)

where round is a function which rounds a floating point value to 5 decimal places after

the point, and where the factors qs, qt, qc, ql, and qf are determined as follows.

* qs Is the source quality factor in the variant description.

* qt The media type quality factor is 1 if there is no type attribute in the variant
description, or if there is no Accept header in the request. Otherwise, it is the
quality assigned by the Accept header to the media type in the type attribute. Note:
If a type is matched by none of the elements of an Accept header, the Accept header
assigns the quality factor 0 to that type.

* qc The charset quality factor is 1 if there is no charset attribute in the variant
description, or if there is no Accept-Charset header in the request. Otherwise, the
charset quality factor is the quality assigned by the Accept-Charset header to the
charset in the charset attribute.

* ql The language quality factor is 1 if there is no language attribute in the variant
description, or if there is no Accept-Language header in the request. Otherwise, the
language quality factor is the highest quality factor assigned by the Accept-
Language header to any one of the languages listed in the language attribute.

* qf The features quality factor is 1 if there is no features attribute in the variant
description, or if there is no Accept-Features header in the request. Otherwise, it is
the quality degradation factor for the features attribute, see section 6.4 of [2].

As an example, if a variant list contains the variant description

{"paper.html.en" 0.7 {type text/html} {language fr}}

and if the request contains the Accept headers

Accept: text/html:q=1.0, */*:q=0.8

Accept-Language: en;q=1.0, fr;q=0.5

the remote variant selection algorithm will compute an overall quality for the variant as


follows:









{"paper.html.fr" 0.7 {type text/html} {language fr}}

round (0.7 1.0 0.5) =0.35000

With the above Accept headers, the complete variant list

{"paper.html.en" 0.9 {type text/html} {language en}},

{"paper.html.fr" 0.7 {type text/html} {language fr}},

{"paper.ps.en" 1.0 {type application/postscript} {language en} }

would yield the following computations:

round( qs *qt *qc *ql *qf ) = Q

paper.html.en: 0.9 1.0 1.0 1.0 1.0 = 0.90000

paper.html.fr: 0.7 1.0 1.0 0.5 1.0 = 0.35000

paper.ps.en: 1.0 0.8* 1.0* 1.0* 1.0 =0.80000

In fact, this algorithm is more suitable for our versioning negotiation because the

metadata in RVSA are used to describe Web objects but not the device information. With

the object description and the on-hand device information, a client agent could therefore

make a good choice.

Advantages of Versioning Negotiation

First, compared to agent driven negotiation, our approach saves one round-trip

time. In the agent driven negotiation, when the user sends out a request, the server sends

back the list of variants. Based on the list, the user agent chooses the right version

according to its device information and sends over the decided choice of the object. Then

the server delivers the requested version of the object. In versioning negotiation, the

variant lists come with the XHTML index page so the user agent chooses the best version

without requesting the variant list. This saves one round-trip time.









Second, on the server driven negotiation, it is the origin site server who makes the

decision on which copy to send out. This has several disadvantages. First, the decision is

based on the resource description information like CC/PP sent from a user agent or some

third-party Web site which is the repository of device information. In our approach, the

decision is made by a user agent. It saves bandwidth because a CC/PP file is usually very

large which contains comprehensive metadata to describe properties of hardware and

software. Second, it is not secured to disclose the user's information such as the OS

version by sending out device information online. Third, in regard to Web caching, the

server-driven adaptation is not always a good negotiation solution because it bypasses the

caching server. Fourth, the transparent negotiation also has some drawbacks. It is

designed to save bandwidth and take advantage of a caching server. But to decide an

optimized version, it requires not only cached Web objects but also client profiles and

object variant and attribute information. This would result in a significant modification of

the current Web caching functionalities on the proxy server that are widely deployed. In

the versioning negotiation, since the decision is made by a user agent and device

information is always complete, a request always includes an explicit URL. Therefore, a

Web caching server can simply return the requested page as it does now. The only

difference is that XHTML pages have more annotation information for embedded objects

than current ones.

Web Caching on Versioning Negotiation

Our approach improves the performance of content negotiation by fully taking

advantage of the current Web caching mechanism. With Fidelity tags, the requested

XHTML pages are embedded with object variant lists. Then the user agent makes the

decision on fetching which object. Thus there is no more round-trip between client and









server and no extra trip to fetch the device description. Since every version of Web

objects are associated with a URL, an explicit request can come from a user agent as

usual. So the browser cache, proxy cache, surrogate cache, and even origin server all

behave like what they are doing now.

Simulations and Analysis on Versioning Negotiation

In this section, we conducted two simulations on both content negotiation with

CC/PP and our versioning negotiation. We showed the experimental result that

versioning negotiation outperformed the content negotiation with CC/PP.

The simulation environment was set up as Figure 6-2 shows. The Web server is

Apache. It hosts more than 1000 personal Web sites of CISE Department students and

professors at the University of Florida so we are able to test the simulation with some real

workload. Two CGI modules were put onto the server programmed with Perl. One is for

CC/PP and the other is for versioning negotiation. The CC/PP module receives the users'

requests, retrieves the device information from a third-party site, matches different

versions with device descriptions, and sends back the selected version to the client. We

call our versioning negotiation module PAVN. It behaves like a normal Web server

which simply returns pages. The matching process between devices and objects happens

on the client side in PAVN. We used a Motorola i95 cellular phone as a client and

programmed with J2ME and MIDP 1.0. Elapsed time is measured on the cellular phone

and displayed on the phone screen. The downloaded pages and objects are not displayed

because for both methods it takes the same amount of time for the two methods to render.

The phone has 1.5M RAM, 160*120 screen, 8 bits color depth [MOT02]. The CPU speed

is not disclosed by Motorola, but it is estimated to be around 100MHz [PHO03].



















i95cl Nextd Toer
NEdcel TcCff


Figure 6-2. Simulation environment to compare performance on CC/PP and PAVN
negotiation modules


The simulation results are illustrated as a bar graph in Figure 6-3. The vertical axis

indicates the round-trip time to fetch the Web objects. The horizontal axis shows the sizes

of the downloaded objects. The plus sign on the object size means two objects were

downloaded; for example, lk+256 indicates that two objects were downloaded. It means

the size of the index page is 1k, and the size of the embedded object is 256 bytes. Each

bar shows the average time of 15 runs.

The Versioning Negotiation outperformed CC/PP in all 9 cases where both the

CC/PP and PAVN algorithm are executed. The average saved time is about 870

milliseconds. To further explore the amount of the saved time, we analyzed the

performance on the two server side modules carefully.

The two CGI modules are very short. The PAVN CGI simply gets the request,

opens the corresponding file, and sends it back. The CCPP CGI uses the Library for

WWW in Perl (LWP) to fetch the device CC/PP file, then gets the image format

information, for example, the width, height and the resolution, and finally opens the

requested file and returns it.










12000
U PAVN
10000 CCPP

e 8000

6000

4000

2000





Object Size (bytes)


Figure 6-3. Simulation results on CC/PP and Versioning Negotiation


We used the UNIX time command as a benchmark to measure the two programmed

modules. Figure 6-4 shows the details returned by the time command. For the CCPP

module, the majority of the extra time was spent on retrieving the CC/PP file from the

Internet. The user process consumes 0.78 second, the system calls on network takes 0.11

second, including file opening and network connection setting up, and the total elapsed

time is 1.35 seconds. Therefore, it takes about a half second to fetch the CC/PP file from

the Internet by subtracting the first two numbers from the last one. Regarding the PAVN

module, the total elapsed time is 0.34 second, the user process takes 0.28 second, and the

system time consumes about 0.02 second on file operation. We therefore saved about 1

second on the server side by using PAVN instead of the CC/PP module.

In our novel implementation, several issues are not considered. First, the CC/PP file

is fetched from the proxy server which certainly saved a lot of time. Second, in the real












PAVN
U LIS*-l




CCPP



0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6
time (seconds)


Figure 6-4. Time measured on the server side


implementation of CC/PP, there are always some delta data sent to the Web server from

the client as complementary information, for example, the upgraded operating system

version or the size of the memory sticks which was just inserted into the expanded slots.

The extra information will also cost some extra time for the CC/PP module. Third, we

used an average size of CC/PP files, which is 4.24k bytes because we could not find out a

standard CC/PP file for the Motorola i95cl phone [W3C01].

The processing time of the Versioning Selection Algorithm (VSA) on both server

and phone is insignificant compared with the object delivering time spent on the wireless

and wired networks. With a lack of benchmark tools on cellular phones, we could not

find out the accurate time spent on the phone client as we did on the UNIX server. But

we got several timestamps while our application was running. It takes only 25ms to parse

the fidelities of one object as Figure 6-1 shows. But we use only this datum as a reference

since it is measured inside the program and thus not accurate.

It is interesting to note is that there is a significant delay on setting up a connection

on a wireless network. The experiments show three cases to download 512k Web objects:









256+256, 512, and 512+0. In PAVN, to download 512 bytes with one round-trip

consumes 5398ms. But the others take 6959 and 6677ms separately. It is similar to the

CCPP method. Therefore, it would be more efficient to download everything necessary at

once on the current wireless network, which is similar to the WAP solution. But pushing

Web contents is a preemptive solution which is opposite to our pulling method in

versioning negotiation.

Finally, we can see the trend of computing power of small devices and their

connected wireless links will be developed extremely fast in the near future. The saved

time by deploying PFML will be more significant. Moreover, we do not need different

solutions to different devices. The ubiquitous Web will finally appear on all devices.














CHAPTER 7
CONCLUSION AND FUTURE WORK

Summary

This dissertation presents a study of Web caching in the domain of pervasive

computing. We ubiquitously deliver Web contents to mobile users with heterogeneous

devices.

We first pointed out the challenges. In the upcoming world of pervasive computing,

users access information sources in the World Wide Web by a huge variety of mobile

devices featuring heterogeneous capabilities, for example, with respect to display, data

input, computing capacity, and so forth. These mobile devices coexist with fixed

workstations resulting in an even broader diversity of device characteristics and

capabilities. The miscellaneous devices are attached to the Internet by a variety of

communication systems, such as cellular radio networks, local area wireless networks,

dial-up connections, or broadband connections. The various communication systems

offer different functionality and heterogeneous characteristics, for example, bandwidth,

delay, and so forth [BUS03].

We presented an approach that joins the concepts of Web caching and XML in a

uniform scheme so whichever the devices are being used and wherever the location is, a

user can always get the same appearance of the Web contents within the same amount of

response time.

Generally, we classify Web contents into two categories: the personal profile such

as the user's bookmarks, contact information, and the public Web contents such as









HTML pages, text files, image files, and so forth. We further make two subcategories on

the public Web contents which are XHTML index pages and the contents with specific

file formats, such as .txt, .jpg files. We solved the problems of each category separately

and integrated them together.

The Internet Caching Protocol was extended and named as x-ICP. It targeted

delivering a personal profile and shortening response time for mobile users. When a user

changes the point of attachment on the network, x-ICP transparently connects the Foreign

Proxy with the Home Proxy and gets the personal profile ready. The x-ICP can also help

users to fetch Web objects from the Home Proxy to reduce the response time and the

overall traffic on the Internet. According to the experiments, if the user moves around on

an intranet--the Foreign Proxy and Home Proxy are connected by the same backbone--the

response time can be 1.22 times faster with x-ICP deployed than without it. The

experiments also showed that with the constraint of the current Internet performance,

users would not be able to benefit from cached copies on the Home Proxy unless their

distance to the Home Proxy is no more than 201 miles.

We proposed a new XML language called PFML to solve the delivering problem of

public objects. The PFML consists of two tags: priority and fidelity. Priority tags are used

by partiality adaptation to transport an XHTML page. Basically, a generic page for all

devices in all network circumstances is generated by the Web author. But the different

parts of the page are marked by the priority tags to indicate their importance compared

with other sections. Therefore, users are able to download Web pages according to their

preferences, device capabilities, and network conditions. All these can be done

automatically by our Client and Server Priority Selection algorithms. Our experiment









showed, with the help of priority tags and caching servers, a cellular phone can save

about 1 second to download a Web page compared to downloading a normal HTML

page.

Fidelity tags are designed for versioning negotiation. It allows the user agent to

determine which objects to fetch if multiple versions exist. The variant lists of objects are

embedded into the index page and delivered to the user agent in the first place. Then our

Versioning Negotiation Algorithm is running on the mobile device to choose the best

version. Our experiment showed that the computation time on the small devices was not

significant compared to the network transportation time. The current CC/PP solution

takes 0.8 more second to deliver a Web object than our versioning negotiation method.

The amount of time saved by our algorithms will be more significant when the

transfer rates of wireless networks are faster. The Universal Mobile Telecommunications

System (UMTS) will provide up to 10M bps by the end of 2005 [ARC03]. Furthermore,

there will be about 135,000 hot spots in service to cellular/VoIP Wi-Fi integrated phones

in 2006 [COM03], which rate is at least 11 Mbps.

Future Work

We hope in the future that all Web pages are embedded with PFML tags, and x-ICP

is deployed everywhere so the ubiquitous Web contents can be presented, network traffic

can be reduced, and user response time can be shortened.

The most important experiment needed to done is to model the mobile user's

behavior, for example, what kind of Foreign Proxies they tend to use, how far they are

from the Home Proxy, how long is the linger time, which devices are being used while

moving, what is the speed of movement, and so forth. Unfortunately, the log files of the





PAGE 1

UBIQUITOUS WEB CACHING By WENZHENG GU A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLOR IDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY UNIVERSITY OF FLORIDA 2003

PAGE 2

Copyright 2004 by Wenzheng Gu

PAGE 3

To my parents, Mingchu and Ruilian, and my lovely wife Xiaoli.

PAGE 4

ACKNOWLEDGMENTS First and foremost, my deepest appreciation goes to Dr. Sumi Helal, chairman of my committee. Dr. Helal provided me with continuous and excellent guidance and mentoring throughout my academic years at the University of Florida. His strong support and efforts made my research work much easier. His motivation encouraged me to surmount many obstacles in the past four years. Also, I would like to express my gratitude to Drs. Michael P. Frank, Paul D. Gader, Joachim Hammer, and Allen D.George for serving on my supervisory committee and for their valuable comments and suggestions. Thanks Dr. Frank to spend extra time with me to improve my experiment performance. I would like to thank my lab mates who gave me constructive advice. Last, but not least, special thanks go to my parents who supported me to go abroad to continue my education and to my wife for her continuous support in my educational endeavors. iv

PAGE 5

TABLE OF CONTENTS page LIST OF TABLES............................................................................................................vii LIST OF FIGURES.........................................................................................................viii ABSTRACT.........................................................................................................................x CHAPTER 1 INTRODUCTION........................................................................................................1 Motivation................................................................................................................1 Overview..................................................................................................................6 Design Philosophy, Objective, and Contribution....................................................9 Organization of This Dissertation..........................................................................10 2 RELATED RESEARCH WORK...............................................................................11 Mobile IP...............................................................................................................11 Three Hierarchies of Web Caching........................................................................13 Service Discovery..................................................................................................16 Content Adaptation and Negotiation.....................................................................19 Device Description..................................................................................19 Content Adaptation.................................................................................20 Content Negotiation................................................................................21 Web Page Partition.................................................................................23 3 ARCHITECTURE OF EXTENDED INTERNET CACHING PROTOCOL............24 Overview of X-ICP Architecture...........................................................................24 Mobile IP versus X-ICP.........................................................................................29 Design Details of X-ICP........................................................................................29 X-ICP Modules..............................................................................................29 Processing Procedures of X-ICP ...................................................................32 Proxy service discovery...........................................................32 Sibling proxy configuration and registration...........................33 General Web object delivery...................................................37 Profile update and cache duplication.......................................38 v

PAGE 6

4 SIMULATION AND ANALYSIS ON X-ICP...........................................................39 Trace Collection and Characteristics.....................................................................39 Simulation Methodology.......................................................................................40 Analysis..................................................................................................................45 5 PARTIALITY ADAPTATION..................................................................................52 Overview of Partiality Adaptation and Fidelity Negotiation.................................52 Partiality Adaptation Design Details.....................................................................56 Design of Priority Tag..................................................................................56 Automated Assignment Algorithm of Priority Values.................................58 Priority assignment algorithm..................................................58 Data structure of priority assignment algorithm......................64 Web Caching in Partiality Adaptation...................................................................66 Experimental Evaluation........................................................................................66 6 VERSIONING NEGOTIATION................................................................................76 Design of Fidelity Tag...........................................................................................76 Versioning Selection Algorithm............................................................................77 Advantages of Versioning Negotiation..................................................................80 Web Caching on Versioning Negotiation..............................................................81 Simulations and Analysis on Versioning Negotiation...........................................82 7 CONCLUSION AND FUTURE WORK...................................................................87 Summary................................................................................................................87 Future Work...........................................................................................................89 LIST OF REFERENCES...................................................................................................91 BIOGRAPHICAL SKETCH.............................................................................................96 vi

PAGE 7

LIST OF TABLES Table page 3-1. Comparison between Mobile IP and X-ICP..............................................................28 4-1. Objects Distribution per Day on the Different CISE Sub-networks.........................39 4-2. Variables Used in Analysis........................................................................................46 5-1. Example Data on 12-day Trace of Cellular Phone....................................................69 5-2 Distribution on 100 Web Sites...................................................................................74 vii

PAGE 8

LIST OF FIGURES Figure page 1-1. Mark Weisers vision on ubiquitous computing..........................................................1 1-2. Trends on global wireless and Internet growth............................................................3 1-3. General architecture for ubiquitous Web caching........................................................5 2-1. IP in IP encapsulation in Mobile IP............................................................................13 2-2. A two-layer caching hierarchy...................................................................................14 2-3. The hierarchy of Internet Caching Protocol (ICP).....................................................15 2-4. SLP agents and their transactions for service discovery and registration..................17 2-5. Overview of content negotiation solutions.................................................................22 3-1. Overview of x-ICP architecture..................................................................................25 3-2. Applying x-ICP to Mobile IPs triangle routing.........................................................27 3-3. Modules on proxy server with x-ICP being deployed................................................30 3-4. Data structures on the Node Monitor.........................................................................31 3-5. An example of a nomadic node M moves from Net1 to Net2...................................34 4-1. Home Proxy and Foreign Proxy hit rates...................................................................43 4-2. The percentage of bandwidth used to download objects from the nearby Home Proxy........................................................................................................................45 4-3. As x-ICP is being deployed, the downloading speedup can be considered as a function of inter-proxy round-trip time....................................................................47 4-4. Round-trip delays tested on campus network.............................................................49 4-5. The impact of RTT values on speedup.......................................................................50 4-6. The impact of the cache hit rate of the Home Proxy on speedup...............................50 viii

PAGE 9

5-1. Hierarchy of PFML elements...................................................................................54 5-2. The Document Type Definition of PFML..................................................................55 5-3. Processing on partiality adaptation and versioning negotiation.................................56 5-4. Foos homepage implemented with HTML(a) and PFML(b)....................................58 5-5. Page Segment Priority Value Decision Algorithm.....................................................60 5-6. Client Agent Priority Value Decision Algorithm.......................................................62 5-7. The heap data structure for priority selection algorithm............................................65 5-8. Experimental environment on partiality adaptation...................................................67 5-9. Raw data collected on a 12-day trace. (a) represents the RTT measured on cellular phone. (b) RTT measured on proxy.........................................................................69 5-10 Simulation results on PFML.....................................................................................72 5-11 Simulation data on 100 Web sites retrieved by cellular phone.................................73 6-1. An Example of using PFML with both Fidelity and Priority tags..............................78 6-2. Simulation environment to compare performance on CC/PP and PAVN negotiation modules....................................................................................................................83 6-3. Simulation results on CC/PP and Versioning Negotiation.........................................84 6-4. Time measured on the server side..............................................................................85 ix

PAGE 10

Abstract of Dissertation Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy UBIQUITOUS WEB CACHING By Wenzheng Gu December 2003 Chair: Abdelsalam (Sumi) Helal Major Department: Computer and Information Science and Engineering Internet access by mobile users, who roam on a mobile network with exotic electronic devices, presents a scenario of browsing that is substantially different from the wired network. When users, with current Web technology, change devices or the point of attachment to the network, a different Internet appears, for example, personal profiles like bookmarks and shopping carts for ecommerce sites are lost. Furthermore, the response time is longer, the heterogeneity of mobile devices is conflict with the wide variety of Web contents, and the user intent is not automated. In this dissertation, we explore two ways to deal with above challenges. First, the current Web caching mechanism is applied to wireless networks. We designed a mobile Web caching protocol -the Extended Internet Caching Protocol (x-ICP). It is deployed at the edge of the Internet to deliver Web contents from a nearby Home Proxy server if there is no performance degradation compared to fetch them from the origin sites. The x-ICP is also responsible for giving users a consistent look on their personalized Web pages. Second, we applied several content services to the cached objects. Three adaptive x

PAGE 11

mechanisms are designed to cope with device heterogeneity and Web content variety. We first created the adaptive Web contents, where the Partiality and Fidelity Markup Language (PFML) is used to embed metadata into Web pages. Based on this information, the Partiality Adaptation and Versioning Negotiation (PAVN) approaches are used to adapt cached Web contents to different devices in the first place. We also designed client and server side adaptive algorithm to let users express their intents automatically and invisibly. xi

PAGE 12

CHAPTER 1 INTRODUCTION Motivation The most profound technologies are those that disappear. They weave themselves into the fabric of everyday life until they are indistinguishable [WEI91]. This is the paraphrased statement made by Mark Weiser in 1991. And it is the first vision of pervasive/ubiquitous computing. As Figure 1-1 shows, people were expecting the same convenience and computing power in the mobile device as the computer which sits on the desk. Figure 1-1. Mark Weisers vision on ubiquitous computing. 1

PAGE 13

2 Today, people use a wide range of devices, including desktops, laptops, handheld personal digital assistants (PDAs), and smart phones that are connected to the Internet, and use all kinds of networks, such as wireless LAN(802.11b/a), cell phone network (GPRS), broadband network (DSL), and telephone network (56k modem). Two profound technologies allow users to move around with computing power and network resources at hand: portable computers and wireless communications. Moreover, two trends can be seen standing out in networking and communication as Figure 1-2 illustrates. (1) The World Wide Web can be considered as a large distributed information system that provides access to shared data objects and continues to grow exponentially. (2) The proliferation of the wireless Internet and telephone devices creates ever greater demands on the networks of wireless carriers and service providers. Therefore, we would expect that the combination of these two growing technology trends--Internet access on the one hand and wireless access on the other-would result in a potent combination. The wireless Web will enable a plethora of new applications, especially for users on the move. Much research has been done on the challenges to this new computing paradigm [DUC92, FOR94, IMI94, MUK94, SAT95]. From our point of view, the challenges are classified into three categories. The first category includes many wireless network issues, for example, the frequent disconnection or handoff, the low bandwidth, the heterogeneous networks, the point of attachment (surrogate), and address migration. Work on ubiquitous computing is still in an early phase. Most work now concentrates on the mobile infrastructure for wireless networking. Because ubiquitous computing envisions hundreds of wireless computers in every office, its need for wireless bandwidth

PAGE 14

3 is prodigious. Regarding handling mobility, networking developed over the past 20 years with the assumption that a machine's name and its network address were unvarying. However, once a computer can move from network to network this assumption is false. Figure 1-2. Trends on global wireless and Internet growth. Existing protocols such as TCP/IP and OSI are unprepared to handle machine mobility without change. Researchers are now working on methods of augmenting or replacing existing protocols to handle mobility [WEI93]. Therefore, mobility opens up new venues for interesting and unique contents and services only possible in a mobile environment. The second category is related to devices: power management, risks to data, different sizes of user interface, and storage capacity. Consequently, new hardware and software techniques must be developed. For example, applications need to be highly optimized for space in order to fit in the limited memory on the mobile devices. For

PAGE 15

4 Internet enabled devices, the reliable TCP/IP stack cannot be widely used; it takes too much space and is not optimized for minimal power consumption. The third category is even more challenging than the previous two due to the following four situations: (1) User intent, which is the key to determine whether the system can help or hinder the user. (2) Context awareness, which enables the system to better understand the location dependent information. (3) Adaptation, which is necessary when there is a significant mismatch between the supply and demand of a resource. (4) Security, which is always a big issue on the network. In summary, the performance of data delivery over different wireless networks is unacceptably low today. Most Internet applications, especially Web access, require efficient data transport. The degraded performance strongly discourages widespread use of wireless access networks since the resulting price/performance ratio becomes too large compared to alternative wired access technologies [BAL98]. One of the reasons of this performance degradation is that the current network protocols do not support mobile users. For example, Web caching is widely used on the wired Internet so that a copy of Web object can be returned from a proxy server usually closer to the user agent than the origin server. But there is no mobile Web caching protocol. When a user leaves home network, he is disconnected from the caching server where many previously downloaded objects are stored. Therefore the performance is degraded. Another reason is that the small palmtop devices are not able to handle all kinds of Web contents, such as Java applets, animation graphics, and so forth. So it takes longer time to do further adaptation on the content for mobile devices.

PAGE 16

5 In this dissertation, we explore two ways to deal with those challenges as Figure 1-3 illustrates. We first designed a mobile Web caching protocol -the Extended Internet Caching Protocol (x-ICP). The x-ICP is deploy ed at the edge of the Internet to deliver Web contents from a nearby Home Proxy server if there is no perf ormance degradation compared to fetch them from the origin site s. The x-ICP is also responsible for giving users a consistent look on their personalized Web pages. Moreover, we designed several adaptive mechanisms to cope with device heterogeneity and Web content variety. We first created the adaptive Web contents. The Partiality and Fidel ity Markup Language (PFML) is used to embed metadata into Web pages. Based on this information, the Partiality Adaptation and Versioning Nego tiation (PAVN) approaches convert cached Web contents to different devices in the first place. We also designed client and server side adaptive algorithm to let users express their intents automatically. Figure 1-3. General architectur e for ubiquitous Web caching

PAGE 17

6 Overview Web Caching with X-ICP We consider Web caching as an important portion of our solution because not only Web caching is an efficient approach that has been widely used to improve current overall Internet performance but also based on the cached Web contents, more services can be easily provided, for example, image transformation, language translation, virus scanning, and so forth. Web caching is the temporary storage of Web objects for later retrieval. The majority of cache systems are proxy caches, which are widely deployed at the department and institute level of Local Area Networks (LANs) to benefit a group of people with the same browsing interests. There are many significant advantages on Web caching, especially for proxy caching: Web caching reduced bandwidth consumption because fewer requests and responses are needed to go over the network. Web caching reduced latency since responses for cached requests are available immediately and are closer to the client being served [DAV01]. Web caching increased availability by duplicating Web objects on the Internet. Web caching is transparently deployable and generally applicable. Transparent deployment means that the solution must not require changes to the current implementations on the client or the server. Generally applicable means, in the face of the phenomenal growth of both Web contents and mobile devices, the solution should be scalable and general enough to apply to all mobile scenarios. These advantages make the Web less expensive and better performing. In this dissertation, we first propose an Extended Internet Caching Protocol (x-ICP). It is based on traditional Web caching, but allows the proxy server on the nomadic users newly visited network to retrieve the user profile and Web objects from the proxy

PAGE 18

7 server of the users home network. Such a scheme gives users a consistent look at Web pages in the context of changing locations or changing devices, and decreases the response time for the requests by fetching an object from a usually nearby home network rather than from the origin site. To evaluate the performance of x-ICP, we use trace-based analysis and analytic modeling methods. We draw several conclusions, all suggesting that x-ICP would be an effective approach to solve the problems when nomadic users access the Web in a heterogeneous environment, especially in wireless LAN environments. In the context of content service, Web caching also plays an important role because on the edge of the Internet, many content servers are deployed. They are either surrogates which are near the original servers, or proxies which are close to user agents. On those servers, many cached objects are considered as a content layer. On top of the content layer is a service layer which provides services such as translation, transcoding, or virus scanning. Our Partiality Adaptation and Versioning Negotiation (PAVN) is one of the services. Taking advantage of the cached objects can make adaptation and negotiation more efficient. For example, our adaptation allows more users, or precisely speaking, more devices, to share the same copy of an object. This would result in a larger community with common interests. Therefore there would be a very good hit rate, and in turn save a lot of bandwidth and response time. Content Service Due to mobile device proliferation, content providers can no longer deliver only one version of their content to the users, as they need to deliver an appropriate form of content depending on the capabilities of the viewing devices. Web authors either create multiple versions of the same content for each device or depend on some intermediaries to do the transformation. Providing a suitable content and presentation for different client

PAGE 19

8 devices in heterogeneous environments is becoming an important service today. But simply adding another service layer onto the cached content layer will not work. This will make the overloaded Internet even worse. For example, to display a low resolution picture on a cell phone, simply downloading a very high resolution one and converting it on the proxy close to the cell phone would waste a lot of bandwidth between proxy and origin servers. Another example is when a PDA user is on the move, he may not want to read the same size of the CNN page as when he is sitting in front of a desktop at home. It is not therefore necessary to deliver a complete CNN page to a PDA user. Content adaptation and negotiation are two major approaches to delivering a suitable version of Web objects to mobile devices. Content adaptation usually refers to those transcoding and distillation methods processed on a proxy near the mobile users based on their profiles and network Quality of Service (QoS). Content negotiation, on the other hand, is a process between the client agent and the content server. The latter stores several variants of an object under different identifications (URL). After negotiation, an appropriate version is identified and delivered to the user. We modified the two previous approaches and combined them to achieve efficient content delivery to mobile clients. We propose two new approaches to the adaptive mobile content delivery. The first approach, called Partiality Adaptation, allows Web authors to create one version of an XHTML page whose various parts could fit various devices. The second approach, called Versioning Negotiation, improves the efficiency of content negotiation by eliminating the problems from the current negotiation algorithms based on HTTP. Current negotiation methods determine which version of the object to send out by the servers. It requires either partial information from an HTTP header or a

PAGE 20

9 device description file from a third party site. The metadata in an HTTP header would not lead to an accurate decision to fetch device description file introduces more network traffic and delay. On the contrary, we embed enough object information into an XHTML page and let the user agent make the final decision on fetching which object version. To further explore user intent and context awareness, it is also necessary to deploy new algorithms on both client and server sides. Our automated Priority Selection Algorithms are able to deliver suitable content to different types of devices without both client and servers intervention. Moreover, they can further reduce Web page response time and overall Internet bandwidth usage. Several evaluations on performance are presented by conducting experiments on laptop, PDA, and smart phone clients on the wireless links. All of them show a better performance than their current counterpart solutions. Design Philosophy, Objective, and Contribution Our design objective is to meet the emerging demands for ubiquitous access to the Internet with growing diversity of client devices. The complete design is based on the philosophy the simpler, the better. With the protocols and algorithms designed in this dissertation, we aimed at achieving the following goals: Make personal profiles follow the mobile users movement so the users can consistently access the Internet with their bookmarks, cookies, and so forth. Reduce the response time for mobile device users by fetching cached objects from the proxy server on the home network instead of going all the way to the far end of the Internet. Bridge the gap between the different variants associated with the same object, namely one copy for devices with different capabilities. For example, by merging both WAP and HTML pages to one, we save the time to generate different pages

PAGE 21

10 on the origin server, and we lower the burden on the proxy to keep track of different versions of the same content. Position Web caching of objects in a better place for content negotiation and adaptation rather than delivering and transcoding cached copies on the fly. For instance, by sharing the same pages with different devices, the size of the user group will be increased, and therefore the cache hit rate would be higher, and the bandwidth usage and response time to users would be reduced. Make better negotiation and adaptation by requiring no client device information. The adaptation is based on an appropriate copy rather than a large file. This reduces the proxy workload and saves the bandwidth between the proxy and origin server. Reduce users intervention by using automated algorithms. We use programs to automatically select the size of a Web page and the numbers of embedded objects instead of asking users to click on the choices. Organization Of This Dissertation The organization of the subsequent chapters is as follows. In Chapter 2, we survey related work, which mainly includes topics on mobile IP, Web caching, content adaptation and negotiation. In Chapter 3, we present the architecture of x-ICP and explain design details. In Chapter 4, we analyze and conduct the experiments on the performance of x-ICP. In Chapter 5, we cover the design principles of PAVN, and we illustrate details on Partiality Adaptation and its corresponding experiment. In Chapter 6, we discuss Versioning Negotiation and concentrate on simulation which proves the performance improvement. In Chapter 7, we summarize and suggest future research.

PAGE 22

CHAPTER 2 RELATED RESEARCH WORK Mobile IP In mobile networking, computing activities are not disrupted when the user changes the computers point of attachment to the Internet. Instead, all the needed reconnection occurs automatically and noninteractively. Some technologies are emerging and getting attention. Mobile IP is one of the well-developed technologies. Under Mobile IP, users do not have to modify their IP stack configurations manually each time they move into a new network [CAM00, CELXX, PER98, PER98a, VAL99]. Mobile IP also has been put into the IPv6 suite as the next generation standard of the Internet. Part of our research is based on this protocol. Mobile IP has the following three main components: 1. Mobile Node 2. Home Agent 3. Foreign Agent The Mobile Node is a device such as a cell phone, personal digital assistant, or laptop whose software enables network roaming capabilities. The Home Agent is a router on the home network serving as the anchor point for communication with the Mobile Node. It tunnels packets from a device on the Internet, called a Correspondent Node, to the roaming Mobile Node. (A tunnel is established between the Home Agent and a reachable point for the Mobile Node in the foreign network.) 11

PAGE 23

12 The Foreign Agent is a router that may function as the point of attachment for the Mobile Node when it roams to a foreign network, delivering packets from the Home Agent to the Mobile Node. Moreover, the care-of address is the termination point of the tunnel toward the Mobile Node when it is on a foreign network. The Home Agent maintains an association between the home IP address of the Mobile Node and its care-of address, which is the current location of the Mobile Node on the foreign or visited network [CIS01]. The Mobile IP was designed to allow the Mobile Node to use two IP addresses: a fixed home address and a care-of address that changes at each new point of attachment. In the Mobile IP, the home address is static and is used, for instance, to identify TCP connections. The care-of address changes at each new point of attachment and can be thought of as the Mobile Nodes topologically significant address. It indicates the network number and thus identifies the Mobile Nodes point of attachment with respect to the network topology. The home address makes it appear that the Mobile Node is continually able to receive data on its home network, where Mobile IP requires the existence of a network node known as the Home Agent. Whenever the Mobile Node is not attached to its home network (and is therefore attached to what is termed the foreign network), the Home Agent gets all the packets destined for the Mobile Node and arranges to deliver them to the Mobile Nodes current point of attachment. Figure 2-1 indicates the routes of IP packets. Mobile IP is best understood as the cooperation of three separable mechanisms:

PAGE 24

13 Discovering the care-of address; Registering the care-of address; Tunneling to the care-of address. [PER98] Figure 2-1.In Mobile IP protocol, IP in IP encapsulation is implemented to forward packets from the Home Agent to the Foreign Agent. Three Hierarchy of Web Caching On the wired network, Web caching has been generally recognized as an effective approach to solve the long round-trip propagation delays brought by the growth of the Internet [BAR00, DAV99, WAN99]. This straightforward idea employs intermediate servers to act as proxies to temporarily store some Web objects and serve the nomadic users requests.

PAGE 25

14 On some networks, one caching server might not be enough because of the size of the network, performance, and availability requirements. Two or more caching servers in such a network can serve more users in th e expected response ti me and provide load balancing and fault tolerance. Several servers that work toge ther to provide efficient and reliable Web caching form a cache cluster. Figure 2-2 shows a logic diagram of a twolayer cache hierarchy. Currently, there are three main exis ting approaches on proxy Web caching, including broadcast probe, exemplified by Harvest and Squid, hash-partitioning of the object namespace among caches, such as C aching Array Protocol (CARP), and a directory service first proposed in Cachin g and Replication for Internet Service Performance (CRISP). Figure 2-2. A two-layer caching hierarchy.

PAGE 26

15 The Caching Array Protocol uses a deterministic request resolution path to quickly locate and route a request to the caching server that contains the requested object without querying between servers in the cache cluster [ZHO99]. The CARP does not duplicate cached objects in multiple servers and therefore saves caching space in the cluster or array, and it uses hash-based functions to reach this optimization. A CRISP cache consists of a set of caching servers (proxies), which directly field requests from clients/browsers, and a mapping service, which is responsible for maintaining the global directory of objects stored in the caching servers. On a local cache miss, each caching server queries the mapping service to determine if the object is resident elsewhere in the collective cache. If the mapping service reports a hit, then the object is fetched directly from the peer caching server. Caching servers keep the global directory current by reporting object fetches and evictions to the mapping service. Direct Retrievals Hits and Misses Resolved Parent Cache Hits Resolved Sibling Cache Local Cache User Intern et Figure 2-3. The hierarchy of Internet Caching Protocol (ICP).

PAGE 27

16 The Harvest research project on Internet caching at the University of Southern California developed ICP in 1996. The ICP is an Internet standard as set forth in Internet Engineering Task Force (IETF) Request for Comments RFC 2186 and RFC 2187. The ICP works in a straightforward way. It is a lightweight message format used for communicating among Web caches. The ICP is used to exchange hints about the existence of URLs in neighbor caches. Caches exchange ICP queries and replies to gather information for use in selecting the most appropriate location from which to retrieve an object. Figure 2-3 shows the hierarchy of ICP. The basic sequence of events in an ICP transaction is as follows: 1. Local cache receives an HTTP request from a cache client. 2. The local cache sends ICP queries. 3. The peer cache(s) receives the queries and sends ICP replies. 4. The local cache receives the ICP replies and decides where to forward the request. Service Discovery Service discovery protocols provide mechanisms for dynamically discovering available services in a network and for providing the necessary information to: Search and browse for services Choose the right service (with desired characteristics) Utilize the service Among the well-known contenders, Universal Plug and Play (www.upnp.org), Jini (www.jini.org), and Salutation (www.salutation.org) architectures are prominent, coming primarily from the industry. The Service Location Protocol (SLP) is a product of the Service Location Protocol Working Group (SVRLOC) of the Internet Engineering Task Force (IETF) [PER97, VEI97]. It is a protocol for automatic resource discovery on Internet Protocol-based

PAGE 28

17 networks. The SLP is a language independent protocol. Thus the protocol specification can be implemented in any language. The SLP bases its discovery mechanism on service attributes, which are essentially different ways of describing a service. It can cater to both hardware and software forms of services. The SLP infrastructure consists of three types of agents: User Agents Service Agents Directory Agents The User Agents acquire service handles for end-user applications that request the services. The Service Agents are responsible for advertis ing service handles to the Directory Agents thus making services avai lable to the User Agents. Figure 2-4 shows the interaction between these three agents. Service Agent Directory Agent User Agent S e r v i c e R e q u e s t S e r v i c e R e g i s t r a t i o n S e r v i c e A c k n o w l e d g e S e r v i c e R e p l yService Discovery Service Registration and Update Figure 2-4. SLP agents and their transacti ons for service discovery and registration. Jini is a service discovery architecture ba sed on Java. It is a distributed serviceoriented architecture developed by Sun Mi crosystems [REK99]. Jini services can represent hardware devices, software programs or a combination of the two. A collection

PAGE 29

18 of Jini services forms a Jini federation. Jini services coordinate with each other within the federation. The overall goal of Jini is to turn the network into a flexible, easily administered tool on which human and computational clients can find services in a flexible and robust fashion. Jini is designed to make the network a more dynamic entity that better reflects the dynamic nature of the work group by enabling the ability to add and delete services flexibly. The Universal Plug and Play (UPnP), pushed primarily by Microsoft, is an evolving architecture designed to extend the original Microsoft Plug and Play peripheral model to a highly dynamic world of many network devices supplied by many vendors [MIC00]. The UPnP works primarily at lower layer network protocol suites (that is, TCP/IP), implementing standards at this level. The UPnP attempts to ensure that all device manufacturers can quickly adhere to the proposed standard without major hassles. By providing a set of defined network protocols, the UPnP allows devices to build their own Application Programming Interfaces that implement these protocols in whatever language or platform they choose. The Salutation coordination framework seems to be a more rigorous and useful framework from a coordination perspective than either Jini or UPnP. It seems to have drawn more from research on intelligent agents than other frameworks mentioned here. Salutation trods a middle way between device autonomy and standardization. In Salutation, a device almost always talks directly to a Salutation Manager, which may be in the same device or located remotely. What we see is an ensemble of Salutation Managers (SLMs) that coordinate with one another. They act like agents that do everything on behalf of their clients. All registration is done with the local or nearest

PAGE 30

19 available SLM. The SLMs discover other nearby SLMs and exchange registration information, even with those on different transport media. Content Adaptation and Negotiation Regarding Web contents, Internet content publishers do not have many options for customizing the content. In some cases, the publishers manually generate secondary, text-only versions of Web pages that the users can select instead of the originals. This is known as content negotiation. Another mechanism is called content adaptation, transcoding, or distillation. Basically, this mechanism changes the content based on network QoS, device information, or user intention, and it usually happens on a proxy server. Both of these methods require more or less information about devices and contents. Device Description There are many ways to describe device capabilities, such as HTTP Request Header Fields, CC/PP, WAP UAPROF, SyncML [BUT01, LEM02]. Typically, CC/PP stands for Composite Capabilities/Preferences Profiles. It is a way to specify what exactly a user agent (Web browser) is capable of doing. The CC/PP describes and manages software and hardware profiles that include: information on the user agent's capabilities (physical and programmatic); the user's specified preferences within the user agent's set of options; and specific qualities about the user agent that can affect content processing and display, such as physical location. The CC/PP is designed to work with a wide variety of Web-enabled devices, from PDAs to desktop machines to laptops to WAP phones to phone browsers to Web television units to specialized browsers for users with disabilities. Proxies may also be used to provide markup

PAGE 31

20 transformation, transmission, or caching services for CC/PP-enabled clients and servers [CCP99]. All the methods have advantages and disadvantages. For example, the HTTP request headers are too simple to describe a mobile devices capabilities and users preference, whereas CC/PP is too complex. The WAP UAPROF is not compatible with HTTP. Content Adaptation With the help of device description, content adaptation is an approach being widely adopted to solve heterogeneous device problems. There are many publications on content adaptation. Smith et al. [SMI98] suggest manipulating Web contents in two dimensions: fidelity and modality. Knutsson et al. [KNU02] proposed an idea on server-directed transcoding which preserves HTTP end-to-end semantics. Chi et al. [CHI02]. gave a solution on image processing which can generate a higher resolution JPEG based on the previous low-resolution version. Shi et al. [SHI01] present a novel architecture to support caching of dynamic personalized content for mobile users. There are also other similar approaches, including AvantGo, Web Clipping, ASP+.NET, PHP HawHaw Library, and XHTM/CSS [BUT01]. Adaptation is most likely to be deployed on the Internet edge such as transcoding, translation, and so forth. The main drawback of this approach is that it breaks various end-to-end HTTP properties which applications rely on. For example, many wireless gateways can transcode the original HTML page to a WML page so it can be displayed on a WAP browser. But complicated Web pages can make the heuristic algorithm on the intermediary difficult to apply. Also, the transformation may be against the Web authors intention.

PAGE 32

21 Content Negotiation Another different approach is content negotiation. The HTTP allows Web site authors to put multiple versions (variants) of the same information under a single URL. Web servers can choose the best representation of a resource based on the browser-supplied preferences for media type, languages, character set, and encoding. To enable content negotiation, the variant list of the resource is usually kept as a file on the Web server for later use. The list can also be retrieved from the file and sent out in the HTTP alternates headers. Three types of content negotiation mechanisms exist: 1. Server-driven negotiation 2. Agent-driven negotiation 3. A combination known as transparent negotiation But none of these mechanisms gives a satisfying solution in terms of making decisions on the best copy. With server-driven negotiation, it is hard to determine the best version because servers usually do not have the complete users information. The major drawback of agent-driven negotiation is that it introduces one more round-trip time to fetch the variant list [HOL98a]. The transparent negotiation is clearly defined and described in [HOL98]. Regarding the optimal transparent content negotiation, the variant file can be kept on a Web caching server to help the intermediary make the final decision because it usually knows the user better than the origin server. Although this transparent negotiation takes advantage of the cached variant list, variant properties, and Web contents, the final decision is still made by the proxy server. It is similar to letting a waiter decide the complete order for a customer in a restaurant, instead of letting

PAGE 33

2 2 c u s t o m e r m a k e t h e d e c i s i o n h i m s e l f F i g u r e 2 5 i l l u s t r a t e s t h e s e t h r e e s c e n a r i o s p l u s t h e v e r s i o n i n g n e g o t i a t i o n F i g u r e 2 5 C o n t e n t n e g o t i a t i o n s o l u t i o n s ( R e g a r d i n g t h e l e f t t w o g r a p h s n e g o t i a t i o n d e c i s i o n s a r e m a d e o n s e r v e r s T h e r i g h t t w o g r a p h s s h o w t h a t c l i e n t s m a k e t h e n e g o t i a t i o n d e c i s i o n B u t t h e u p p e r r i g h t g r a p h t a k e s t h r e e r o u n d t r i p s w h e r e a s t h e b o t t o m r i g h t o n e t a k e s t w o O n t h e t o p t w o g r a p h s p a g e s a r e r e t u r n e d f r o m o r i g i n s e r v e r s w h e r e a s a t t h e b o t t o m t w o t h e c a c h i n g s e r v e r c a n s a t i s f y t h e r e q u e s t )

PAGE 34

2 3 A t l a s t t h e H T T P R e m o t e V a r i a n t S e l e c t i o n A l g o r i t h m ( R V S A ) i s a n i m p o r t a n t p a r t o f t h e t r a n s p a r e n t n e g o t i a t i o n [ H O L 9 8 a ] A n R V S A c a n b e u s e d b y a n H T T P s e r v e r t o c h o o s e t h e b e s t v a r i a n t o n b e h a l f o f a n e g o t i a t i n g u s e r a g e n t T h e u s e o f a r e m o t e a l g o r i t h m c a n s p e e d u p t h e t r a n s p a r e n t n e g o t i a t i o n p r o c e s s b y e l i m i n a t i n g a r e q u e s t r e s p o n s e r o u n d t r i p W e b P a g e P a r t i t i o n T o b r e a k a W e b p a g e ( a c o n t a i n e r p a g e a n d i t s e m b e d d e d l i n k s ) i n t o s e v e r a l f r a g m e n t s i s n o t a b r a n d n e w i d e a I t w a s f i r s t a p p l i e d t o t h o s e d y n a m i c g e n e r a t e d W e b o b j e c t s I n [ D O U 9 7 E S I X X ] t h e s t a t i c c o n t e n t s o f a W e b p a g e a r e c a c h e d s e p a r a t e l y f r o m t h e d y n a m i c p a r t s C h i e t a l [ C H I 0 2 a ] p r o p o s e d a n X M L b a s e d m e c h a n i s m t o v a l i d a t e d i f f e r e n t f r a g m e n t s o f a W e b p a g e i n o r d e r t o p r e s e r v e d a t a i n t e g r i t y

PAGE 35

CHAPTER 3 ARCHITECTURE OF EXTENDED INTERNET CACHING PROTOCOL Overview of X-ICP Architecture In a mobile network, the movement of nomadic users presents significant technical challenges to provide efficient access to the Internet. For a given individual nomadic user, his location will vary from time to time, and he usually has more than one device to access the Internet. Imagine these three scenarios: First, people today are using workstations in the office, PCs at home, laptops, PDAs, and cellular phones everywhere to surf online. The experience is bad when the device is changed or when the user uses a public device. Bookmarks, address books, cookies, and link histories are all gone. People have to synchronize their devices from time to time. Second, the Computer Engineering (CE) Department and the Health Department of a university are working together to use wireless sensors to help the elderly. Some CE students need to stay in the Health Department for some time to acquire health knowledge while doing wireless research. Third, the most common movement for a student can be considered as going between school and home. When a student goes back home and wants to do some homework, the best place to start is his department proxy server where huge amounts of related pages and documents are already visited and downloaded by the instructors and other students. But for nomadic users, the proxy caching servers do not work efficiently because the request is not necessarily en route from the Home Proxy server where many previously downloaded contents are stored. It is therefore imperative to take into account dynamic nomadic behavior in designing a Web caching system. 24

PAGE 36

25 In this chapter, we introduce a newly integrated caching model, Extended Internet Caching Protocol (x-ICP), to benefit nomadic users. The main functionality of x-ICP is to connect the Foreign Proxy with the Home Proxy. So when a user moves, the Foreign Proxy can fetch the users profile automatically. It also deals with the decreased cache hit rate on the Foreign Proxy server when a user attaches to a new network. The x-ICP is based on the Mobile IP protocol, which has been widely discussed as a network solution to mobility. But the design of Mobile IP makes the current caching system hard to adapt to nomadic users. The x-ICP provides an opportunity to combat this problem by allowing the proxy server of the nomadic users newly attached network (Foreign Proxy) to fetch a copy from a usually nearby Home Proxy server. Figure 3-1 depicts this idea. Figure 3-1. The x-ICP is deployed on the proxy servers belonging to the different networks. When PDAs or laptops are away from home, they can download copies of Web objects from the Home Proxy. Before we go any further, we need to ask a fundamental question. Why do we extend ICP in particular? Why not extend other inter-caching protocols, for example

PAGE 37

26 CARP or CRISP? This is because the latter two infrastructures require predefined domains. In CARP, there are a cluster of proxy servers. Each of them is in charge of a range of URLs which is determined by a harsh function. In CRISP, all the proxy servers belonging to the same domain need to register their cached objects with a center agent. But the uncertainty feature of nomadic users makes it hard to predict which proxy servers should be grouped together at the proxy setup time, and there is much overhead to add and remove a proxy into or from the domain. Therefore, using short ICP messages to exchange caching information between the Foreign Proxy and Home Proxy is an effective way. Another reason to extend ICP is because it is a lightweight protocol. The ICP message format consists of a 20-octet fixed header plus a variable sized payload. In current practice, it is implemented on top of UDP. An ICP query/reply exchange was designed to occur quickly, typically within a second or two. The x-ICP is based on Mobile IP. Although Mobile IP brings significant conveniences for nomadic users, there are still some unavoidable problems with it since it changed the underlying infrastructure of current application level protocols. One of problems is that the triangle routing of Mobile IP completely bypasses the Home Proxy server where many Web objects were cached during previous Web accesses. When a nomadic node moves to a new location, the user will send out an HTTP request, which is processed only by the Foreign Proxy. If there does not exist any cached copy locally, the request will be forwarded to the Web server at the far end of the Internet. But it is very likely a copy of the requested object is residing on the Home Proxy, which is usually nearby. The single-arrow line in Figure 3-2 shows the triangle routing of Mobile IP, and

PAGE 38

27 the solid double-arrow line indicates how we can take advantage of those copies closer to us. Certainly the proxy servers mentioned here are those very close to the users, such as the department proxy in a university. Compared to the higher level proxy in a caching hierarchy, these proxy servers store many objects concentrated on a relatively small browsing interest to cater to a small community. One of the functionalities of x-ICP is that the request will be forwarded to the Home Proxy server first, when a cache miss occurs on the Foreign Proxy. If it is still a miss, it then goes to the origin site. Mobile Client Foreign Network Internet Host Home Network Foreign Proxy Home Proxy x-ICP Figure 3-2. Applying x-ICP to Mobile IPs triangle routing. More improvements have been made on ICP toward x-ICP. For instance, current shared cache architectures face a dilemma. On the one hand, the hierarchies wish to group as many proxy servers among a large number of clients as possible to achieve the best hit rates. On the other hand, as more proxy servers are involved to service more

PAGE 39

28 Table 3-1. Comparison between Mobile IP and X-ICP Mobile IP X-ICP Discovery Home agents and foreign agents may advertise their availability on each link for which they provide service. A newly arrived nomadic node can send a solicitation on the link to learn if any prospective agents are present. Proxy server agents advertise their services on their own links. A newly arrived nomadic node can retrieve service information from either the Service Agents or Directory Agents by Service Location Protocol (SLP). Registration/ Configuration When the nomadic node is away from home, it registers its care-of address with its Home Agent either directly or through a Foreign Agent, which forwards the registration to the Home Agent. When the nomadic node arrives at the new location, the configuration file of the Foreign Proxy server is modified to group the Foreign Proxy server with its Home Proxy server. Furthermore, the Foreign Proxy would fetch the users profile if it is out of date. For each user, two lists are created to maintain the corresponding objects information. Delivery In order for datagrams to be delivered to the nomadic node when it is away from home, the Home Agent has to tunnel the datagrams to the care-of address. When a cache miss happens locally, the Foreign Proxy server forwards the request to the corresponding Home Proxy server first with ICP message. If it is still a cache miss, then to the origin server. Duplication N/A It is the Foreign Proxys responsibility to monitor the status of each nomadic node. When a node leaves, the Foreign Proxy needs to send the modified profile to the nodes Home Proxy and the visited URL list back to its Home Proxy. The Home Proxy then decides which ones to fetch and store them on the local disk.

PAGE 40

29 clients, the response time they provide to any one client worsens due to the complex hierarchy [TEW99]. In x-ICP, such a problem does not exist. There are no siblings and parent in our design. The Foreign Proxy will contact only with the Home Proxy where a great number of objects were previously downloaded by the same user. This will result in a relatively high hit rate compared to visiting other proxy servers. Moreover, because of no broadcasting, the Internet traffic is reduced and response time is shortened since there is no need to wait for the slowest response from all probed nodes. Mobile IP versus X-ICP In this section, we will address the similarities and differences between Mobile IP and x-ICP. Analogous to Mobile IP [PER98a], the main processing procedures of x-ICP can be divided into four major steps: Proxy Service Discovery, Sibling Proxy Server Configuration Web Page Delivery Cache Duplication Details are illustrated in Table 1: Design Details of X-ICP X-ICP modules Before talking about the procedures for how an HTTP request is satisfied by the Foreign Proxy when x-ICP is deployed, we need to introduce two new modules on the proxy server, Node Monitor and Cache Copier, as Figure 3-3 shows. The Node Monitor Module is responsible for maintaining several lists when a proxy server functions as a Foreign Proxy. One of the lists is a foreign user list. Those users, who temporarily reside on this network, are on this list. First, when a nomadic user attaches to a foreign network, the proxy service discovery takes place. Second, the user

PAGE 41

30 agent registers with the Node Monitor of th e discovered proxy, that is, to create a new node on the user list with the us ers ID. The ID could be eith er the care-of address of the nomadic user or the IP addre ss on the users home network. A nother data structure is the object list. Each user has a corresponding list. All the URLs requested by the user, which are either cached locally or fetched from origin servers, are inserted into that list; namely, the objects fetched from the Home Proxy are not on the list. This is simply Figure 3-3. Modules on proxy se rver with x-ICP being deployed. because these objects would be sent back to the Home Pr oxy when the user leaves, and those already on the Home Proxy are not nece ssary to be sent back later on. Having detected the users departure, the Node Monitor sends over th e corresponding list of URLs to the Cache Copier module on the users Home Proxy. Figure 3-4 gives the overview of the two lists. The Cache Copier is an active module on the users Home Proxy, whereas the Node Monitor functions when the proxy server is considered as a Foreign Proxy. First of all, security is an important issue when retrieving objects from a third party site. The Proxy Server Server Side Process Side Storage Manager Node Monitor Cache Copier To Web From Client Exchange with other cache copier Exchange with other Node Monitors

PAGE 42

31 Cache Copier needs to authenti cate the list before fetching the objects. This can be done by encrypting messages with the secret key carried by a mobile user. Second, for each object on the list sent over from any Foreign Proxy, the Home Proxy checks whether those objects are already stored. If yes, th e nodes of the cached objects are removed from its object list. Third, the Cache Copier also looks up the expiration time of those cached objects, if the difference of e xpiration time (Te) and current time (Tc) is less than the sum of three values: the processing time on both ends: Cache Copier and Node Monitor (Tp), Foreign User 1 Foreign User 2 Foreign User n URL 1 URL n URL 2 URL 1 URL n URL 2 URL 1 URL n URL 2 Object Lists Foreign User List Figure 3-4.Data structures on the Node Monitor. There are two lists here: one list is the foreign user list to keep track of the m obile users; the other list is the object list for each user. the round trip time to fetch the co py (Tt) and a small threshold value S, then this URL node would be removed from the object list. Simply, the object would be fetched if Te Tc < Tp + Tt + S

PAGE 43

32 This would help the Home Proxy to download a frequently visited object from a closer proxy server instead of the often far away origin server. Fourth, the QoS of network, like the availability of network bandwidth, will be used to decide whether to download the objects from the Foreign Proxy. Processing Procedures of X-ICP Proxy service discovery When proxy services are needed to be accessed from a wireless device, a new domain of research and challenging problems come into the picture. Finding a service efficiently becomes important. This is a broad research area, and we talk about Service Location Protocol (SLP) briefly here. Many features make SLP a good choice for our proxy service discovery model. First, traditionally, users find services by using the name of a network host (a human readable text string), which is an alias for a network address. The Service Location Protocol eliminates the need for a user to know the name of a network host supporting a service in advance. The user instead names the service and supplies a set of attributes which describe the service. The Service Location Protocol allows the user to bind this description to the network address of the service, and it provides a dynamic configuration mechanism for applications in local area networks. Second, it is not a global resolution system for the entire Internet; it is instead intended to serve enterprise networks with shared services. Applications are modeled as clients need to find servers attached to the enterprise network at a possibly distant location. For cases where there are many different clients and/or services available, the protocol is adapted to make use of nearby Directory Agents that offer a centralized repository for advertised services. For example, the proxy server can run a service agent program to broadcast its service to its network or

PAGE 44

33 bit can register with a Directory Agent to be retrieved later by other agents. Third, unlike Jini, it is programming language independent. In x-ICP, when a user attaches to the new network, the user agent sends out the inquiries to look for a nearby proxy server. Having received the reply, the user agent modifies the settings of its own browser to point to the new proxy, and a request to use x-ICP to group the discovered proxy and its Home Proxy is sent out to both proxy servers. The new proxy reconfiguration and registration take place next. Sibling proxy configuration and registration Sibling proxy configuration. Standard ICP is modified to adapt to our sibling proxy configuration process. In ICP v2, configuring caches within a hierarchy requires establishing peering or parent relationships, which currently involves manual configuration at both ends. One caching server must indicate that the other is a parent or sibling. The other cache adds the first cache to its access control lists correspondingly, like a child or sibling. In x-ICP, when a nomadic node moves to a new location and discovers a new proxy server, the configuration file of the Foreign Proxy is modified and the accessing list of the nodes Home Proxy is updated. Given the scenario in Figure 3-5, we will show how the configuration procedures work. A nomadic node M was originally connected to the Net1, then attached to the Net2. The Proxy4 is considered as its Home Proxy and the ProxyE is the Foreign Proxy. Having attached to the Net2, node M inserts the following line into the configuration file of ProxyE as ICP required: cache_host Proxy4.Net1 sibling HTTP-port icp-port.

PAGE 45

34 Cache_host is the defined directive from ICP. Proxy4.Net1 is the host name or IP address of the Home Proxy server. The word sibling indicates the relationship between Proxy4 and ProxyE. Unlike ICP, there are no other relationships, like parent or Figure 35. A nomadic node M moves from Net1 to Net2. multicast, in x-ICP. In the meantime, Proxy4 is notified by Node M to update its access list as follows: acl src ProxyE ProxyE.Net2 HTTP_access allow ProxyE ICP_access allow ProxyE The first line above defines an access control entry named as ProxyE which specifies a source IP address of the proxy machine on Net2. The next two lines indicates which protocols can be used. In this case, the caching server on Net2 would then be allowed to make any request to both the HTTP and ICP ports. This implementation is the same as that on Squid proxy servers except the configuration file is modified by nomadic nodes dynamically. Security Issues. Security needs to be carefully considered when the configuration is being updated. First, we assume that strong authentication mechanisms have been

PAGE 46

35 implemented by the Mobile IP. Second, we put more information on the entry list to secure our protocol because we are opening a door here to malicious hackers if the above implementations are used. For example, if someone puts an entry onto your list, saying look at his server as a sibling, and the server always satisfies the requests by returning irrelevant pages. This is dangerous. To prevent this from happening, we insert more information into the entry on the Foreign Proxy server. Regarding the same case presented in Figure 3-5, an entry is shown with one more constraint in bold: cache_host Proxy4.Net1 sibling HTTP-port icp-port care-of address When Node M moves to Net2 and makes a request to register, the Foreign Proxy server also appends node Ms care-of address to the entry. Next time, when an HTTP request comes in and if it is a cache miss, the proxy server looks up the caching list with the senders care-of address. If there is a match, it forwards the requests to the corresponding Home Proxy server. Thus, no one can redirect other Mobile Nodes requests. The security problem of updating the Home Proxys access list, when the Mobile Node is away from home, can be easily solved with the secret key carried over by the node and reconfiguration request is encrypted with the key. Register with Node Monitor. One more task that needs to be done is to register with the Node Monitor, which maintains a foreign node list on each proxy server. Having updated Access Control List (ACL), the monitor adds an entry to the list. The entry consists of three parts. The first part is the Mobile Nodes ID. The second part is the host name or IP address of its Home Proxy server. In the above case, the entry is like M.Net1, Proxy4.Net1. And third, the Node Monitor creates a corresponding empty object list for the node for later object retrieval.

PAGE 47

36 Hops Detection. Deploying x-ICP on different networks can bring more overhead than expected. The ICP v2 was designed to group the proxy servers on the intranet, which assumes they are not far away from each other. But the behavior of a Mobile Node is unpredictable so its new attachment point to the Internet might be too many hops away from its home network. By the time the IP v4 is implemented, the diameter of the Internet is about 30 hops, according to statistical data [TRE93]. The Internet's unbroken growth and recent fundamental topology changes within the international backbone make the maximum hop counted to 40, which can be currently observed in the worst case [TTLxx]. It is very likely the Mobile Node has the same distance from the Home Proxy server as from the original Web server when it is away from home. Before a Mobile Node decides to fetch a copy from its Home Proxy server, it needs to estimate how many hops it is away from the home network. An easy way to do so is to use the traceroute algorithm [SMI00]. Having obtained the number of hops away from the home network, the Mobile Node can decide whether to contact the Home Proxy every time when a cache miss happens locally. Given that the diameter of the current Web is 40 hops, if the number of hops is less than some threshold which is less than 40, the Mobile Node could try to fetch objects from the Home Proxy first, otherwise, the origin site would be contacted directly. Knowing the hops, it also helps to set the TTL value in the ICP query so that the whole system can work in a more efficient way which eliminates the routing loops. Our experiments show some results which can be referred to as the threshold to determine whether or not to fetch from the Home Proxy.

PAGE 48

37 User profile delivery. Having finished the configuration, the mobile user agent sends out a request to the Home Proxy to ask the latest profile version number. If the current mobile device has been offline for a while and the version number is older than the requested one, then the latest users profile is fetched includes bookmarks, cookies, history links, contact information, and so forth. The Foreign Proxy simply maintains a copy of the profile, monitors the updates on those profile items, and modifies them periodically. General Web Object Delivery When a nomadic user makes a request via the Foreign Proxy, the Storage Manager of the proxy first checks the local caching storage. If it is a cache hit, the object will be returned directly, and the URL of the object will be inserted into the object list of that user. If it is a cache miss, the Foreign Proxy will forward the request to the Home Proxy first, if still a miss, then to the origin site. When the object is from the origin site, the URL of the object will be inserted into the users object list. This way all the URLs of requested objects, excluding those downloaded from the Home Proxy, are on the object list. Unlike the way in which traditional Web caching deals with a cache miss, x-ICP sets up an extra round-trip between the Home Proxy and Foreign Proxy. Therefore, if the cache misses on the Home Proxy take a significant percentage of total forwarded requests from Foreign Proxy, the system performance will be degraded. On the other hand, if the cache hit rates on the Home Proxy is high and the Home Proxy is closer to the Foreign Proxy than the origin site, we could improve the system performance. Namely, if we could retrieve many objects from a nearby proxy, we save some amount of time Tsave than downloading them from origin sites. If the requests forwarded to the Home Proxy

PAGE 49

38 are cache misses, we waste some amount of time Twaste. Thus if we are able to achieve Tsave > Twaste, the x-ICP is an efficient protocol. In the next chapter, we will discuss in what circumstances, the x-ICP improves the network performance. Profile Update and Cache Duplication The users profile is updated when the user leaves. When the Foreign Proxy detects that a mobile user leaves and some changes have been made on the profile, the Foreign Proxy increments the version number and sends it back to its Home Proxy for synchronization purpose. The goal of Cache Duplication is to copy the cached objects of a nomadic user from the Foreign Proxy to the Home Proxy when the user leaves the foreign network. The Node Monitor on the Foreign Proxy and the Cache Copier on the Home Proxy cooperate with each other to accomplish this task. When the Node Monitor detects the nomads departure from the local network, it begins to negotiate with the Home Proxy of the node. It removes the URLs of expired objects, and the links will be expired soon. The Node Monitor then sends the remaining object list to the Cache Copier of the Home Proxy. The Cache Copier asks its local Storage Manager to see whether any objects on the list are cached locally and removes them. Thus the Cache Copier makes a shortened URL list and sends it back to the Node Monitor of the Foreign Proxy. With the updated list, the Node Monitor is able to send out the objects accordingly, and the Cache Copier receives and stores them on the local disk of the Home Proxy. Having done so, the Node Monitor also deletes the entry of the go-away node from the Foreign Node list. And the whole list is checked thoroughly. If no other nodes are sharing the Home Proxy on the list, the corresponding cache-host line will also be removed from the configure file of this proxy.

PAGE 50

CHAPTER 4 SIMULATION AND ANALYSIS To gain some insight into the efficiency of xICP, we conducted some analyses by examining the trace logs collected by a proxy server at the Computer and Information Science and Engineering Department of the University of Florida. The proxy server identified some characteristics of collective user access patterns that were transformed into the foundation of x-ICP. Trace Collection and Characteristics This section poses and answers a number of questions about the potential performance of x-ICP. We will explore the bounds of x-ICP. Key questions include: What cache hit rates could effectively decrease document access latency? What is the best speedup x-ICP could achieve? For what range of distances can x-ICP work effectively? Table 4-1. Objects Distribution per Day on the Different CISE Sub-networks Sub-net#1 Sub-net# 2 Sub-net# 3 Sub-net# 4 Sub-net# 5 All others Objects/day 420 2307 6960 7280 23535 426 To answer these questions quantitatively, we have collected and analyzed Web access data from two environments. First, we present our observations on the traces of user requests collected by a proxy server at the CISE Department during the period October 29, 2001 to November 19, 2001. On average, there are 40,199 accesses every day from more than five sub-networks. Table 4-1 shows the request distribution from the different sub-networks and the corresponding population, which is in proportion to the 39

PAGE 51

40 number of requests. We selected three of them (Sub-net# 1,3,5) with a different number of requests and ran the simulation separately to test the hit rate on the Home Proxy. Second, we present the result of a 19-day NLANR trace [WES02]. The data are collected on one of their 10 proxy servers, named startap from February 24, 2002 to March 14, 2002. The feature of the root node in a caching hierarchy made it less useful for our analyses, but it helped us to obtain comparable results. Simulation Methodology The results presented in this section are based on Web caching simulations using our trace data as input. We installed the Squid proxy servers (version 2.4) on two UNIX machines, and configured them as sibling. The proxy directly answering clients requests is considered as the Foreign Proxy and the other is the Home Proxy. In analyzing the cache behavior of these traces, we use the first three days of each trace to warm up our Home Proxy caches before gathering statistics. Whether the object is cacheable or not is judged by the Squid proxy servers, and which objects are to be replaced are also taken care of by Squid. These traces have two primary limitations that affect our results. First, we assume the user linger time on the new location is one day long. Second, each time we start a new day simulation, the cache on the Foreign Proxy is set empty because currently no research has been conducted on what kind of Foreign Proxy the nomadic user is likely to attach to. Therefore, the compulsory misses on the Foreign Proxy should be higher than that in reality. To quantify the overall performance of the system and examine the impact of x-ICP, Figure 4-1 shows both the Home Proxy hit rates and Foreign Proxy hit rates in a 20-day trace. The bars are labeled on the x-axis with days. The lower portion of each bar shows

PAGE 52

41 the hit rate that would be seen by a local Foreign Proxy acting on behalf of the nomadic users new attachment point. The upper portion of the bar shows the improvement in hit rate that would be seen by the nomadic user using x-ICP. Those cache hits are from the users Home Proxy. In (a), for the Foreign Proxy bars, the average hit rate is 12.9% ranging from 0% to 29.1%. For the Home Proxy bars, the average hit rate is 22.1% ranging from 1.2% to 39.9%. In (b), for the Foreign Proxy bars, the average hit rate is 23.2% ranging from 9.1% to 72.6%. For the Home Proxy bars, the average hit rate is 19.8% ranging from 8.0% to 37.7%. In (c), for the Foreign Proxy bars, the average hit rate is 32.1% ranging from 9.4% to 67.0%. For the Home Proxy bars, the average hit rate is 16.7% ranging from 11.3% to 27.4%. In (d), for the Foreign Proxy bars, the average hit rate is 36.1% ranging from 16.9% to 64.7%. For the Home Proxy bars, the average hit rate is 12.2% ranging from 2.9% to 26.7%. From the above data, the Foreign and Home Proxy hit rates changed when different networks were tested. Actually, beyond that, the population and the number of requests of each sub-network play an important role. We briefly discuss this result here, and the details can be found in [WOL99] to explain the relationship between the hit rate and dxxCdxNCxCxCnxnN111,111 (1) population. Equation (1) summarizes the key formula from Wolman et al. yielding C N the aggregate object hit rate for a population N, where n denotes the number of requests. Thus, the hit rate is H N = p c C N, where p c is the probability that a requested document is cacheable. The Wolman model makes several assumptions: (1) object popularity follows a Zipf-like distribution; (2) object popularity is uniform across the population; (3) objects

PAGE 53

42 are cacheable with probability p c independent of popularity; and (4) inter-arrival times for object requests and updates are exponentially distributed with a parameter determined by the objects popularity [GAD00]. All these assumptions are fit for our nomadic environment so that we are able take advantage of their conclusion. In short, the bigger 00.10.20.30.40.50.60.71357911131517DayHit Ratio(%) Home Proxy Foreign Proxy (a) Data collected on Sub-net#1 of CISE proxy log 00.10.20.30.40.50.60.70.80.9123456789101112131415161718DayHit Ratio(%) Home Proxy Foreign Proxy (b) Data collected on Sub-net#3 of CISE proxy log Figure 4-1 Home Proxy and Foreign Proxy hit rates of the traces examined in this study.

PAGE 54

43 00.10.20.30.40.50.60.70.80.91357911131517DayHit Ratio(% ) Home Proxy Foreign Proxy Home Proxy Foreign Proxy (c) Data collected on Sub-net#5 of CISE proxy log 00.10.20.30.40.50.60.70.8135791113151719DayHit Ratio(%) (d) Data collected on NLANR startap proxy log Figure 4-1. Continued. population the proxy serves, the higher the local hit rate is. According to [GOL98, BAR00], the hit rate at a proxy is almost fixed, therefore the higher the local hit rate is, the lower it is on the Home Proxy.

PAGE 55

44 Since we are more interested in the behaviors of an individual or a group of nomadic users of fairly small number, we believe that the data collected from the Sub-net# 1 and 3 are more likely to match our criteria. We eliminated the data from Sub-net#5 because the requests from it took up half of the total requests of the entire department, which includes hundreds of students and faculty members. The NLANR trace shows the smallest Home Proxy hit rate, which is about 12.2%, because it is one of the ten root caches of the nationwide caching hierarchy system. This system can be considered to be serving a very large population, and it results in the very low hit rate. So we choose not to adopt its value either. Therefore, we calculate the average of the Home Proxy Hit Rates on Sub-net#1 and 3, which is 21%. In summary, if the x-ICP protocol is deployed, it would achieve a noticeable improvement on hit rate for nomadic users. Based on this hit rate, we will further explore how the x-ICP benefits nomadic users. Bandwidth Savings One of the most important issues on Web caching is to save bandwidth. During the simulation, we also collected the number of bytes downloaded from both the origin sites and the Home Proxy. As Figure 4-2 shows, on Sub-net#1, the average percentage of bandwidth used to download objects from the Home Proxy is 20%, and on Sub-net#3, it is 18%. So we consider that 19% bandwidth can be saved if we download Web objects from the Home Proxy. It is a big saving when two proxy servers are both on the same campus LAN or Corporation LAN. In this case, nearly one fifth of the bandwidth out of the total downloading bandwidth are consumed locally. On the other hand, 2% more traffic is created by exchanging x-ICP message between Home Proxy and Foreign Proxy. The

PAGE 56

45 00.050.10.150.20.250.30.350.40.45123456789101112131415161718DaysPercentage of Bandwidth sub-net1 sub-net3 Figure 4-2. The percentage of bandwidth used to download objects from the nearby Home Proxy. average size of each x-ICP packet is 80 bytes. The body of the message contains the string of the URL. All HTTP requests are forwarded to Home Proxy in the x-ICP format when there is a cache miss on the Foreign Proxy. Analysis Hit Rate versus Inter-proxy Delay In the previous section we drew a solid conclusion on the cache hit rate and bandwidth saving of x-ICP using our trace data. In this section, we will extend these results analytically to better understand the caching performance of x-ICP. In the x-ICP scheme, a Foreign Proxy forwards a missing request to the nomadic users Home Proxy to determine if 1. the Home Proxy holds the requested document 2. that document can be returned faster than from the origin server

PAGE 57

46 Whether such cooperation is worthwhile will mainly depend on the inter-proxy latencies. We begin by setting up a model to show the relationship between hit rate and inter-proxy delay based on the x-ICP infrastructure. Let us assume some users move from a Home Proxy to a Foreign Proxy. Here are some defined terms: Table 4-2. Variables Used in Analysis R the total number of object requests made by the nomadic users when they are attached to a new network C h the hit rate on a Home Proxy when R requests were made C f the hit rate on a Foreign Proxy when R requests were made D h the average delay between a Foreign Proxy and a Home Proxy D o the average delay between a Foreign Proxy and an origin server Finally, we have ])1([)1()1(ohhfofDCDCRDCRSpeedup (2) The numerator denotes the total amount of execution time to fetch Web objects from origin sites when x-ICP is not deployed. The term 1-C f is the cache miss rate on the Foreign Proxy, namely, the probability of fetching objects remotely. R(1C f )D o is the total delay when requests forwarded from the Foreign Proxy to the origin sites. The denominator is the total amount of execution time when x-ICP is deployed. The 1-C h is the cache miss rate on the Home Proxy. So when cache miss happens on a Foreign Proxy server, the delay D h occurs. If it is still a cache miss on the Home Proxy, there is another delay (1C h ) D o Equation (2) can be reduced to equation (3). ohhoDCDDSpeedup)1( (3) According to equation (3), we draw some conclusions below. The performance of x-ICP is related to only two factors:

PAGE 58

47 1. the hit rate on the Home Proxy, to whom the requests are forwarded by the Foreign Proxy 2. the rate of D o / D h Much research has been conducted on the Internet round-trip time (RTT) [COT00,WOR02]. We adopt the value 65ms for regional RTT within Europe and within North America, which is assigned to D o. Under the assumption of an individual or a small number of nomadic users, we assign the value 21% average hit rate from the previous section to C h. 024681012141611.051.11.151.21.25SpeedupRound-trip time (ms) Figure 4-3. As x-ICP is being deployed, the downloading speedup can be considered as a function of inter-proxy round-trip time. In Figure 4-3, the speedup value illustrates how many times faster the response time is when using x-ICP than not using it. As the graph shows, the higher the speedup, the less the inter-proxy RTT is required. When a nomadic user attaches to a new network, the RTT between the Home Proxy and Foreign Proxy cannot exceed 13.65 milliseconds, otherwise people have to wait a longer time to fetch the copies than to fetch from the origin server directly. On the other hand, the graph sees that when people want to

PAGE 59

48 experience a 1.22 times shorter response time, the RTT can not be more than 2 milliseconds. In conclusion, the RTT of the Home Proxy and Foreign Proxy is between 2 and 11.28 milliseconds to make x-ICP work efficiently. RTT versus Distance Our study further shows the relationship between RTT and physical distance. In [COT00], having measured 16 pairs of sites located in the United States, Europe and Japan, Cottrell et al. were able to generate an equation (4), where Y indicates RTT and is the function of the distance (kilometer), which is denoted by X in equation (4). This linear function will lead us to a very interesting approximation on the distance. Y = 0.024X + 5.8887 (4) With some simple calculations, we conclude that the maximum distance that x-ICP can support is about 322 kilometers (201 miles) when Y is 13.65 ms. We have also collected some data on RTT to 10 random selected sites in our lab. The simulation method in [ZHA93] was implemented. The result is shown in Figure 4-4. The seven hops are on the routing path, through which most Web object requests from our lab are sent to the origin sites. The first six hops are on campus. The seventh hop is a carrier providers node in another city. We tested the delays in six different periods of a day and observed that most delays are less than 2 ms on a campus-wide network. According to Figure 4-3, if it is a cache hit on the Home Proxy, the response time to fetch that object can be at least 1.22 times faster when x-ICP is deployed on a campus wide network. Another interesting observation is that, on the campus wide network, the RTT to a router closer to the user agent is not necessary less than that to a farther away router. In Figure 4-4, the hop 3 is closer to the browser than hop 6 in physical distance, but it takes

PAGE 60

49 longer amount of round-trip time on hop 3 because of the processing time spent on the router, for instance opening the port and sending back the echo message. 0.002.004.006.008.0010.0012.0014.0016.0018.00123456time period of a dayDelay(ms) hop 1 hop 2 hop 3 hop 4 hop 5 hop 6 hop 7 Figure 4-4. Round-trip delays tested from the lab in the CISE Department of the University of Florida to the seven outbound routers. In the above analysis, we used some empirical values. To further explore the x-ICP performance, we analyze the sensitivity of x-ICP on D o and C h The D o we used is the RTT measurement on a small network packet. When a Web object is downloaded, especially on a wireless network, the value of D o is bigger. Figure 4-5 shows that the x-ICP speedup is not changed significantly when D o grows. On the other hand, when the overall network speed becomes faster, the speedup drops if the delay between the two proxy servers is large. Figure 4-6 illustrates that to improve the performance of x-ICP, the hit rate on the Home Proxy is critical. When hit rate is bigger, speedup grows faster, for instance, when the hit rate is 50% on the Home Proxy, the speedup can be 2. When the hit rate on the Home Proxy is low, its impact on the speedup is not significant.

PAGE 61

50 00.20.40.60.811.21.401002003004005006007008009001000Average reginal RTT within North America (ms)Speedup Dh=2 Dh=13.65 Figure 4-5. The impact of RTT values on speedup 0510152025303500.10.20.30.40.50.60.70.80.91Cache Hit Rate on Home Proxy (Ch)Speedup Dh=2 Dh=13.65 Figure 4-6. The impact of the cache hit rate of the Home Proxy on speedup In this chapter, we first measured the cache hit rate on the Home Proxy when x-ICP is deployed. Then with analysis, we found the relationship between the cache hit rate and round-trip time, and then we mapped the round-trip time to the physical distance with a

PAGE 62

51 linear equation. We are therefore able to answer the questions asked at the beginning of this chapter. About 21% cache hit rates could be obtained on the Home Proxy server with x-ICP deployed. Regarding the bandwidth, about 19% of the total traffic is on the path between the Home Proxy and the Foreign Proxy instead of between the origin site and Foreign Proxy. Regarding the response time, 21% of objects are fetched at least 1.22 times faster on a campus/corporation network. Nomadic users can attach to any new network without lowering the performance as long as the Foreign Proxy is not farther than 201 miles away from the Home Proxy in the circumstances of the current Internet. Let us go back to the two scenarios imagined at the beginning of Chapter 3 with these conclusions. While attaching to the College of Healths network, a Computer Science (CS) Department student can download about one-fifth of the objects (pages, documents, images) from the CS proxy via the campus backbone, which is at least 1.22 times faster than to get it from the origin site. Moreover, if someone wants to work at home on the weekend, his ISP can download most objects from his office proxy server as long as his home is not 201 miles from the office, and the total response time is shorter. This will also help the ISP to make some local requests instead of long distance or even international requests to the origin sites on the Internet.

PAGE 63

CHAPTER 5 PARTIALITY ADAPTATION Overview of Partiality Adaptation and Fidelity Negotiation We have talked about x-ICP to deliver the special user profile for the individual mobile user and the performance of x-ICP. In this chapter, we will focus on delivering the general Web contents. On the server side, Web objects can be classified into two categories: (1) an XHTML page, also known as a container page or an index page; and (2) a content file, including many types such as video, image, text, and audio. Significant research has been done to enable speedy content delivery of the second category, for example, the Internet content transcoding and distilling for many specific file formats [CHA02, FOX96, LEI01, MOH98,]. In [SMI98], a framework is introduced to transcode contents among those types. In regard to the first category object, a widely adopted approach is to use XML to present the content and use XSL to describe the presentation. To adapt to different devices or context, XSLT is used to convert the source XML to the destination XML file. Our research is focused on both of these two categories because they are closely related to each other. Whether or not to download the objects of the second category depends on the references in the container pages. Efficiently removing some embedded object placeholders in the XHTML page can significantly reduce the total number of downloaded objects. On the client side, A plethora of exotic electronic devices exist, such as pagers, PDAs, and color-display cellular phones. There is no sign that the diversity of their 52

PAGE 64

53 characteristics will diminish anytime soon. As mobile devices come of age, one simple Web page is no longer universally valid, and more content services are required. To better understand the client capabilities, network connectivity, or user preference, metadata or annotation is required and ranges from simple to complex descriptions. On the one hand, many simple metadata are incorporated into HTTP headers, such as user agent information and page expiration time. On the other hand, a very complex metadata like CC/PP exists specifying client-side profile, including every detail of hardware and software. Moreover, markup languages embed the metadata into documents--the tags. In our research, we use tags to deliver the following information: the appropriate size of an XHTML page, including the appropriate number of portions and their priorities the available versions of each object and their properties Partiality adaptation and versioning negotiation are designed to deliver different Web contents derived from the same page for heterogeneous networks and devices. There are thus two types of corresponding tags: priority tag and fidelity tag. We will see more details on the second one in Chapter 6. These tags can be incorporated into other XHTML languages so more complicated functionalities can be implemented while the previous adaptation and negotiation goals can still be achieved. Figures 5-1 and 5-2 illustrate the overall structure of an XHTML page with priority and fidelity tags and its Document Type Definition (DTD). Here we name the language with the new tags as Partiality and Fidelity Markup Language (PFML) for documentation purpose. Embedded priority tags in an XHTML page indicate the Web authors intention on how to partition a page into several fragments which are easier to be adapted. Then a portion of the page can be downloaded upon the users request. Furthermore, the priority

PAGE 65

54 tag can be used for not only content files but also XSL and XSLT template files. The overall Internet traffic (including those for desktops) could be reduced by downloading XHTML pages in a smaller granularity and the reduced number of subsequent object requests. PFML Priorit y Other HTML Tags Fidelit y Choice Scri pt Im g Embe d Figure 5-1. Hierarchy of PFML elements Priority tags not only maintain the end-to-end communication feature of HTTP, but also give both ends a better way to communicate. Publishers can use them to indicate their concerns on different objects in terms of priority. Clients can use them to fetch desired Web objects with appropriate user agent priority values. In our design, the smaller the value, the user agent is willing to fetch more objects. And intermediaries can apply the content services accordingly, for example, if there is a traffic jam on the network, the proxy server can reduce the size of the index page so the page can reach the user with a shorter delay.

PAGE 66

55 Figure 5-2. The Document Type Definition of PFML. Figure 5-3 shows how the content adaptation and negotiation work. The full version of the page consists of three parts with priority values 0, 5 and 9. We assume the user device is a middle-level one and the device priority value is 5. In step 1, the original page is tailored to the one without the portion of priority as the response to the users first request. All the portions with priority values lower than 5 are filtered out. This adaptation work can be easily done on either the origin site or a proxy server. In step 2, the lower resolution image is selected by the client agent according to the variant list, which is embedded in the container page in the first response. The negotiation is much more efficient here because the adaptation has generated a smaller page with fewer embedded objects. The mobile devices can therefore afford process it since fewer selection algorithms need to run. We will talk about partiality adaptation in great detail in this chapter and discuss Versioning Negotiation in Chapter 6.

PAGE 67

56 Foo.png Foo.png 1 2 Foo.png Foo. g i f Foo. g i f Figure 5-3. Processing by partiality adaptation and versioning negotiation. With priority tags, the number of objects to download is reduced in step 1, and with fidelity tags, the appropriate version of the object is downloaded in step 2. Partiality Adaptation Design Details Design of Priority Tag The priority tag is used to divide a Web page into several fragments in order to cater to the devices with different capabilities. Each part is assigned a priority value. The author can use the attribute values of the Priority tag to express their intentions. Value indicates that the corresponding content has the highest priority which must be sent out when its URL is requested, whereas the value means the corresponding content is the least important, compared to other parts of the Web page. By default, the value is set to for each portion of a Web page. The values could be incremented or decremented automatically with the algorithms described in the Priority Assignment Algorithm Section as long as the fixed attribute is set as N. The fixed attribute is used to include those parts which are always necessary, such as the portion or for those

PAGE 68

57 portions lacking links because our automated priority evaluation algorithms are based on the statistics of the clicks on the links inside a fragment. An example of partiality adaptation is given in Figure 5-4. Mr. Foo has a personal Web site. Whenever a request to his homepage is made, he always wants his selfintroduction and contact information to be downloaded. So he assigns those fragments < TITLE> Foos Home

I am

I like sports and music

Foo1 < A HREF = HTTP://>

Foo2 < A HREF = HTTP://>

Phone #:

(a) An HTML page of Foos personal Web site. Figure 5-4. Foos homepage implemented with HTML(a) and PFML(b)

PAGE 69

58 Foos Home

I am

I like sports and music

Foo1 < A HREF = HTTP://>

Foo2 < A HREF = HTTP://>

Phone #: (123)456-7890

(b) Modified Foos personal page with priority tags. Figure 5-4. Continued. with priority , and he defines the remaining portions as optional with the priority value set as . Automated Assignment Algorithm of Priority Values Priority assignment algorithm Server Side. An XHTML page first needs to be divided into several segments because the smaller the granularity, the easier it is to adapt to different devices. Each segment can be as big as a whole page or as small as a table cell, and each segment can

PAGE 70

59 be a link to an object or even a word. The decision on how to fragment a page is made by either the Web page author or some automated programs, such as a Web page could be partitioned syntactically or semantically. Regarding small Web sites, such as personal sites mentioned in Figure 5-4, the author could fragment a page into several portions according to the semantic by themselves. Fragmenting big commercial sites such as Yahoo.com may not be an easy job due to its big file size which is about 50k. Instead, an automated program can parse and fragment it. Some HTML tags could be considered as the delimiters, such as pairs of

for headings,

for paragraphs, for frames,
Permanent Link: http://ufdc.ufl.edu/UFE0002406/00001

Material Information

Title: Ubiquitous web caching
Physical Description: xi, 96 p.
Language: English
Creator: Gu, Wenzheng ( Dissertant )
Helal, Abdelsalam A. ( Thesis advisor )
Frank, Michael P. ( Reviewer )
Gader, Paul D. ( Reviewer )
Hammer, Joachim ( Reviewer )
George, Allen D. ( Reviewer )
Publisher: University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: 2004
Copyright Date: 2004

Subjects

Subjects / Keywords: Computer and Information Science and Engineering thesis, Ph. D.   ( local )
Computer network protocols   ( lcsh )
Cache memory -- Design   ( lcsh )
Dissertations, Academic -- UF -- Computer and Information Science and Engineering   ( local )

Notes

Abstract: Internet access by mobile users, who roam on a mobile network with exotic electronic devices, presents a scenario of browsing that is substantially different from the wired network. When users, with current Web technology, change devices or the point of attachment to the network, a different Internet appears, for example, personal profiles like bookmarks and shopping carts for ecommerce sites are lost. Furthermore, the response time is longer, the heterogeneity of mobile devices is conflict with the wide variety of Web contents, and the user intent is not automated. ABSTRACT: In this dissertation, we explore two ways to deal with above challenges. First, the current Web caching mechanism is applied to wireless networks. We designed a mobile Web caching protocol -- the Extended Internet Caching Protocol (x-ICP). It is deployed at the edge of the Internet to deliver Web contents from a nearby Home Proxy server if there is no performance degradation compared to fetch them from the origin sites. The x-ICP is also responsible for giving users a consistent look on their personalized Web pages. Second, we applied several content services to the cached objects. Three adaptive mechanisms are designed to cope with device heterogeneity and Web content variety. We first created the adaptive Web contents, where the Partiality and Fidelity Markup Language (PFML) is used to embed metadata into Web pages. Based on this information, the Partiality Adaptation and Versioning Negotiation (PAVN) approaches are used to adapt cached Web contents to different devices in the first place. We also designed client and server side adaptive algorithm to let users express their intents automatically and invisibly.
Subject: adaptation, caching, mobile, negotiation, web, xml
General Note: Title from title page of source document.
General Note: Includes vita.
Thesis: Thesis (Ph. D.)--University of Florida, 2003.
Bibliography: Includes bibliographical references.
General Note: Text (Electronic thesis) in PDF format.

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0002406:00001

Permanent Link: http://ufdc.ufl.edu/UFE0002406/00001

Material Information

Title: Ubiquitous web caching
Physical Description: xi, 96 p.
Language: English
Creator: Gu, Wenzheng ( Dissertant )
Helal, Abdelsalam A. ( Thesis advisor )
Frank, Michael P. ( Reviewer )
Gader, Paul D. ( Reviewer )
Hammer, Joachim ( Reviewer )
George, Allen D. ( Reviewer )
Publisher: University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: 2004
Copyright Date: 2004

Subjects

Subjects / Keywords: Computer and Information Science and Engineering thesis, Ph. D.   ( local )
Computer network protocols   ( lcsh )
Cache memory -- Design   ( lcsh )
Dissertations, Academic -- UF -- Computer and Information Science and Engineering   ( local )

Notes

Abstract: Internet access by mobile users, who roam on a mobile network with exotic electronic devices, presents a scenario of browsing that is substantially different from the wired network. When users, with current Web technology, change devices or the point of attachment to the network, a different Internet appears, for example, personal profiles like bookmarks and shopping carts for ecommerce sites are lost. Furthermore, the response time is longer, the heterogeneity of mobile devices is conflict with the wide variety of Web contents, and the user intent is not automated. ABSTRACT: In this dissertation, we explore two ways to deal with above challenges. First, the current Web caching mechanism is applied to wireless networks. We designed a mobile Web caching protocol -- the Extended Internet Caching Protocol (x-ICP). It is deployed at the edge of the Internet to deliver Web contents from a nearby Home Proxy server if there is no performance degradation compared to fetch them from the origin sites. The x-ICP is also responsible for giving users a consistent look on their personalized Web pages. Second, we applied several content services to the cached objects. Three adaptive mechanisms are designed to cope with device heterogeneity and Web content variety. We first created the adaptive Web contents, where the Partiality and Fidelity Markup Language (PFML) is used to embed metadata into Web pages. Based on this information, the Partiality Adaptation and Versioning Negotiation (PAVN) approaches are used to adapt cached Web contents to different devices in the first place. We also designed client and server side adaptive algorithm to let users express their intents automatically and invisibly.
Subject: adaptation, caching, mobile, negotiation, web, xml
General Note: Title from title page of source document.
General Note: Includes vita.
Thesis: Thesis (Ph. D.)--University of Florida, 2003.
Bibliography: Includes bibliographical references.
General Note: Text (Electronic thesis) in PDF format.

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0002406:00001


This item has the following downloads:


Full Text












UBIQUITOUS WEB CACHING


By

WENZHENG GU


















A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
DOCTOR OF PHILOSOPHY

UNIVERSITY OF FLORIDA


2003

































Copyright 2004

by

Wenzheng Gu

































To my parents, Mingchu and Ruilian,
and my lovely wife Xiaoli.















ACKNOWLEDGMENTS

First and foremost, my deepest appreciation goes to Dr. Sumi Helal, chairman of

my committee. Dr. Helal provided me with continuous and excellent guidance and

mentoring throughout my academic years at the University of Florida. His strong support

and efforts made my research work much easier. His motivation encouraged me to

surmount many obstacles in the past four years.

Also, I would like to express my gratitude to Drs. Michael P. Frank, Paul D. Gader,

Joachim Hammer, and Allen D.George for serving on my supervisory committee and for

their valuable comments and suggestions. Thanks Dr. Frank to spend extra time with me

to improve my experiment performance.

I would like to thank my lab mates who gave me constructive advice.

Last, but not least, special thanks go to my parents who supported me to go abroad

to continue my education and to my wife for her continuous support in my educational

endeavors.
















TABLE OF CONTENTS

page

L IST O F T A B L E S ........ .. ...... .. ............ .................................................... .. vii

LIST OF FIGURES .............................................. ........ ...... ............. viii

A B ST R A C T ................. .......................................................................................... x

CHAPTER

1 IN TR OD U CTION ............................................... .. ......................... ..

M motivation ................................................ 1
O overview ................ ...................... ........................ ...............
Design Philosophy, Objective, and Contribution ..........................................9
O organization of This D issertation ............................................... ..................... 10

2 RELATED RESEARCH WORK .................................................... ................11

M ob ile IP ......................................... .............................. ............. 11
Three H ierarchies of W eb Caching................................. ......................... ........ 13
Service D discovery ....................... ................................ .. ........ .... 16
Content Adaptation and N negotiation ........................................ ............... 19
D evice D description ............................................................ ............... 19
Content A adaptation ...........................................................................20
C ontent N negotiation ...................................................... ..... .......... 21
W eb Page Partition ........................................ ........................... 23

3 ARCHITECTURE OF EXTENDED INTERNET CACHING PROTOCOL............24

Overview of X-ICP Architecture ................................. ....................24
M obile IP versu s X -IC P ........................................................................... .... ... 29
D design D details of X -IC P ................................. .............................. ...................29
X-ICP M odules....................................... .......................... ..29
Processing Procedures of X-ICP ..................... ................... ............... .32
Proxy service discovery ............................ ................... 32
Sibling proxy configuration and registration...........................33
General Web object delivery ................................................37
Profile update and cache duplication................. ..............38



v









4 SIMULATION AND ANALYSIS ON X-ICP.........................................................39

Trace C collection and Characteristics ........................................ .....................39
Sim ulation M methodology ............................................... ............................ 40
A analysis .................................................. 45

5 PARTIALITY ADAPTATION........................................................... .....................52

Overview of Partiality Adaptation and Fidelity Negotiation..............................52
Partiality Adaptation D design D details ........................................ ............... 56
D esign of Priority Tag ....... ................. ........ ............... 56
Automated Assignment Algorithm of Priority Values..............................58
Priority assignm ent algorithm ............................. ............... 58
Data structure of priority assignment algorithm....................64
Web Caching in Partiality Adaptation..................... ....... ..... ...............66
Experimental Evaluation.......................................... 66

6 VER SION IN G NEGOTIA TION .................................................................. ........76

D esign of Fidelity Tag ............................................ .. ....... .......... .... 76
V ersioning Selection A lgorithm ........................................ ........................ 77
Advantages of Versioning Negotiation......................................................80
Web Caching on Versioning Negotiation............................................................81
Simulations and Analysis on Versioning Negotiation ...........................................82

7 CONCLUSION AND FUTURE WORK ....................................... ............... 87

S u m m a ry .......................................................................................................... 8 7
F future W ork ..................................................................................................89

L IST O F R E F E R E N C E S ....................................................................... ... ................... 9 1

B IO G R A PH IC A L SK E TCH ..................................................................... ..................96
















LIST OF TABLES


Table page

3-1. Comparison between Mobile IP and X-ICP.............. ........................................28

4-1. Objects Distribution per Day on the Different CISE Sub-networks ....................39

4-2. V ariables U sed in A nalysis............................................... ............................. 46

5-1. Example Data on 12-day Trace of Cellular Phone.................... .................69

5-2 D distribution on 100 W eb Sites........................................................ ............... 74
















LIST OF FIGURES


Figure page

1-1. M ark W eiser's vision on ubiquitous computing.................................. ... ............... 1

1-2. Trends on global wireless and Internet growth. ........................................ ................3

1-3. General architecture for ubiquitous Web caching ............. ..... ..................5

2-1. IP in IP encapsulation in M obile IP...................................... ......................... 13

2-2. A two-layer caching hierarchy. .............................................................................14

2-3. The hierarchy of Internet Caching Protocol (ICP). ....................................................15

2-4. SLP agents and their transactions for service discovery and registration ................17

2-5. Overview of content negotiation solutions ...................................... .................22

3-1. Overview of x-ICP architecture .................................................... ...................25

3-2. Applying x-ICP to Mobile IP's triangle routing.....................................................27

3-3. Modules on proxy server with x-ICP being deployed ...........................................30

3-4. Data structures on the N ode M onitor.................................................. ............... 31

3-5. An example of a nomadic node M moves from Netl to Net2........................ 34

4-1. Home Proxy and Foreign Proxy hit rates. ...................................... ............... 43

4-2. The percentage of bandwidth used to download objects from the nearby Home
P ro x y ............................................................ ................ 4 5

4-3. As x-ICP is being deployed, the downloading speedup can be considered as a
function of inter-proxy round-trip time. ........ .......... ........... ............... 47

4-4. Round-trip delays tested on campus network................................. ..... .............49

4-5. The impact of RTT values on speedup................................. ..................50

4-6. The impact of the cache hit rate of the Home Proxy on speedup.............................50









5-1. Hierarchy of PFM L elem ents ............................................................................54

5-2. The Document Type Definition of PFML............................................ ..........55

5-3. Processing on partiality adaptation and versioning negotiation.................................56

5-4. Foo's homepage implemented with HTML(a) and PFML(b).............. .....................58

5-5. Page Segment Priority Value Decision Algorithm .................................................60

5-6. Client Agent Priority Value Decision Algorithm ..................................................62

5-7. The heap data structure for priority selection algorithm ........................................65

5-8. Experimental environment on partiality adaptation. .............................................67

5-9. Raw data collected on a 12-day trace. (a) represents the RTT measured on cellular
phone. (b) RTT m measured on proxy ........................................ ...... ............... 69

5-10 Sim ulation results on PFM L ......... ................................................ ............... 72

5-11 Simulation data on 100 Web sites retrieved by cellular phone. .............................73

6-1. An Example of using PFML with both Fidelity and Priority tags ...........................78

6-2. Simulation environment to compare performance on CC/PP and PAVN negotiation
m o du les ............................................................................. 8 3

6-3. Simulation results on CC/PP and Versioning Negotiation ........................................84

6-4. Tim e m measured on the server side ........................................ ......................... 85














Abstract of Dissertation Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Doctor of Philosophy

UBIQUITOUS WEB CACHING

By

Wenzheng Gu

December 2003

Chair: Abdelsalam (Sumi) Helal
Major Department: Computer and Information Science and Engineering

Internet access by mobile users, who roam on a mobile network with exotic

electronic devices, presents a scenario of browsing that is substantially different from the

wired network. When users, with current Web technology, change devices or the point of

attachment to the network, a different Internet appears, for example, personal profiles like

bookmarks and shopping carts for ecommerce sites are lost. Furthermore, the response

time is longer, the heterogeneity of mobile devices is conflict with the wide variety of

Web contents, and the user intent is not automated.

In this dissertation, we explore two ways to deal with above challenges. First, the

current Web caching mechanism is applied to wireless networks. We designed a mobile

Web caching protocol -- the Extended Internet Caching Protocol (x-ICP). It is deployed

at the edge of the Internet to deliver Web contents from a nearby Home Proxy server if

there is no performance degradation compared to fetch them from the origin sites. The x-

ICP is also responsible for giving users a consistent look on their personalized Web

pages. Second, we applied several content services to the cached objects. Three adaptive









mechanisms are designed to cope with device heterogeneity and Web content variety. We

first created the adaptive Web contents, where the Partiality and Fidelity Markup

Language (PFML) is used to embed metadata into Web pages. Based on this information,

the Partiality Adaptation and Versioning Negotiation (PAVN) approaches are used to

adapt cached Web contents to different devices in the first place. We also designed client

and server side adaptive algorithm to let users express their intents automatically and

invisibly.

















CHAPTER 1
INTRODUCTION

Motivation

The most profound technologies are those that disappear. They weave themselves


into the fabric of everyday life until they are indistinguishable [WEI91]. This is the


paraphrased statement made by Mark Weiser in 1991. And it is the first vision of


pervasive/ubiquitous computing. As Figure 1-1 shows, people were expecting the same


convenience and computing power in the mobile device as the computer which sits on the

desk.







-Mainframe (one computer, mrrny
s.. people)
-PC (one pwIOum one crspeuBer)

person, rnany computers)






4

2o



Co o o L o 0 o o m
o w i'o f f ^ Vf f ff Uf Uf O


Figure 1-1. Mark Weiser's vision on ubiquitous computing.









Today, people use a wide range of devices, including desktops, laptops, handheld

personal digital assistants (PDAs), and smart phones that are connected to the Internet,

and use all kinds of networks, such as wireless LAN(802.1 lb/a), cell phone network

(GPRS), broadband network (DSL), and telephone network (56k modem). Two profound

technologies allow users to move around with computing power and network resources at

hand: portable computers and wireless communications.

Moreover, two trends can be seen standing out in networking and communication

as Figure 1-2 illustrates. (1) The World Wide Web can be considered as a large

distributed information system that provides access to shared data objects and continues

to grow exponentially. (2) The proliferation of the wireless Internet and telephone

devices creates ever greater demands on the networks of wireless carriers and service

providers. Therefore, we would expect that the combination of these two growing

technology trends--Internet access on the one hand and wireless access on the other--

would result in a potent combination. The wireless Web will enable a plethora of new

applications, especially for users on the move.

Much research has been done on the challenges to this new computing paradigm

[DUC92, FOR94, IMI94, MUK94, SAT95]. From our point of view, the challenges are

classified into three categories. The first category includes many wireless network issues,

for example, the frequent disconnection or handoff, the low bandwidth, the

heterogeneous networks, the point of attachment (surrogate), and address migration.

Work on ubiquitous computing is still in an early phase. Most work now concentrates on

the mobile infrastructure for wireless networking. Because ubiquitous computing

envisions hundreds of wireless computers in every office, its need for wireless bandwidth









is prodigious. Regarding handling mobility, networking developed over the past 20 years

with the assumption that a machine's name and its network address were unvarying.

However, once a computer can move from network to network this assumption is false.























Figure 1-2. Trends on global wireless and Internet growth.

Existing protocols such as TCP/IP and OSI are unprepared to handle machine mobility

without change. Researchers are now working on methods of augmenting or replacing

existing protocols to handle mobility [WEI93]. Therefore, mobility opens up new venues

for interesting and unique contents and services only possible in a mobile environment.

The second category is related to devices: power management, risks to data,

different sizes of user interface, and storage capacity. Consequently, new hardware and

software techniques must be developed. For example, applications need to be highly

optimized for space in order to fit in the limited memory on the mobile devices. For









Internet enabled devices, the reliable TCP/IP stack cannot be widely used; it takes too

much space and is not optimized for minimal power consumption.

The third category is even more challenging than the previous two due to the

following four situations: (1) User intent, which is the key to determine whether the

system can help or hinder the user. (2) Context awareness, which enables the system to

better understand the location dependent information. (3) Adaptation, which is necessary

when there is a significant mismatch between the supply and demand of a resource. (4)

Security, which is always a big issue on the network.

In summary, the performance of data delivery over different wireless networks is

unacceptably low today. Most Internet applications, especially Web access, require

efficient data transport. The degraded performance strongly discourages widespread use

of wireless access networks since the resulting price/performance ratio becomes too large

compared to alternative wired access technologies [BAL98].

One of the reasons of this performance degradation is that the current network

protocols do not support mobile users. For example, Web caching is widely used on the

wired Internet so that a copy of Web object can be returned from a proxy server usually

closer to the user agent than the origin server. But there is no mobile Web caching

protocol. When a user leaves home network, he is disconnected from the caching server

where many previously downloaded objects are stored. Therefore the performance is

degraded. Another reason is that the small palmtop devices are not able to handle all

kinds of Web contents, such as Java applets, animation graphics, and so forth. So it takes

longer time to do further adaptation on the content for mobile devices.









In this dissertation, we explore two ways to deal with those challenges as Figure

1-3 illustrates. We first designed a mobile Web caching protocol -- the Extended Internet

Caching Protocol (x-ICP). The x-ICP is deployed at the edge of the Internet to deliver

Web contents from a nearby Home Proxy server if there is no performance degradation

compared to fetch them from the origin sites. The x-ICP is also responsible for giving

users a consistent look on their personalized Web pages. Moreover, we designed several

adaptive mechanisms to cope with device heterogeneity and Web content variety. We

first created the adaptive Web contents. The Partiality and Fidelity Markup Language

(PFML) is used to embed metadata into Web pages. Based on this information, the

Partiality Adaptation and Versioning Negotiation (PAVN) approaches convert cached

Web contents to different devices in the first place. We also designed client and server

side adaptive algorithm to let users express their intents automatically.


ITTP
S-.- X-ICP


Figure 1-3. General architecture for ubiquitous Web caching









Overview

Web Caching with X-ICP

We consider Web caching as an important portion of our solution because not only

Web caching is an efficient approach that has been widely used to improve current

overall Internet performance but also based on the cached Web contents, more services

can be easily provided, for example, image transformation, language translation, virus

scanning, and so forth.

Web caching is the temporary storage of Web objects for later retrieval. The

majority of cache systems are proxy caches, which are widely deployed at the department

and institute level of Local Area Networks (LANs) to benefit a group of people with the

same browsing interests.

There are many significant advantages on Web caching, especially for proxy

caching:

* Web caching reduced bandwidth consumption because fewer requests and
responses are needed to go over the network.

* Web caching reduced latency since responses for cached requests are available
immediately and are closer to the client being served [DAV01].

* Web caching increased availability by duplicating Web objects on the Internet.

* Web caching is transparently deployable and generally applicable. Transparent
deployment means that the solution must not require changes to the current
implementations on the client or the server. Generally applicable means, in the face
of the phenomenal growth of both Web contents and mobile devices, the solution
should be scalable and general enough to apply to all mobile scenarios.

These advantages make the Web less expensive and better performing.

In this dissertation, we first propose an Extended Internet Caching Protocol (x-

ICP). It is based on traditional Web caching, but allows the proxy server on the nomadic

user's newly visited network to retrieve the user profile and Web objects from the proxy









server of the user's home network. Such a scheme gives users a consistent look at Web

pages in the context of changing locations or changing devices, and decreases the

response time for the requests by fetching an object from a usually nearby home network

rather than from the origin site. To evaluate the performance of x-ICP, we use trace-based

analysis and analytic modeling methods. We draw several conclusions, all suggesting that

x-ICP would be an effective approach to solve the problems when nomadic users access

the Web in a heterogeneous environment, especially in wireless LAN environments.

In the context of content service, Web caching also plays an important role because

on the edge of the Internet, many content servers are deployed. They are either surrogates

which are near the original servers, or proxies which are close to user agents. On those

servers, many cached objects are considered as a content layer. On top of the content

layer is a service layer which provides services such as translation, transcoding, or virus

scanning. Our Partiality Adaptation and Versioning Negotiation (PAVN) is one of the

services. Taking advantage of the cached objects can make adaptation and negotiation

more efficient. For example, our adaptation allows more users, or precisely speaking,

more devices, to share the same copy of an object. This would result in a larger

community with common interests. Therefore there would be a very good hit rate, and in

turn save a lot of bandwidth and response time.

Content Service

Due to mobile device proliferation, content providers can no longer deliver only

one version of their content to the users, as they need to deliver an appropriate form of

content depending on the capabilities of the viewing devices. Web authors either create

multiple versions of the same content for each device or depend on some intermediaries

to do the transformation. Providing a suitable content and presentation for different client









devices in heterogeneous environments is becoming an important service today. But

simply adding another service layer onto the cached content layer will not work. This will

make the overloaded Internet even worse. For example, to display a low resolution

picture on a cell phone, simply downloading a very high resolution one and converting it

on the proxy close to the cell phone would waste a lot of bandwidth between proxy and

origin servers. Another example is when a PDA user is on the move, he may not want to

read the same size of the CNN page as when he is sitting in front of a desktop at home. It

is not therefore necessary to deliver a complete CNN page to a PDA user.

Content adaptation and negotiation are two major approaches to delivering a

suitable version of Web objects to mobile devices. Content adaptation usually refers to

those transcoding and distillation methods processed on a proxy near the mobile users

based on their profiles and network Quality of Service (QoS). Content negotiation, on the

other hand, is a process between the client agent and the content server. The latter stores

several variants of an object under different identifications (URL). After negotiation, an

appropriate version is identified and delivered to the user.

We modified the two previous approaches and combined them to achieve efficient

content delivery to mobile clients. We propose two new approaches to the adaptive

mobile content delivery. The first approach, called Partiality Adaptation, allows Web

authors to create one version of an XHTML page whose various parts could fit various

devices. The second approach, called Versioning Negotiation, improves the efficiency of

content negotiation by eliminating the problems from the current negotiation algorithms

based on HTTP. Current negotiation methods determine which version of the object to

send out by the servers. It requires either partial information from an HTTP header or a









device description file from a third party site. The metadata in an HTTP header would not

lead to an accurate decision to fetch device description file introduces more network

traffic and delay. On the contrary, we embed enough object information into an XHTML

page and let the user agent make the final decision on fetching which object version.

To further explore user intent and context awareness, it is also necessary to deploy

new algorithms on both client and server sides. Our automated Priority Selection

Algorithms are able to deliver suitable content to different types of devices without both

client and server's intervention. Moreover, they can further reduce Web page response

time and overall Internet bandwidth usage. Several evaluations on performance are

presented by conducting experiments on laptop, PDA, and smart phone clients on the

wireless links. All of them show a better performance than their current counterpart

solutions.

Design Philosophy, Objective, and Contribution

Our design objective is to meet the emerging demands for ubiquitous access to the

Internet with growing diversity of client devices. The complete design is based on the

philosophy "the simpler, the better."

With the protocols and algorithms designed in this dissertation, we aimed at

achieving the following goals:

* Make personal profiles follow the mobile users' movement so the users can
consistently access the Internet with their bookmarks, cookies, and so forth.

* Reduce the response time for mobile device users by fetching cached objects from
the proxy server on the home network instead of going all the way to the far end of
the Internet.

* Bridge the gap between the different variants associated with the same object,
namely one copy for devices with different capabilities. For example, by merging
both WAP and HTML pages to one, we save the time to generate different pages









on the origin server, and we lower the burden on the proxy to keep track of
different versions of the same content.

* Position Web caching of objects in a better place for content negotiation and
adaptation rather than delivering and transcoding cached copies on the fly. For
instance, by sharing the same pages with different devices, the size of the user
group will be increased, and therefore the cache hit rate would be higher, and the
bandwidth usage and response time to users would be reduced.

* Make better negotiation and adaptation by requiring no client device information.
The adaptation is based on an appropriate copy rather than a large file. This reduces
the proxy workload and saves the bandwidth between the proxy and origin server.

* Reduce user's intervention by using automated algorithms. We use programs to
automatically select the size of a Web page and the numbers of embedded objects
instead of asking users to click on the choices.

Organization Of This Dissertation

The organization of the subsequent chapters is as follows. In Chapter 2, we survey

related work, which mainly includes topics on mobile IP, Web caching, content

adaptation and negotiation. In Chapter 3, we present the architecture of x-ICP and explain

design details. In Chapter 4, we analyze and conduct the experiments on the performance

of x-ICP. In Chapter 5, we cover the design principles of PAVN, and we illustrate details

on Partiality Adaptation and its corresponding experiment. In Chapter 6, we discuss

Versioning Negotiation and concentrate on simulation which proves the performance

improvement. In Chapter 7, we summarize and suggest future research.














CHAPTER 2
RELATED RESEARCH WORK

Mobile IP

In mobile networking, computing activities are not disrupted when the user changes

the computer's point of attachment to the Internet. Instead, all the needed reconnection

occurs automatically and noninteractively. Some technologies are emerging and getting

attention. Mobile IP is one of the well-developed technologies. Under Mobile IP, users do

not have to modify their IP stack configurations manually each time they move into a

new network [CAMOO, CELXX, PER98, PER98a, VAL99]. Mobile IP also has been put

into the IPv6 suite as the next generation standard of the Internet. Part of our research is

based on this protocol.

Mobile IP has the following three main components:

1. Mobile Node
2. Home Agent
3. Foreign Agent

The Mobile Node is a device such as a cell phone, personal digital assistant, or

laptop whose software enables network roaming capabilities.

The Home Agent is a router on the home network serving as the anchor point for

communication with the Mobile Node. It tunnels packets from a device on the Internet,

called a Correspondent Node, to the roaming Mobile Node. (A tunnel is established

between the Home Agent and a reachable point for the Mobile Node in the foreign

network.)









The Foreign Agent is a router that may function as the point of attachment for the

Mobile Node when it roams to a foreign network, delivering packets from the Home

Agent to the Mobile Node.

Moreover, the care-of address is the termination point of the tunnel toward the

Mobile Node when it is on a foreign network.

The Home Agent maintains an association between the home IP address of the

Mobile Node and its care-of address, which is the current location of the Mobile Node on

the foreign or visited network [CIS01].

The Mobile IP was designed to allow the Mobile Node to use two IP addresses: a

fixed home address and a care-of address that changes at each new point of attachment.

In the Mobile IP, the home address is static and is used, for instance, to identify TCP

connections. The care-of address changes at each new point of attachment and can be

thought of as the Mobile Node's topologically significant address. It indicates the

network number and thus identifies the Mobile Node's point of attachment with respect

to the network topology. The home address makes it appear that the Mobile Node is

continually able to receive data on its home network, where Mobile IP requires the

existence of a network node known as the Home Agent. Whenever the Mobile Node is

not attached to its home network (and is therefore attached to what is termed the foreign

network), the Home Agent gets all the packets destined for the Mobile Node and arranges

to deliver them to the Mobile Node's current point of attachment. Figure 2-1 indicates the

routes of IP packets.

Mobile IP is best understood as the cooperation of three separable mechanisms:










Discovering the care-of address;
Registering the care-of address;
Tunneling to the care-of address. [PER98]


Src Dest.
CN I Mv Paylcad
Header
Original IP packet


Header
HA COo


Paylcad

OEncginal IP Packet

Encapsulated IP Packet


TUNNEL


Src Dest.
|C MN Paylcad
Header
Original IP Packet
(decapsulated)


Figure 2-1.In Mobile IP protocol, IP in IP encapsulation is implemented to forward
packets from the Home Agent to the Foreign Agent.




Three Hierarchy of Web Caching

On the wired network, Web caching has been generally recognized as an effective

approach to solve the long round-trip propagation delays brought by the growth of the

Internet [BAROO, DAV99, WAN99]. This straightforward idea employs intermediate

servers to act as proxies to temporarily store some Web objects and serve the nomadic

user's requests.


1










On some networks, one caching server might not be enough because of the size of

the network, performance, and availability requirements. Two or more caching servers in

such a network can serve more users in the expected response time and provide load

balancing and fault tolerance. Several servers that work together to provide efficient and

reliable Web caching form a cache cluster. Figure 2-2 shows a logic diagram of a two-

layer cache hierarchy.

Currently, there are three main existing approaches on proxy Web caching,

including broadcast probe, exemplified by Harvest and Squid, hash-partitioning of the

object namespace among caches, such as Caching Array Protocol (CARP), and a

directory service first proposed in Caching and Replication for Internet Service

Performance (CRISP).





Wab Server






Proxy P ,r .'







Prxy Proxy Proxy






Browser
Figure 2-2. A two-layer caching hierarchy.









The Caching Array Protocol uses a deterministic request resolution path to quickly

locate and route a request to the caching server that contains the requested object without

querying between servers in the cache cluster [ZHO99]. The CARP does not duplicate

cached objects in multiple servers and therefore saves caching space in the cluster or

array, and it uses hash-based functions to reach this optimization.

A CRISP cache consists of a set of caching servers (proxies), which directly field

requests from clients/browsers, and a mapping service, which is responsible for

maintaining the global directory of objects stored in the caching servers. On a local cache

miss, each caching server queries the mapping service to determine if the object is

resident elsewhere in the collective cache. If the mapping service reports a hit, then the

object is fetched directly from the peer caching server. Caching servers keep the global

directory current by reporting object fetches and evictions to the mapping service.


Figure 2-3. The hierarchy of Internet Caching Protocol (ICP).


Direct
Retrievals









The Harvest research project on Internet caching at the University of Southern

California developed ICP in 1996. The ICP is an Internet standard as set forth in Internet

Engineering Task Force (IETF) Request for Comments RFC 2186 and RFC 2187. The

ICP works in a straightforward way. It is a lightweight message format used for

communicating among Web caches. The ICP is used to exchange hints about the

existence of URLs in neighbor caches. Caches exchange ICP queries and replies to

gather information for use in selecting the most appropriate location from which to

retrieve an object. Figure 2-3 shows the hierarchy of ICP.

The basic sequence of events in an ICP transaction is as follows:

1. Local cache receives an HTTP request from a cache client.

2. The local cache sends ICP queries.

3. The peer cache(s) receives the queries and sends ICP replies.

4. The local cache receives the ICP replies and decides where to forward the request.

Service Discovery

Service discovery protocols provide mechanisms for dynamically discovering

available services in a network and for providing the necessary information to:

* Search and browse for services
* Choose the right service (with desired characteristics)
* Utilize the service

Among the well-known contenders, Universal Plug and Play (www.upnp.org), Jini

(www.jini.org), and Salutation (www.salutation.org) architectures are prominent, coming

primarily from the industry.

The Service Location Protocol (SLP) is a product of the Service Location Protocol

Working Group (SVRLOC) of the Internet Engineering Task Force (IETF) [PER97,

VEI97]. It is a protocol for automatic resource discovery on Internet Protocol-based










networks. The SLP is a language independent protocol. Thus the protocol specification

can be implemented in any language. The SLP bases its discovery mechanism on service

attributes, which are essentially different ways of describing a service. It can cater to both

hardware and software forms of services.

The SLP infrastructure consists of three types of agents:

* User Agents
* Service Agents
* Directory Agents

The User Agents acquire service handles for end-user applications that request the

services. The Service Agents are responsible for advertising service handles to the

Directory Agents thus making services available to the User Agents. Figure 2-4 shows

the interaction between these three agents.




Service Service
Discovery Registration
and Update
Dire or gent








User Agent
Service Agent

Figure 2-4. SLP agents and their transactions for service discovery and registration.


Jini is a service discovery architecture based on Java. It is a distributed service-

oriented architecture developed by Sun Microsystems [REK99]. Jini services can

represent hardware devices, software programs, or a combination of the two. A collection









of Jini services forms a Jini federation. Jini services coordinate with each other within the

federation. The overall goal of Jini is to turn the network into a flexible, easily

administered tool on which human and computational clients can find services in a

flexible and robust fashion. Jini is designed to make the network a more dynamic entity

that better reflects the dynamic nature of the work group by enabling the ability to add

and delete services flexibly.

The Universal Plug and Play (UPnP), pushed primarily by Microsoft, is an

evolving architecture designed to extend the original Microsoft Plug and Play peripheral

model to a highly dynamic world of many network devices supplied by many vendors

[MICOO]. The UPnP works primarily at lower layer network protocol suites (that is,

TCP/IP), implementing standards at this level. The UPnP attempts to ensure that all

device manufacturers can quickly adhere to the proposed standard without major hassles.

By providing a set of defined network protocols, the UPnP allows devices to build their

own Application Programming Interfaces that implement these protocols in whatever

language or platform they choose.

The Salutation coordination framework seems to be a more rigorous and useful

framework from a coordination perspective than either Jini or UPnP. It seems to have

drawn more from research on intelligent agents than other frameworks mentioned here.

Salutation trods a middle way between device autonomy and standardization. In

Salutation, a device almost always talks directly to a Salutation Manager, which may be

in the same device or located remotely. What we see is an ensemble of Salutation

Managers (SLMs) that coordinate with one another. They act like agents that do

everything on behalf of their clients. All registration is done with the local or nearest









available SLM. The SLMs discover other nearby SLMs and exchange registration

information, even with those on different transport media.

Content Adaptation and Negotiation

Regarding Web contents, Internet content publishers do not have many options for

customizing the content. In some cases, the publishers manually generate secondary, text-

only versions of Web pages that the users can select instead of the originals. This is

known as content negotiation. Another mechanism is called content adaptation,

transcoding, or distillation. Basically, this mechanism changes the content based on

network QoS, device information, or user intention, and it usually happens on a proxy

server. Both of these methods require more or less information about devices and

contents.

Device Description

There are many ways to describe device capabilities, such as HTTP Request

Header Fields, CC/PP, WAP UAPROF, SyncML [BUT01, LEM02].

Typically, CC/PP stands for Composite Capabilities/Preferences Profiles. It is a

way to specify what exactly a user agent (Web browser) is capable of doing. The CC/PP

describes and manages software and hardware profiles that include: information on the

user agent's capabilities (physical and programmatic); the user's specified preferences

within the user agent's set of options; and specific qualities about the user agent that can

affect content processing and display, such as physical location. The CC/PP is designed

to work with a wide variety of Web-enabled devices, from PDAs to desktop machines to

laptops to WAP phones to phone browsers to Web television units to specialized

browsers for users with disabilities. Proxies may also be used to provide markup









transformation, transmission, or caching services for CC/PP-enabled clients and servers

[CCP99].

All the methods have advantages and disadvantages. For example, the HTTP

request headers are too simple to describe a mobile device's capabilities and user's

preference, whereas CC/PP is too complex. The WAP UAPROF is not compatible with

HTTP.

Content Adaptation

With the help of device description, content adaptation is an approach being widely

adopted to solve heterogeneous device problems. There are many publications on content

adaptation. Smith et al. [SMI98] suggest manipulating Web contents in two dimensions:

fidelity and modality. Knutsson et al. [KNU02] proposed an idea on server-directed

transcoding which preserves HTTP end-to-end semantics. Chi et al. [CHI02]. gave a

solution on image processing which can generate a higher resolution JPEG based on the

previous low-resolution version. Shi et al. [SHI01] present a novel architecture to support

caching of dynamic personalized content for mobile users. There are also other similar

approaches, including AvantGo, Web Clipping, ASP+.NET, PHP HawHaw Library, and

XHTM/CSS [BUT01].

Adaptation is most likely to be deployed on the Internet edge such as transcoding,

translation, and so forth. The main drawback of this approach is that it breaks various

"end-to-end" HTTP properties which applications rely on. For example, many wireless

gateways can transcode the original HTML page to a WML page so it can be displayed

on a WAP browser. But complicated Web pages can make the heuristic algorithm on the

intermediary difficult to apply. Also, the transformation may be against the Web authors'

intention.









Content Negotiation

Another different approach is content negotiation. The HTTP allows Web site

authors to put multiple versions (variants) of the same information under a single URL.

Web servers can choose the best representation of a resource based on the browser-

supplied preferences for media type, languages, character set, and encoding. To enable

content negotiation, the variant list of the resource is usually kept as a file on the Web

server for later use. The list can also be retrieved from the file and sent out in the HTTP

alternates headers.

Three types of content negotiation mechanisms exist:

1. Server-driven negotiation

2. Agent-driven negotiation

3. A combination known as transparent negotiation

But none of these mechanisms gives a satisfying solution in terms of making decisions on

the "best" copy. With server-driven negotiation, it is hard to determine the "best" version

because servers usually do not have the complete user's information. The major

drawback of agent-driven negotiation is that it introduces one more round-trip time to

fetch the variant list [HOL98a]. The transparent negotiation is clearly defined and

described in [HOL98]. Regarding the optimal transparent content negotiation, the variant

file can be kept on a Web caching server to help the intermediary make the final decision

because it usually knows the user better than the origin server. Although this transparent

negotiation takes advantage of the cached variant list, variant properties, and Web

contents, the final decision is still made by the proxy server. It is similar to letting a

waiter decide the complete order for a customer in a restaurant, instead of letting









customer make the decision himself. Figure 2-5 illustrates these three scenarios plus the

versioning negotiation.


Origin
Server


Client


Origin
Server


Client


Variant selection
based on variant
list and CC/PP


Container Page Req


Container Page Res

Embedded obj.
req. with Accept
Headers
selected Obj.





Server-driven Negotiation


Cache
Server


Variant selection
based on variant
list, properties and
accept headers


Client


Container Page Req


Container Page Res

Embedded obj
req. with Accepi
SHeaders
selected Obj.


Transparent Negotiation


Container Page Req


Container Page Res

Embedded obj. req.

variant list
nObj. URI ofa Variant selection
Obj. URI of a
S based on variant
specific version
specic list and client info.


selected Obj.

Agent-driven Negotiation


Cache
Server Client

Container Page Req

Variant selection
Container Page Res based on variant
list, properties and
client info.
Embedded obj. req.


selected Obj.


Versioning Negotiation


Figure 2-5. Content negotiation solutions. (Regarding the left two graphs, negotiation
decisions are made on servers. The right two graphs show that clients make
the negotiation decision. But the upper right graph takes three round-trips,
whereas the bottom right one takes two. On the top two graphs, pages are
returned from origin servers whereas at the bottom two, the caching server can
satisfy the request.)









At last, the HTTP Remote Variant Selection Algorithm (RVSA) is an important

part of the transparent negotiation [HOL98a]. An RVSA can be used by an HTTP server

to choose the best variant on behalf of a negotiating user agent. The use of a remote

algorithm can speed up the transparent negotiation process by eliminating a request-

response round-trip.

Web Page Partition

To break a Web page (a container page and its embedded links) into several

fragments is not a brand-new idea. It was first applied to those dynamic-generated Web

objects. In [DOU97, ESIXX], the static contents of a Web page are cached separately

from the dynamic parts. Chi et al. [CHI02a] proposed an XML-based mechanism to

validate different fragments of a Web page in order to preserve data integrity.














CHAPTER 3
ARCHITECTURE OF EXTENDED INTERNET CACHING PROTOCOL

Overview of X-ICP Architecture

In a mobile network, the movement of nomadic users presents significant technical

challenges to provide efficient access to the Internet. For a given individual nomadic

user, his location will vary from time to time, and he usually has more than one device to

access the Internet. Imagine these three scenarios: First, people today are using

workstations in the office, PCs at home, laptops, PDAs, and cellular phones everywhere

to surf online. The experience is bad when the device is changed or when the user uses a

public device. Bookmarks, address books, cookies, and link histories are all gone. People

have to synchronize their devices from time to time. Second, the Computer Engineering

(CE) Department and the Health Department of a university are working together to use

wireless sensors to help the elderly. Some CE students need to stay in the Health

Department for some time to acquire health knowledge while doing wireless research.

Third, the most common movement for a student can be considered as going between

school and home. When a student goes back home and wants to do some homework, the

best place to start is his department proxy server where huge amounts of related pages

and documents are already visited and downloaded by the instructors and other students.

But for nomadic users, the proxy caching servers do not work efficiently because the

request is not necessarily en route from the Home Proxy server where many previously

downloaded contents are stored. It is therefore imperative to take into account dynamic

nomadic behavior in designing a Web caching system.









In this chapter, we introduce a newly integrated caching model, Extended Internet

Caching Protocol (x-ICP), to benefit nomadic users. The main functionality of x-ICP is to

connect the Foreign Proxy with the Home Proxy. So when a user moves, the Foreign

Proxy can fetch the user's profile automatically. It also deals with the decreased cache hit

rate on the Foreign Proxy server when a user attaches to a new network. The x-ICP is

based on the Mobile IP protocol, which has been widely discussed as a network solution

to mobility. But the design of Mobile IP makes the current caching system hard to adapt

to nomadic users. The x-ICP provides an opportunity to combat this problem by allowing

the proxy server of the nomadic user's newly attached network (Foreign Proxy) to fetch a

copy from a usually nearby Home Proxy server. Figure 3-1 depicts this idea.


SE- Cache Exchange
Motion
Connecfan




SZInternet












Figure 3-1. The x-ICP is deployed on the proxy servers belonging to the different
networks. When PDAs or laptops are away from home, they can download copies of Web
objects from the Home Proxy.

Before we go any further, we need to ask a fundamental question. Why do we

extend ICP in particular? Why not extend other inter-caching protocols, for example









CARP or CRISP? This is because the latter two infrastructures require predefined

domains. In CARP, there are a cluster of proxy servers. Each of them is in charge of a

range of URLs which is determined by a harsh function. In CRISP, all the proxy servers

belonging to the same domain need to register their cached objects with a center agent.

But the uncertainty feature of nomadic users makes it hard to predict which proxy servers

should be grouped together at the proxy setup time, and there is much overhead to add

and remove a proxy into or from the domain. Therefore, using short ICP messages to

exchange caching information between the Foreign Proxy and Home Proxy is an

effective way.

Another reason to extend ICP is because it is a lightweight protocol. The ICP

message format consists of a 20-octet fixed header plus a variable sized payload. In

current practice, it is implemented on top of UDP. An ICP query/reply exchange was

designed to occur quickly, typically within a second or two.

The x-ICP is based on Mobile IP. Although Mobile IP brings significant

conveniences for nomadic users, there are still some unavoidable problems with it since it

changed the underlying infrastructure of current application level protocols. One of

problems is that the triangle routing of Mobile IP completely bypasses the Home Proxy

server where many Web objects were cached during previous Web accesses. When a

nomadic node moves to a new location, the user will send out an HTTP request, which is

processed only by the Foreign Proxy. If there does not exist any cached copy locally, the

request will be forwarded to the Web server at the far end of the Internet. But it is very

likely a copy of the requested object is residing on the Home Proxy, which is usually

nearby. The single-arrow line in Figure 3-2 shows the triangle routing of Mobile IP, and










the solid double-arrow line indicates how we can take advantage of those copies closer to

us. Certainly the proxy servers mentioned here are those very close to the users, such as

the department proxy in a university. Compared to the higher level proxy in a caching

hierarchy, these proxy servers store many objects concentrated on a relatively small

browsing interest to cater to a small community. One of the functionalities of x-ICP is

that the request will be forwarded to the Home Proxy server first, when a cache miss

occurs on the Foreign Proxy. If it is still a miss, it then goes to the origin site.

Home Proxy

Internet
Home Host
Network
x-ICP








Foreign Proxy



Foreign
Network

Mobile Client

Figure 3-2. Applying x-ICP to Mobile IP's triangle routing.

More improvements have been made on ICP toward x-ICP. For instance, current

shared cache architectures face a dilemma. On the one hand, the hierarchies wish to

group as many proxy servers among a large number of clients as possible to achieve the

best hit rates. On the other hand, as more proxy servers are involved to service more










Table 3-1. Comparison between Mobile IP and X-ICP
Mobile IP X-ICP
Discovery Home agents and foreign agents Proxy server agents advertise their
may advertise their availability services on their own links. A
on each link for which they newly arrived nomadic node can
provide service. A newly arrived retrieve service information from
nomadic node can send a either the Service Agents or
solicitation on the link to learn if Directory Agents by Service
any prospective agents are Location Protocol (SLP).
present.

Registration/ When the nomadic node is away When the nomadic node arrives at
Configuration from home, it registers its care- the new location, the configuration
of address with its Home Agent file of the Foreign Proxy server is
either directly or through a modified to group the Foreign
Foreign Agent, which forwards Proxy server with its Home Proxy
the registration to the Home server. Furthermore, the Foreign
Agent. Proxy would fetch the user's
profile if it is out of date. For each
user, two lists are created to
maintain the corresponding objects
information.

Delivery In order for datagrams to be When a cache miss happens
delivered to the nomadic node locally, the Foreign Proxy server
when it is away from home, the forwards the request to the
Home Agent has to tunnel the corresponding Home Proxy server
datagrams to the care-of address. first with ICP message. If it is still
a cache miss, then to the origin
server.

Duplication N/A It is the Foreign Proxy's
responsibility to monitor the status
of each nomadic node. When a
node leaves, the Foreign Proxy
needs to send the modified profile
to the node's Home Proxy and the
visited URL list back to its Home
Proxy. The Home Proxy then
decides which ones to fetch and
store them on the local disk.









clients, the response time they provide to any one client worsens due to the complex

hierarchy [TEW99]. In x-ICP, such a problem does not exist. There are no siblings and

parent in our design. The Foreign Proxy will contact only with the Home Proxy where a

great number of objects were previously downloaded by the same user. This will result in

a relatively high hit rate compared to visiting other proxy servers. Moreover, because of

no broadcasting, the Internet traffic is reduced and response time is shortened since there

is no need to wait for the slowest response from all probed nodes.


Mobile IP versus X-ICP

In this section, we will address the similarities and differences between Mobile IP

and x-ICP. Analogous to Mobile IP [PER98a], the main processing procedures of x-ICP

can be divided into four major steps:

* Proxy Service Discovery,
* Sibling Proxy Server Configuration
* Web Page Delivery
* Cache Duplication

Details are illustrated in Table 1:

Design Details of X-ICP

X-ICP modules

Before talking about the procedures for how an HTTP request is satisfied by the

Foreign Proxy when x-ICP is deployed, we need to introduce two new modules on the

proxy server, Node Monitor and Cache Copier, as Figure 3-3 shows.

The Node Monitor Module is responsible for maintaining several lists when a

proxy server functions as a Foreign Proxy. One of the lists is a foreign user list. Those

users, who temporarily reside on this network, are on this list. First, when a nomadic user

attaches to a foreign network, the proxy service discovery takes place. Second, the user









agent registers with the Node Monitor of the discovered proxy, that is, to create a new

node on the user list with the user's ID. The ID could be either the care-of address of the

nomadic user or the IP address on the user's home network. Another data structure is the

object list. Each user has a corresponding list. All the URLs requested by the user, which

are either cached locally or fetched from origin servers, are inserted into that list; namely,

the objects fetched from the Home Proxy are not on the list. This is simply

Proxy
Server


Side Storage Client
To Web Process Manager Side From Client






Node Cache
Exchange Monitor Copier Exchange with
with other other Node
cache Monitors
corner


Figure 3-3. Modules on proxy server with x-ICP being deployed.

because these objects would be sent back to the Home Proxy when the user leaves, and

those already on the Home Proxy are not necessary to be sent back later on. Having

detected the user's departure, the Node Monitor sends over the corresponding list of

URLs to the Cache Copier module on the user's Home Proxy. Figure 3-4 gives the

overview of the two lists.

The Cache Copier is an active module on the user's Home Proxy, whereas the

Node Monitor functions when the proxy server is considered as a Foreign Proxy. First of

all, security is an important issue when retrieving objects from a third party site. The










Cache Copier needs to authenticate the list before fetching the objects. This can be done

by encrypting messages with the secret key carried by a mobile user. Second, for each

object on the list sent over from any Foreign Proxy, the Home Proxy checks whether

those objects are already stored. If yes, the nodes of the cached objects are removed from

its object list. Third, the Cache Copier also looks up the expiration time of those cached

objects, if the difference of expiration time (Te) and current time (Tc) is less than the sum

of three values: the processing time on both ends: Cache Copier and Node Monitor (Tp),




Foreign User 1 URL 1 URL 2 -- URL n





Foreign Foreign User 2 URL 1 URL 2 URL
User
List
I




Foreign User n URL 1 URL 2 -- URL n


Object Lists




Figure 3-4.Data structures on the Node Monitor. There are two lists here: one list is the
foreign user list to keep track of the mobile users; the other list is the object
list for each user.

the round trip time to fetch the copy (Tt) and a small threshold value S, then this URL

node would be removed from the object list. Simply, the object would be fetched if

Te Tc < Tp + Tt + S









This would help the Home Proxy to download a frequently visited object from a

closer proxy server instead of the often far away origin server. Fourth, the QoS of

network, like the availability of network bandwidth, will be used to decide whether to

download the objects from the Foreign Proxy.

Processing Procedures of X-ICP

Proxy service discovery

When proxy services are needed to be accessed from a wireless device, a new

domain of research and challenging problems come into the picture. Finding a service

efficiently becomes important. This is a broad research area, and we talk about Service

Location Protocol (SLP) briefly here.

Many features make SLP a good choice for our proxy service discovery model.

First, traditionally, users find services by using the name of a network host (a human

readable text string), which is an alias for a network address. The Service Location

Protocol eliminates the need for a user to know the name of a network host supporting a

service in advance. The user instead names the service and supplies a set of attributes

which describe the service. The Service Location Protocol allows the user to bind this

description to the network address of the service, and it provides a dynamic configuration

mechanism for applications in local area networks. Second, it is not a global resolution

system for the entire Internet; it is instead intended to serve enterprise networks with

shared services. Applications are modeled as clients need to find servers attached to the

enterprise network at a possibly distant location. For cases where there are many

different clients and/or services available, the protocol is adapted to make use of nearby

Directory Agents that offer a centralized repository for advertised services. For example,

the proxy server can run a service agent program to broadcast its service to its network or









bit can register with a Directory Agent to be retrieved later by other agents. Third, unlike

Jini, it is programming language independent.

In x-ICP, when a user attaches to the new network, the user agent sends out the

inquiries to look for a nearby proxy server. Having received the reply, the user agent

modifies the settings of its own browser to point to the new proxy, and a request to use x-

ICP to group the discovered proxy and its Home Proxy is sent out to both proxy servers.

The new proxy reconfiguration and registration take place next.

Sibling proxy configuration and registration

Sibling proxy configuration. Standard ICP is modified to adapt to our sibling

proxy configuration process. In ICP v2, configuring caches within a hierarchy requires

establishing peering or parent relationships, which currently involves manual

configuration at both ends. One caching server must indicate that the other is a parent or

sibling. The other cache adds the first cache to its access control lists correspondingly,

like a child or sibling.

In x-ICP, when a nomadic node moves to a new location and discovers a new

proxy server, the configuration file of the Foreign Proxy is modified and the accessing

list of the node's Home Proxy is updated. Given the scenario in Figure 3-5, we will show

how the configuration procedures work.

A nomadic node M was originally connected to the "Netl", then attached to the

"Net2". The "Proxy4" is considered as its Home Proxy and the "ProxyE" is the Foreign

Proxy. Having attached to the "Net2", node M inserts the following line into the

configuration file of"ProxyE" as ICP required:

cache host Proxy4.Netl sibling HTTP-port icp-port.









"Cachehost" is the defined directive from ICP. Proxy4.Netl is the host name or IP

address of the Home Proxy server. The word "sibling" indicates the relationship between

"Proxy4" and "ProxyE". Unlike ICP, there are no other relationships, like parent or

Proxy 4
1 M 2 3




Net
S] Internet

Net2




A B C D M PrxyE
Figure 3- 5. A nomadic node M moves from Netl to Net2.

multicast, in x-ICP. In the meantime, "Proxy4" is notified by Node M to update its access

list as follows:

* acl src ProxyE ProxyE.Net2
* HTTP_access allow ProxyE
* ICP_access allow ProxyE

The first line above defines an access control entry named as "ProxyE" which specifies a

source IP address of the proxy machine on Net2. The next two lines indicates which

protocols can be used. In this case, the caching server on Net2 would then be allowed to

make any request to both the HTTP and ICP ports. This implementation is the same as

that on Squid proxy servers except the configuration file is modified by nomadic nodes

dynamically.

Security Issues. Security needs to be carefully considered when the configuration

is being updated. First, we assume that strong authentication mechanisms have been









implemented by the Mobile IP. Second, we put more information on the entry list to

secure our protocol because we are opening a door here to malicious hackers if the above

implementations are used. For example, if someone puts an entry onto your list, saying

look at his server as a sibling, and the server always satisfies the requests by returning

irrelevant pages. This is dangerous. To prevent this from happening, we insert more

information into the entry on the Foreign Proxy server. Regarding the same case

presented in Figure 3-5, an entry is shown with one more constraint in bold:

cache host Proxy4.Netl sibling HTTP-port icp-port care-ofaddress

When Node M moves to Net2 and makes a request to register, the Foreign Proxy server

also appends node M's care-of address to the entry. Next time, when an HTTP request

comes in and if it is a cache miss, the proxy server looks up the caching list with the

sender's care-of address. If there is a match, it forwards the requests to the corresponding

Home Proxy server. Thus, no one can redirect other Mobile Nodes' requests.

The security problem of updating the Home Proxy's access list, when the Mobile

Node is away from home, can be easily solved with the secret key carried over by the

node and reconfiguration request is encrypted with the key.

Register with Node Monitor. One more task that needs to be done is to register

with the Node Monitor, which maintains a foreign node list on each proxy server. Having

updated Access Control List (ACL), the monitor adds an entry to the list. The entry

consists of three parts. The first part is the Mobile Node's ID. The second part is the host

name or IP address of its Home Proxy server. In the above case, the entry is like

"M.Netl, Proxy4.Netl". And third, the Node Monitor creates a corresponding empty

object list for the node for later object retrieval.









Hops Detection. Deploying x-ICP on different networks can bring more overhead

than expected. The ICP v2 was designed to group the proxy servers on the intranet, which

assumes they are not far away from each other. But the behavior of a Mobile Node is

unpredictable so its new attachment point to the Internet might be too many hops away

from its home network. By the time the IP v4 is implemented, the diameter of the Internet

is about 30 hops, according to statistical data [TRE93]. The Internet's unbroken growth

and recent fundamental topology changes within the international backbone make the

maximum hop counted to 40, which can be currently observed in the worst case [TTLxx].

It is very likely the Mobile Node has the same distance from the Home Proxy server as

from the original Web server when it is away from home.

Before a Mobile Node decides to fetch a copy from its Home Proxy server, it needs

to estimate how many hops it is away from the home network. An easy way to do so is to

use the "traceroute" algorithm [SMIOO].

Having obtained the number of hops away from the home network, the Mobile

Node can decide whether to contact the Home Proxy every time when a cache miss

happens locally. Given that the diameter of the current Web is 40 hops, if the number of

hops is less than some threshold which is less than 40, the Mobile Node could try to fetch

objects from the Home Proxy first, otherwise, the origin site would be contacted directly.

Knowing the hops, it also helps to set the TTL value in the ICP query so that the whole

system can work in a more efficient way which eliminates the routing loops. Our

experiments show some results which can be referred to as the threshold to determine

whether or not to fetch from the Home Proxy.









User profile delivery. Having finished the configuration, the mobile user agent

sends out a request to the Home Proxy to ask the latest profile version number. If the

current mobile device has been offline for a while and the version number is older than

the requested one, then the latest user's profile is fetched includes bookmarks, cookies,

history links, contact information, and so forth.

The Foreign Proxy simply maintains a copy of the profile, monitors the updates on

those profile items, and modifies them periodically.

General Web Object Delivery

When a nomadic user makes a request via the Foreign Proxy, the Storage Manager

of the proxy first checks the local caching storage. If it is a cache hit, the object will be

returned directly, and the URL of the object will be inserted into the object list of that

user. If it is a cache miss, the Foreign Proxy will forward the request to the Home Proxy

first, if still a miss, then to the origin site. When the object is from the origin site, the

URL of the object will be inserted into the user's object list. This way all the URLs of

requested objects, excluding those downloaded from the Home Proxy, are on the object

list.

Unlike the way in which traditional Web caching deals with a cache miss, x-ICP

sets up an extra round-trip between the Home Proxy and Foreign Proxy. Therefore, if the

cache misses on the Home Proxy take a significant percentage of total forwarded requests

from Foreign Proxy, the system performance will be degraded. On the other hand, if the

cache hit rates on the Home Proxy is high and the Home Proxy is closer to the Foreign

Proxy than the origin site, we could improve the system performance. Namely, if we

could retrieve many objects from a nearby proxy, we save some amount of time Tsave

than downloading them from origin sites. If the requests forwarded to the Home Proxy









are cache misses, we waste some amount of time Twaste. Thus if we are able to achieve

Tsave > Twaste, the x-ICP is an efficient protocol. In the next chapter, we will discuss in

what circumstances, the x-ICP improves the network performance.

Profile Update and Cache Duplication

The user's profile is updated when the user leaves. When the Foreign Proxy detects

that a mobile user leaves and some changes have been made on the profile, the Foreign

Proxy increments the version number and sends it back to its Home Proxy for

synchronization purpose.

The goal of Cache Duplication is to copy the cached objects of a nomadic user

from the Foreign Proxy to the Home Proxy when the user leaves the foreign network. The

Node Monitor on the Foreign Proxy and the Cache Copier on the Home Proxy cooperate

with each other to accomplish this task. When the Node Monitor detects the nomad's

departure from the local network, it begins to negotiate with the Home Proxy of the node.

It removes the URLs of expired objects, and the links will be expired soon. The Node

Monitor then sends the remaining object list to the Cache Copier of the Home Proxy. The

Cache Copier asks its local Storage Manager to see whether any objects on the list are

cached locally and removes them. Thus the Cache Copier makes a shortened URL list

and sends it back to the Node Monitor of the Foreign Proxy. With the updated list, the

Node Monitor is able to send out the objects accordingly, and the Cache Copier receives

and stores them on the local disk of the Home Proxy.

Having done so, the Node Monitor also deletes the entry of the go-away node from

the Foreign Node list. And the whole list is checked thoroughly. If no other nodes are

sharing the Home Proxy on the list, the corresponding "cache-host" line will also be

removed from the configure file of this proxy.














CHAPTER 4
SIMULATION AND ANALYSIS

To gain some insight into the efficiency of x- ICP, we conducted some analyses by

examining the trace logs collected by a proxy server at the Computer and Information

Science and Engineering Department of the University of Florida. The proxy server

identified some characteristics of collective user access patterns that were transformed

into the foundation of x-ICP.

Trace Collection and Characteristics

This section poses and answers a number of questions about the potential

performance of x-ICP. We will explore the bounds of x-ICP. Key questions include:

What cache hit rates could effectively decrease document access latency?
What is the best speedup x-ICP could achieve?
For what range of distances can x-ICP work effectively?

Table 4-1. Objects Distribution per Day on the Different CISE Sub-networks
Sub-net#1 Sub-net# 2 Sub-net# 3 Sub-net# 4 Sub-net# 5 All others

Objects/day 420 2307 6960 7280 23535 426



To answer these questions quantitatively, we have collected and analyzed Web

access data from two environments. First, we present our observations on the traces of

user requests collected by a proxy server at the CISE Department during the period

October 29, 2001 to November 19, 2001. On average, there are 40,199 accesses every

day from more than five sub-networks. Table 4-1 shows the request distribution from the

different sub-networks and the corresponding population, which is in proportion to the









number of requests. We selected three of them (Sub-net# 1,3,5) with a different number

of requests and ran the simulation separately to test the hit rate on the Home Proxy.

Second, we present the result of a 19-day NLANR trace [WES02]. The data are

collected on one of their 10 proxy servers, named "startap" from February 24, 2002 to

March 14, 2002. The feature of the root node in a caching hierarchy made it less useful

for our analyses, but it helped us to obtain comparable results.

Simulation Methodology

The results presented in this section are based on Web caching simulations using

our trace data as input. We installed the Squid proxy servers (version 2.4) on two UNIX

machines, and configured them as sibling. The proxy directly answering clients' requests

is considered as the Foreign Proxy and the other is the Home Proxy. In analyzing the

cache behavior of these traces, we use the first three days of each trace to warm up our

Home Proxy caches before gathering statistics. Whether the object is cacheable or not is

judged by the Squid proxy servers, and which objects are to be replaced are also taken

care of by Squid.

These traces have two primary limitations that affect our results. First, we assume

the user linger time on the new location is one day long. Second, each time we start a new

day simulation, the cache on the Foreign Proxy is set empty because currently no

research has been conducted on what kind of Foreign Proxy the nomadic user is likely to

attach to. Therefore, the compulsory misses on the Foreign Proxy should be higher than

that in reality.

To quantify the overall performance of the system and examine the impact of x-ICP,

Figure 4-1 shows both the Home Proxy hit rates and Foreign Proxy hit rates in a 20-day

trace. The bars are labeled on the x-axis with days. The lower portion of each bar shows









the hit rate that would be seen by a local Foreign Proxy acting on behalf of the nomadic

user's new attachment point. The upper portion of the bar shows the improvement in hit

rate that would be seen by the nomadic user using x-ICP. Those cache hits are from the

user's Home Proxy. In (a), for the Foreign Proxy bars, the average hit rate is 12.9%

ranging from 0% to 29.1%. For the Home Proxy bars, the average hit rate is 22.1%

ranging from 1.2% to 39.9%. In (b), for the Foreign Proxy bars, the average hit rate is

23.2% ranging from 9.1% to 72.6%. For the Home Proxy bars, the average hit rate is

19.8% ranging from 8.0% to 37.7%. In (c), for the Foreign Proxy bars, the average hit

rate is 32.1% ranging from 9.4% to 67.0%. For the Home Proxy bars, the average hit rate

is 16.7% ranging from 11.3% to 27.4%. In (d), for the Foreign Proxy bars, the average hit

rate is 36.1% ranging from 16.9% to 64.7%. For the Home Proxy bars, the average hit

rate is 12.2% ranging from 2.9% to 26.7%.

From the above data, the Foreign and Home Proxy hit rates changed when different

networks were tested. Actually, beyond that, the population and the number of requests of

each sub-network play an important role. We briefly discuss this result here, and the

details can be found in [WOL99] to explain the relationship between the hit rate and



CN = dxC = f (1)
f Cx uCx" 1+/CX


population. Equation (1) summarizes the key formula from Wolman et al. yielding CN,

the aggregate object hit rate for a population N, where n denotes the number of requests.

Thus, the hit rate is HN = pcCN, where pc is the probability that a requested document is

cacheable. The Wolman model makes several assumptions: (1) object popularity follows

a Zipf-like distribution; (2) object popularity is uniform across the population; (3) objects









are cacheable with probability pc independent of popularity; and (4) inter-arrival times for

object requests and updates are exponentially distributed with a parameter determined by

the object's popularity [GADOO]. All these assumptions are fit for our nomadic

environment so that we are able take advantage of their conclusion. In short, the bigger


0.7
0.6
0.5
0.4
0.3
0.2
0.1


1 3 5 7 9 11 13 15 17
Day


(a) Data collected on Sub-net#1 of CISE proxy log


0.9
i' it5 i'
0 .8 i .., i ,.. '---- -_
0.7
0.6
.2 0.5

1 0.3
0.2 -
0.1

1 2 3 4 5 6 7 8 9 10111213 1415161718
Day

(b) Data collected on Sub-net#3 of CISE proxy log

Figure 4-1 Home Proxy and Foreign Proxy hit rates of the traces examined in this study.


Home Proxy
Foreign Proxy





-niin~
- fl 11J.













0.9
0.8
0.7
0.6
. 0.5
, 0.4
I 0.3
0.2
0.1
0


M Home Proxy
] Foreign Proxy


-









'- co LO 0 '-- CO LO -D

Day


(c) Data collected on Sub-net#5 of CISE proxy log




0.8

0.7 I3

0.6

0.5
.2
S0.4 -

0.3

0.2

0.1

0
Sco LnU N- 0) -O -Ln -- -)

Day


(d) Data collected on NLANR startap proxy log


Figure 4-1. Continued.



population the proxy serves, the higher the local hit rate is. According to [GOL98,


BAROO], the hit rate at a proxy is almost fixed, therefore the higher the local hit rate is,


the lower it is on the Home Proxy.


-
-









Since we are more interested in the behaviors of an individual or a group of

nomadic users of fairly small number, we believe that the data collected from the Sub-

net# 1 and 3 are more likely to match our criteria. We eliminated the data from Sub-net#5

because the requests from it took up half of the total requests of the entire department,

which includes hundreds of students and faculty members. The NLANR trace shows the

smallest Home Proxy hit rate, which is about 12.2%, because it is one of the ten root

caches of the nationwide caching hierarchy system. This system can be considered to be

serving a very large population, and it results in the very low hit rate. So we choose not to

adopt its value either.

Therefore, we calculate the average of the Home Proxy Hit Rates on Sub-net#1 and

3, which is 21%. In summary, if the x-ICP protocol is deployed, it would achieve a

noticeable improvement on hit rate for nomadic users. Based on this hit rate, we will

further explore how the x-ICP benefits nomadic users.

Bandwidth Savings

One of the most important issues on Web caching is to save bandwidth. During the

simulation, we also collected the number of bytes downloaded from both the origin sites

and the Home Proxy.

As Figure 4-2 shows, on Sub-net#l, the average percentage of bandwidth used to

download objects from the Home Proxy is 20%, and on Sub-net#3, it is 18%. So we

consider that 19% bandwidth can be saved if we download Web objects from the Home

Proxy. It is a big saving when two proxy servers are both on the same campus LAN or

Corporation LAN. In this case, nearly one fifth of the bandwidth out of the total

downloading bandwidth are consumed locally. On the other hand, 2% more traffic is

created by exchanging x-ICP message between Home Proxy and Foreign Proxy. The











0.45
0.4 sub-net1
0.4 -sub-net3
": 0.35
0.3
m 0.25
0.2
0.15
0.1
C- 0.05


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Days



Figure 4-2. The percentage of bandwidth used to download objects from the nearby
Home Proxy.


average size of each x-ICP packet is 80 bytes. The body of the message contains the

string of the URL. All HTTP requests are forwarded to Home Proxy in the x-ICP format

when there is a cache miss on the Foreign Proxy.

Analysis

Hit Rate versus Inter-proxy Delay

In the previous section we drew a solid conclusion on the cache hit rate and

bandwidth saving of x-ICP using our trace data. In this section, we will extend these

results analytically to better understand the caching performance of x-ICP.

In the x-ICP scheme, a Foreign Proxy forwards a missing request to the nomadic

user's Home Proxy to determine if

1. the Home Proxy holds the requested document

2. that document can be returned faster than from the origin server









Whether such cooperation is worthwhile will mainly depend on the inter-proxy latencies.

We begin by setting up a model to show the relationship between hit rate and inter-proxy

delay based on the x-ICP infrastructure. Let us assume some users move from a Home

Proxy to a Foreign Proxy. Here are some defined terms:

Table 4-2. Variables Used in Analysis
the total number of object requests made by the nomadic users when
R they are attached to a new network
Ch the hit rate on a Home Proxy when R requests were made
Cf the hit rate on a Foreign Proxy when R requests were made
Dh the average delay between a Foreign Proxy and a Home Proxy
Do the average delay between a Foreign Proxy and an origin server


Finally, we have

R (I Cf) Do
Speedup = (2)
R.(1 -Cf).[Dh+ (-Ch).Do] (2)

The numerator denotes the total amount of execution time to fetch Web objects from

origin sites when x-ICP is not deployed. The term 1-Cf is the cache miss rate on the

Foreign Proxy, namely, the probability of fetching objects remotely. R(1- Cf)Do is the

total delay when requests forwarded from the Foreign Proxy to the origin sites. The

denominator is the total amount of execution time when x-ICP is deployed. The 1-Ch is

the cache miss rate on the Home Proxy. So when cache miss happens on a Foreign Proxy

server, the delay Dh occurs. If it is still a cache miss on the Home Proxy, there is another

delay (1- Ch ) Do. Equation (2) can be reduced to equation (3).

Do
Speedup = ---
Speedup Dh + (- Ch) Do (3)


According to equation (3), we draw some conclusions below. The performance of x-ICP

is related to only two factors:










1. the hit rate on the Home Proxy, to whom the requests are forwarded by the Foreign
Proxy

2. the rate of D / Dh

Much research has been conducted on the Internet round-trip time (RTT)

[COTOO,WOR02]. We adopt the value 65ms for regional RTT within Europe and within

North America, which is assigned to Do. Under the assumption of an individual or a small

number of nomadic users, we assign the value 21% average hit rate from the previous

section to Ch.


16
14




8
2 -
10 -------------------
4 -
2


1 1.05 1.1 1.15 1.2 1.25
Speedup



Figure 4-3. As x-ICP is being deployed, the downloading speedup can be considered as a
function of inter-proxy round-trip time.

In Figure 4-3, the speedup value illustrates how many times faster the response

time is when using x-ICP than not using it. As the graph shows, the higher the speedup,

the less the inter-proxy RTT is required. When a nomadic user attaches to a new network,

the RTT between the Home Proxy and Foreign Proxy cannot exceed 13.65 milliseconds,

otherwise people have to wait a longer time to fetch the copies than to fetch from the

origin server directly. On the other hand, the graph sees that when people want to









experience a 1.22 times shorter response time, the RTT can not be more than 2

milliseconds. In conclusion, the RTT of the Home Proxy and Foreign Proxy is between 2

and 11.28 milliseconds to make x-ICP work efficiently.

RTT versus Distance

Our study further shows the relationship between RTT and physical distance. In

[COTOO], having measured 16 pairs of sites located in the United States, Europe and

Japan, Cottrell et al. were able to generate an equation (4), where Y indicates RTT and is

the function of the distance (kilometer), which is denoted by X in equation (4). This

linear function will lead us to a very interesting approximation on the distance.

Y = 0.024X + 5.8887 (4)

With some simple calculations, we conclude that the maximum distance that x-ICP can

support is about 322 kilometers (201 miles) when Y is 13.65 ms.

We have also collected some data on RTT to 10 random selected sites in our lab.

The simulation method in [ZHA93] was implemented. The result is shown in Figure 4-4.

The seven hops are on the routing path, through which most Web object requests from

our lab are sent to the origin sites. The first six hops are on campus. The seventh hop is a

carrier provider's node in another city. We tested the delays in six different periods of a

day and observed that most delays are less than 2 ms on a campus-wide network.

According to Figure 4-3, if it is a cache hit on the Home Proxy, the response time to fetch

that object can be at least 1.22 times faster when x-ICP is deployed on a campus wide

network. Another interesting observation is that, on the campus wide network, the RTT to

a router closer to the user agent is not necessary less than that to a farther away router. In

Figure 4-4, the hop 3 is closer to the browser than hop 6 in physical distance, but it takes







49


longer amount of round-trip time on hop 3 because of the processing time spent on the

router, for instance opening the port and sending back the echo message.


18.00
16.00 I
14.00
S12.00 --hop 1
-)- hop 2
E 10.00 hop 3
> -x-hop 4
8.00 -- hop 5
S6- hop 6
S6.00 --- hop 7
4.00
2.00 -
0.00
1 2 3 4 5 6
time period of a day


Figure 4-4. Round-trip delays tested from the lab in the CISE Department of the
University of Florida to the seven outbound routers.


In the above analysis, we used some empirical values. To further explore the x-ICP

performance, we analyze the sensitivity of x-ICP on Do and Ch. The Do we used is the

RTT measurement on a small network packet. When a Web object is downloaded,

especially on a wireless network, the value of Do is bigger. Figure 4-5 shows that the x-

ICP speedup is not changed significantly when Do grows. On the other hand, when the

overall network speed becomes faster, the speedup drops if the delay between the two

proxy servers is large. Figure 4-6 illustrates that to improve the performance of x-ICP, the

hit rate on the Home Proxy is critical. When hit rate is bigger, speedup grows faster, for

instance, when the hit rate is 50% on the Home Proxy, the speedup can be 2. When the

hit rate on the Home Proxy is low, its impact on the speedup is not significant.











1.4

1.2 -

1

z 0.8

L 0.6

0.4

0.2 Dh=2
--- Dh= 13.65
0
0 100 200 300 400 500 600 700 800 900 1000
Average regional RTT within North America (ms)




Figure 4-5. The impact of RTT values on speedup

35

30- Dh=2
-Dh= 13.65
25

S20

15 -

10 -

5

0
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

Cache Hit Rate on Home Proxy (Ch)



Figure 4-6. The impact of the cache hit rate of the Home Proxy on speedup

In this chapter, we first measured the cache hit rate on the Home Proxy when x-ICP

is deployed. Then with analysis, we found the relationship between the cache hit rate and

round-trip time, and then we mapped the round-trip time to the physical distance with a









linear equation. We are therefore able to answer the questions asked at the beginning of

this chapter.

* About 21% cache hit rates could be obtained on the Home Proxy server with x-ICP
deployed.

* Regarding the bandwidth, about 19% of the total traffic is on the path between the
Home Proxy and the Foreign Proxy instead of between the origin site and Foreign
Proxy.

* Regarding the response time, 21% of objects are fetched at least 1.22 times faster
on a campus/corporation network.

* Nomadic users can attach to any new network without lowering the performance as
long as the Foreign Proxy is not farther than 201 miles away from the Home Proxy
in the circumstances of the current Internet.

Let us go back to the two scenarios imagined at the beginning of Chapter 3 with

these conclusions. While attaching to the College of Health's network, a Computer

Science (CS) Department student can download about one-fifth of the objects (pages,

documents, images) from the CS proxy via the campus backbone, which is at least 1.22

times faster than to get it from the origin site. Moreover, if someone wants to work at

home on the weekend, his ISP can download most objects from his office proxy server as

long as his home is not 201 miles from the office, and the total response time is shorter.

This will also help the ISP to make some local requests instead of long distance or even

international requests to the origin sites on the Internet.














CHAPTER 5
PARTIALITY ADAPTATION

Overview of Partiality Adaptation and Fidelity Negotiation

We have talked about x-ICP to deliver the special user profile for the individual

mobile user and the performance of x-ICP. In this chapter, we will focus on delivering

the general Web contents.

On the server side, Web objects can be classified into two categories: (1) an

XHTML page, also known as a container page or an index page; and (2) a content file,

including many types such as video, image, text, and audio. Significant research has been

done to enable speedy content delivery of the second category, for example, the Internet

content transcoding and distilling for many specific file formats [CHA02, FOX96, LEI01,

MOH98,]. In [SMI98], a framework is introduced to transcode contents among those

types. In regard to the first category object, a widely adopted approach is to use XML to

present the content and use XSL to describe the presentation. To adapt to different

devices or context, XSLT is used to convert the source XML to the destination XML file.

Our research is focused on both of these two categories because they are closely related

to each other. Whether or not to download the objects of the second category depends on

the references in the container pages. Efficiently removing some embedded object

placeholders in the XHTML page can significantly reduce the total number of

downloaded objects.

On the client side, A plethora of exotic electronic devices exist, such as pagers,

PDAs, and color-display cellular phones. There is no sign that the diversity of their









characteristics will diminish anytime soon. As mobile devices come of age, one simple

Web page is no longer universally valid, and more content services are required.

To better understand the client capabilities, network connectivity, or user

preference, metadata or annotation is required and ranges from simple to complex

descriptions. On the one hand, many simple metadata are incorporated into HTTP

headers, such as user agent information and page expiration time. On the other hand, a

very complex metadata like CC/PP exists specifying client-side profile, including every

detail of hardware and software. Moreover, markup languages embed the metadata into

documents--the tags. In our research, we use tags to deliver the following information:

* the appropriate size of an XHTML page, including the appropriate number of
portions and their priorities

* the available versions of each object and their properties

Partiality adaptation and versioning negotiation are designed to deliver different

Web contents derived from the same page for heterogeneous networks and devices. There

are thus two types of corresponding tags: priority tag and fidelity tag. We will see more

details on the second one in Chapter 6. These tags can be incorporated into other

XHTML languages so more complicated functionalities can be implemented while the

previous adaptation and negotiation goals can still be achieved. Figures 5-1 and 5-2

illustrate the overall structure of an XHTML page with priority and fidelity tags and its

Document Type Definition (DTD). Here we name the language with the new tags as

Partiality and Fidelity Markup Language (PFML) for documentation purpose.

Embedded priority tags in an XHTML page indicate the Web author's intention on

how to partition a page into several fragments which are easier to be adapted. Then a

portion of the page can be downloaded upon the user's request. Furthermore, the priority






54

tag can be used for not only content files but also XSL and XSLT template files. The

overall Internet traffic (including those for desktops) could be reduced by downloading

XHTML pages in a smaller granularity and the reduced number of subsequent object

requests.


PFML


Priority



Other Fidelity
HTML Tags


Choice



Img Script Embed


Figure 5-1. Hierarchy of PFML elements

Priority tags not only maintain the end-to-end communication feature of HTTP, but

also give both ends a better way to communicate. Publishers can use them to indicate

their concerns on different objects in terms of priority. Clients can use them to fetch

desired Web objects with appropriate user agent priority values. In our design, the

smaller the value, the user agent is willing to fetch more objects. And intermediaries can

apply the content services accordingly, for example, if there is a traffic jam on the

network, the proxy server can reduce the size of the index page so the page can reach the

user with a shorter delay.














="1.0"?>
PFML SYSTEM "PFML.dtd">
PFML (Priority*)>

Priority ANY>
Priority name CDATA #IMPLIED >
Priority value (0|1|2|3|4|5|6|7|8|9) '9' >
Priority fixed (Y|N) 'Y' >

Fidelity (choice*)>
choice (img* | script* I embed*)>
choice sourceQuality CDATA '1'
type CDATA #IMPLIED
charset CDATA #IMPLIED
language CDATA #IMPLIED
feature CDATA #IMPLIED>


Figure 5-2. The Document Type Definition of PFML.


Figure 5-3 shows how the content adaptation and negotiation work. The full

version of the page consists of three parts with priority values 0, 5 and 9. We assume the

user device is a middle-level one and the device priority value is 5. In step 1, the original

page is tailored to the one without the portion of priority "0" as the response to the user's

first request. All the portions with priority values lower than 5 are filtered out. This

adaptation work can be easily done on either the origin site or a proxy server. In step 2,

the lower resolution image is selected by the client agent according to the variant list,

which is embedded in the container page in the first response. The negotiation is much

more efficient here because the adaptation has generated a smaller page with fewer

embedded objects. The mobile devices can therefore afford process it since fewer

selection algorithms need to run. We will talk about partiality adaptation in great detail in

this chapter and discuss Versioning Negotiation in Chapter 6.



























Figure 5-3. Processing by partiality adaptation and versioning negotiation. With priority
tags, the number of objects to download is reduced in step 1, and with fidelity
tags, the appropriate version of the object is downloaded in step 2.


Partiality Adaptation Design Details

Design of Priority Tag

The priority tag is used to divide a Web page into several fragments in order to

cater to the devices with different capabilities. Each part is assigned a priority value. The

author can use the attribute values of the Priority tag to express their intentions. Value

"9" indicates that the corresponding content has the highest priority which must be sent

out when its URL is requested, whereas the value "0" means the corresponding content is

the least important, compared to other parts of the Web page. By default, the value is set

to "9" for each portion of a Web page. The values could be incremented or decremented

automatically with the algorithms described in the Priority Assignment Algorithm

Section as long as the "fixed" attribute is set as "N". The "fixed" attribute is used to

include those parts which are always necessary, such as the portion or for those









portions lacking links because our automated priority evaluation algorithms are based on

the statistics of the clicks on the links inside a fragment.

An example of partiality adaptation is given in Figure 5-4. Mr. Foo has a personal

Web site. Whenever a request to his homepage is made, he always wants his self-

introduction and contact information to be downloaded. So he assigns those fragments





< TITLE> Foo's Home




I am ...









Foo's Home





I am ...






value set as "5".

Automated Assignment Algorithm of Priority Values

Priority assignment algorithm

Server Side. An XHTML page first needs to be divided into several segments

because the smaller the granularity, the easier it is to adapt to different devices. Each

segment can be as big as a whole page or as small as a table cell, and each segment can









be a link to an object or even a word. The decision on how to fragment a page is made by

either the Web page author or some automated programs, such as a Web page could be

partitioned syntactically or semantically. Regarding small Web sites, such as personal

sites mentioned in Figure 5-4, the author could fragment a page into several portions

according to the semantic by themselves. Fragmenting big commercial sites such as

Yahoo.com may not be an easy job due to its big file size which is about 50k. Instead, an

automated program can parse and fragment it. Some HTML tags could be considered as

the delimiters, such as pairs of for headings,

for paragraphs,

for frames,
,
, , for tables, and so forth. Tools like Xpath could be used to locate these tags, then insert them in between the pair of . Certainly, a unique ID, such as foo_x in Figure 5-4, should be assigned to the segment for later use. For each segment, the initial priority value could be assigned in two ways, which are similar to the above fragmentation methods. If the authors fragment the page manually, they could also assign the priority values at the same time. In this way, authors can show their intentions and have some controls on their pages. Otherwise, an automated program could traverse the whole page and assign value to all the segments as a default value. There are 10 priority values that range from 0 to 9 and those values are significant only within the same page. That means the segment priorities from different Web pages are not comparable. For each page, the value 9 indicates the highest priority whereas 0 means the lowest. Having been assigned the initial value, the priority will be changed

PAGE 71

60 periodically, based on the number of accesses to a segment collected from client agents. Figure 5-5 shows the algorithm. Basically, upon each click, two counters are # Nc: total number of clicks; increment upon each click # Ns: total number of segments of a page # t: a function to calculate a specific threshold with parameters # Pi: priority value for segment i # Ti: the time stamp to generate the Pi # Tnow: the current time # Ci: total number of clicks on segment i # Ci: total number of clicks on segment i sent from client agent # executed on each access for each segment i { Ci Ci + Ci; Nc Nc + Ci; } # executed periodically for each segment i { # priority value increment if ( Ci > t (Ci,Pi,Nc,Ns) and Pi < 9 ) { Pi Pi + 1; Ti Tnow; } # priority value decrement # expired means the segment hasn not been touched for a period else if ( Ti expired and Pi > 0 ) { Pi Pi ; Ti Tnow; } } Figure 5-5. Page Segment Priority Value Decision Algorithm. incremented. One counter keeps track of the number of clicks on the segment. Another is a page counter which counts how many clicks on that page. There is a back end program

PAGE 72

61 monitoring the segment counter. If its value is greater than a threshold, the segment priority will be incremented, and the timestamp for the segment is set as the current time. The threshold is calculated based on the current value of segment priority, the number of accesses on the segment and the page, and the number of segments of the page. Now we need to determine how to increment the counters. If a client agent makes the request to a page, the number of clicks for each segment will be piggybacked, and the total corresponding numbers would be updated accordingly on the server. The number of clicks could be 0, 1, or more. The first two values are obvious. But it could be more than 1 because the browser cache or the proxy server can satisfy the request so there is no packet sent to origin server. Whenever the page on the caches is out of date and the new page iority value p (p>=r) wouldare the number of clicks on the specific segment and the number of clicks on the page. If is downloaded, the counts are piggybacked and reset as 0 locally. Along with each request from the user agent, there is an agent priority value. It is used to reflect the users preference, namely, what percent of the whole page would prefer to downloading. If the value is 0, the complete original page would be sent out. If the value is 9, only the smallest portion with priority value 9 would be transferred. Generally, if the value is r, where 0<= r <=9, all the segments with pr be sent out. The agent priority is calculated on the client side. Client side. For each downloaded Web page, the client agent is responsible for counting the number of accesses to each segment, namely, the agent maintains a tuple for each segment in a page where Cj,i is the number of clicks for the segment. The algorithm, which is illustrated in Figure 5-6, consists of two parts. The first part increments two counters by 1 upon each users click. The counters

PAGE 73

62 Figure 5-6. Client Agent Priority Value Decision Algorithm # Nj,c: total number of clicks on a page; increment upon each click # Nj,s: total number of segments of a page # Np: total number of pages # t: a function to calculate a specific threshold with parameters # Pj,i: priority value for segment i # Pj,c: priority value for a page # Tj,c: the time stamp to generate the Pj,c # Vk: the total number of pages having priority k, where 0<=k<=9 # Pa: priority value for a client agent # Ta: the time stamp to generate Pa # Cj,i: total number of clicks on segment i, page j. # upon each click if (new page) Np Np +1; Initialize new (Cj,i)s to 0; Initialize new Pj,c to 0; Cj,i Cj,i + 1; Nj,c Nj,c + 1; # at the idle time for each page j Pj,c Pj,c; # change priority of page for each segment i if ( Cj,i > t(Nj,c,Nj,s) and Pj,c > Pj,i) Pj,c Pj,i; Tj,c Tnow; else if ( Tj,c expired) if ( Pj,c < 9 ) Pj,c Pj,c + 1; Tj,c Tnow; # change priority of agent if ( Pj,c <> Pj,c) k Pj,c; Vk Vk -1; k Pj,c; Vk Vk +1; if (Vk > t(Np) and Pa > k) Pa k; Ta Tnow; else if (Ta expires and Pa < 9) Pa Pa + 1; Ta Tnow;

PAGE 74

63 it is a new page, the previous two counters need to be initialized to 0s and the page counter is incremented by 1. Based on these data, the client agent changes its request priority value, which is set to 0 at installation time, namely, to download the whole page at the beginning. The second part of the algorithm could be running at the agent idle time without interfering with the users operation. We first calculate the page priority values which are the preparation for the calculation on the agent priority. This is based on the statistic values of segment clicks. If one segment priority is greater than a threshold, which is evaluated on the total number of clicks and the total number of segments, we say that segment priority is dominant. So if the page priority is less than the segment priority, we assign the segment priority value to page priority. For example, if the number of clicks on a segment with priority value 6 is greater than the half number of all clicks, we would let page priority value equal to 6. A good function to calculate the threshold value should not return many dominant segments. On the other hand, if the page priority has not been changed for some time, it is decremented by 1. Then by collecting the page priority values of all the visited pages, the priority value of the agent can be determined. There are 10 variables, V0,V1,through V9, which keep track of the number of pages with priority 0,1. If the page priority changes, the old Vk is decremented by 1 and the new Vk is incremented by 1. If a Vk is dominant again, the agent priority is changed to this value k. Generally, two rules are applied for both page and agent priority decisions: If the number of accesses to a segment/page is greater than a threshold, the current value is decremented. If a priority value has not been changed for a long time, the priority value is incremented.

PAGE 75

64 Therefore, it takes awhile for this algorithm to converge. But it eliminates the ping-pong effects that priority values change quickly when the system just starts and the number of clicks is low. Data structure of priority assignment algorithm We use a heap as the data structure for our Priority Assignment Algorithm. The reason to choose it is because its storage size is small and the operations on it are fast and efficient, which are important for small devices. A heap is a special kind of rooted tree that can be implemented efficiently in an array without any explicit pointers where each node in the tree corresponds to an element of the array. It has two properties: 1. Complete binary tree 2. Heap order A Complete Binary Tree is a binary tree that is completely filled on all levels with a possible exception where the lowest level is filled from left to right. The heap order property is more important for us. For every node v, other than the root, the key stored in v is greater or equal (smaller or equal) than the key stored in the parent of v. A heap is a max heap when the relation between every node v (other than the root) and its parent is the "smaller relation" (v <= parent(v)). The maximum value is stored in the root. The corresponding array for the heap is shown in Figure 5-7. The heap can be created and maintained very efficiently. It can be constructed in linear time. And when a portion of the Web page encounters lots of clicks, its priority may rise or vice versa. The time complexity is O(logn) in order to maintain the heap order. Inserting a new fraction follows a path from a leaf to the root of the tree. The tree height is O(log n) yielding running time of O(log n). To determine which portions of the page to send back, the

PAGE 76

65 program simply locates those elements by the indices i, 2i, and 2i+1 recursively, which is based on the breadth-first traverse where i is the parent node and 2i and 2i+1 are its children[BRA96]. Figure 5-7. The heap data structure for priority selection algorithm In our case, there exists another string field in each array element which stores a path from the root element to the corresponding section. Then the section can be easily located by XPath. The primary purpose of XPath is to address parts of an XML document. In support of this primary purpose, it also provides basic facilities for manipulation of strings, numbers, and booleans. The XPath uses a compact, non-XML syntax to facilitate use of XPath within URIs and XML attribute values. XPath gets its name from its use of a path notation as in URLs for navigating through the hierarchical structure of an XML document. Given the example in Figure 5-4, we have the XPath:

PAGE 77

66 /PFML/BODY/Priority[@name=foo_2] to locate the self-introduction part of the page. These paths can serve as the pointers and be stored in the Array A in Figure 5-7. Web Caching in Partiality Adaptation Web caching plays a big role in our partiality adaptation. Priority tags allow different devices to share the same copy of an XHTML file which is usually stored in the caching server. A mobile device can take advantage of the copy of a Web page previously downloaded by some other devices, for example, a desktop, in a caching hierarchy. Instead of going all the way to the far end of the Internet, the client with less capabilities can obtain a subset of the page by extracting the content marked with higher priorities. On the other hand, a device with more capabilities can use the partial copy of a Web page, which was downloaded previously by a smaller device, and send it to the user directly. This can shorten the response time. The remaining objects could be downloaded simultaneously and integrated with the previous part at last. Therefore, letting the mobile device users and traditional desktop users share the same Web page potentially increases the chance of a Web cache hit rate, reduces Internet traffic, and lowers the response time to clients. Experimental Evaluation We conducted a series of experiments on the client and proxy sides. On the client side, we used three types of wireless devices. The first device is a J2ME-enabled Motorola i85 cellular phone. Nextel service was subscribed, which provided a 19.2 kbps transfer rate. We consider this as a low-end device in terms of network performance, CPU power, and display size. The second device is an IBM 390 Thinkpad which uses a 802.11b compatible wireless card to connect to the access point in our lab. The

PAGE 78

67 connection rate was at 11 Mbps. This is cons idered to be a high-end device. The third device is an iPAQ 3800 PDA and uses the sa me network adaptor a nd network connection as the laptop but with less computation pow er and memory. We ha ve also programmed a proxy server and let it run on a Sun Ultr a 60 workstation. The proxy code includes several modules as a normal proxy server doe s: a server side module responsible for setting up a connection with the Web server; a client side module in charge of the communication with clients; a cache management module; and a PFML parser. The two Web servers we used were Google.com and CNN.com. The index pa ge of CNN.com is about 50k and frequently updated. On the ot her hand, the index pa ge of google.com is less than 3k and rarely changed. Laptop computer PDA Cell phone Proxy Server Web Server Internet Figure 5-8. Experimental envir onment on partiality adaptation. We designed three cases, as Figure 5-8 shows, to download a portion of the Web page to the client which is about 1k size. 1. Remote Case: We download the page from the origin site. The client sends out a request to our proxy server, then the proxy relays the request to the origin site. Having received the whole page from the Web, the proxy extracts the first 1k data and forwards the data to the client.

PAGE 79

68 2. Extracted Case: We put the pages of the Web sites onto the proxy servers local disk, and inserted some pairs of tags into the origin pages. Upon the users request, the parts marked with are extracted and sent back to the client. 3. Cached Case: We put an extracted copy of the Web site on the proxy, which is about 1k. When the users request came, the copy was sent out immediately. For each of these three cases, we conducted the experiment 12 times at different time periods of each day. For example, the first experiment was done at 8 a.m. on Monday morning; the second was at 12 a.m. on Tuesday morning, the third was at 4 a.m. on Wednesday morning, and so forth. The intervals between two experiments are 16 hours. By doing the experiments at different times on different days, we could get a fair measurement on traffic of both the Internet and wireless links. Figure 5-9 shows the raw data of running three-case requests from a cellular phone to download a suitable copy of the CNN index page. Since there is a significant timing difference between downloading the largest and smallest datum, we use the logarithmic scale to illustrate the results. In Figure 5-9(a), each bar shows the complete round-trip time starting from sending out the first byte of request and ending at receiving the last 110100100010000100000123456789101112the nth testlogrithmic RTT time Remote Fragment Cached (a) Figure 5-9 is continued on the next page

PAGE 80

69 110100100010000100000123456789101112the nth testlogrithmic server processing time Remote Fragment Cached (b) Figure 5-9. Raw data collected on a 12-day trace. (a) represents the RTT measured on cellular phone. (b) RTT measured on proxy byte of the page. In Figure 5-9(b), each node shows the round-trip time beginning at the proxy receiving the request and finishing when the proxy received and/or processed the page. We give an overall glance at the data in Table 5-1. The average values are calculated from all 12 runs. We use the same method to collect other data for PDAs and laptops. Table 5-1. Example Data on a 12-day Trace of a Cellular Phone Case 1 Case 2 Case 3 Phone Proxy Phone Proxy Phone Proxy Minimum 4910 475 3810 12 3639 3 Maximum 42214 31613 37846 14 36048 4 Average 18824 7568 10033 13 10380 4 Then the method is applied to download the index page of Google. In Figure 5-10, we show only the average value of different category data. Figure 5-10(a) illustrates the total time measured between the users sending out the request and receiving the desired

PAGE 81

70 page. The performances of cached and extracted cases are very similar, whereas the remote case has one order of magnitude of larger retrieving time. For example, the average times to download a CNN page to laptop on the three cases are 8258ms, 764ms, and 756ms. This is mainly because in Case 1 a significant amount of time was spent in between the proxy and origin server to download pages. To further explain this, Figure 5-10(b) measured the time which started from getting the users request and ended at finishing sending back the copy on the proxy. It illustrates that when the proxy relays the client request to the origin site, it takes a big amount of time, which is about 7568ms. On the other hand, if a copy is already cached by the proxy, it takes the least amount of time on the proxy. The time to parse a PFML page and extract some portions of it varies on the size of the origin page. It takes about 13ms to process a 50k page and about 4ms to process a 3k page. It needs about 3ms to send back the ready copy. Figure 5-10(c) deals mainly with the time spent on the client side, including the time that a client sets up a connection with the proxy and the time that the client processes the downloaded page. The wireless links consume significant amounts of time to download pages. They are 10376ms and 8535ms for CNN and Google pages, respectively. According to the experimental result in regard to the CNN page, the average time to process a cache hit is about 3ms; to fragment a 50k CNN.com home page is about 15ms; and to download it from the Web on the wired network is approximately 7500ms. For a smaller page like Googles homepage, which is about 3k, the three values are 3ms, 4ms, and 500ms. The shorter downloading time (500ms) is due to its relatively long expiration time so that pages can be downloaded from nearby caching proxy servers. In our program, we force the agent to download the pages without accepting the

PAGE 82

71 intermediary copies. But some interception proxy servers are deployed on the Internet so it is still possible to get a page from proxy, especially for static pages like Google.com. Figure 5-10 shows a much longer round-trip time to download a page onto a cellular 110100100010000100000Cnn Lapto p Google Lapto p Cnn PDAGoogle PDACnn PhoneGoogle Phonelogarithmic time Remote Extracted Cached (a) Comparison of total time to download pages to the devices 110100100010000Cnn LaptopGoogle LaptopCnn PDAGoogle PDACnn PhoneGoogle Phonelogarithmic time Remote Extracted Cached (b) Comparison of the time spent on the proxy server Figure 5-10 Simulation results on PFML.

PAGE 83

72 110100100010000100000Cnn LaptopGoogle LaptopCnn PDAGoogle PDACnn PhoneGoogle Phonelogarithmic time Remote Extracted Cached (c) Comparison of the time spent by the clients Figure 5-10 Continued. phone with wireless links. The time spent on wireless links is dominant. So the extracted and cached time are very similar because the proxy processing time is negligible compared to the time consumed by the wireless links. But on the other hand, we still see about 8000ms saved on the extracted and cached cases than downloading from the original remote site to fetch a 50k CNN.com index page. We see 1500ms saved on fetching a 3k Google.com index page. This experiment shows that by allowing different devices to share a cached object with Priority tags, it saves about 8 seconds in the best case scenario, for example, to fetch a 50k Web object from the origin site. It also shows that when the wireless network, for example a Wi-Fi network, transfer rate is comparable with that of the wired lines, the saved amount of time is significant. In our Google case, it saves 496ms. On the other hand, when the wireless link transfer rate is at least one order of magnitude lower than that of the wired line and the size of the Web object is small, for instance 3k, the saved

PAGE 84

73 time is less significant compared to the delivering time on the current telecommunication network. But according to the experiment, it still saved about 1.5 seconds out of 10 seconds total delivering time. Therefore, to draw a more accurate conclusion on the performance of a priority tag on the slow wireless networks, we measured the delivering time on the cellular phone by sending out requests to 100 popular Web sites. 02000400060008000100001200014000160001800020000050001000015000200002500030000Page Size (bytes)Downloading Time (ms) Remote Extracted Figure 5-11 Simulation data on 100 Web sites retrieved by cellular phone. The sites were collected from www.hot100.com with more than 10 categories. The sites are generated using Overture's search rankings for the query contained in the category. The 10 categories that we chose are listed in Table 5-2. We used both Remote and Extracted Cases. With remote simulation, the pages were downloaded to the cell phone from the origin site. The downloading time is shown by the blue square in Figure 5-11. But this time, in our client code, the intermediary copies are allowed to fetch. Since the selected Web sites are very popular, pages are most

PAGE 85

74 likely to be downloaded from a proxy server close to client agents. Therefore, this is the best scenario for the Remote case, namely, users can always download a page very fast. In comparison, we stored pages on our Unix machine, and when users requests come in, the pages are simply read through once and sent back to the phone directly. We did not extract any contents because we want to deliver the same sizes of the pages, otherwise the saved transferring time on a wireless network will dominate the overall amount of saved time. The Extracted Case measurement is shown with pink diamond dots in Figure 5-11. The average size of downloaded page is 4843 bytes. The average downloading time is 6875ms in remote simulation, whereas it is 5910ms in extracted simulation. Table 5-2. Distribution on 100 Web Sites. Categories # of sites Art&Culture/Books 10 Business/Finance 10 Education/College 9 Gaming/Gambling 8 Entertainment/Music 11 Home/Cooking 10 Lifestyles/Cars 10 News/Newspapers, Magazines 10 Shopping/Electronics 10 Technology/Internet 12

PAGE 86

75 Therefore, by allowing users to share the cached objects among heterogeneous devices with Priority tags, we are able to save 965ms to download an average-sized Web page. The performance is improved at least 14%. Sseveral points need to be taken into account. First, the workload on the proxy is rather low, which may lead to less processing time of page extraction. Second, the proxy server is supposed to be put at the spot where the backbone of the Internet and the cellular network are connected. But in our simulation it was not deployed this way. Third, most programs were coded in Java language except the one on PDA, which is in C#. But in [GRI02], C# and Java are proven to be very close in TCP socket performance.

PAGE 87

CHAPTER 6 VERSIONING NEGOTIATION Partiality adaptation mainly concentrates on the XHTML index pages whereas versioning negotiation is designed to select the right object version efficiently. After the first round-trip communication between client and server, the objects embedded in the XHTML page are decided. Then it is time to deliver the appropriate version of each object. Content negotiation requires a variant list for every object. The process on a server needs to select the best representation for a given request when multiple representations are available, for example, an HTML version or a WML version. The variant lists are usually stored on the Web server. Whether or not to send out the list and where to send the list depends on the negotiation mechanism. In our approach, we use fidelity tags to conduct versioning negotiation. Lists are embedded in an index page and sent out to user agents. Design of Fidelity Tags Fidelity tags convey object variant messages to clients directly and precisely. This enables users to make their own decision in the first place. Different fidelity descriptions include different attributes of content objects. For example, a text object has the attributes such as language and charset, and image attributes include size and resolution. With the help of fidelity tags, a user agent can easily understand how many different presentations are associated with one embedded object and their characteristics. A clear decision can therefore be made directly by an end-user. 76

PAGE 88

77 Variants of objects and their attributes can be inserted as lists into an XHTML page where the original Web objects were embedded. The lists are quoted by Fidelity tags. Choice tags specify each one of the versions of an object and its attributes. All tags are defined in PFML DTD in Chapter 5. Figure 6-1 shows two types of objects and three associated variants. The first object is an image file associated with three presentations. The image in GIF format has the best quality and biggest size. (The quality values are evaluated by the Web author and we adopt them from [RFC96].) It is the best format for desktops and laptops. To target PDAs, pictures in Portable Network Graphics (PNG) format are the best choices because they have a little lower resolution and relatively smaller size. For pager and cellular phone users, a plaintext can be displayed instead of the image. In the second example, the document in English and in postscript format is the best version. The English version in plain text is a worse one. And the French plaintext is the worst copy in terms of quality. The variant selection can be done on a user agent by matching device information with the objects attributes because the agent has the complete knowledge of the users hardware and software platforms. Versioning Selection Algorithm Versioning selection needs two steps. First, several suitable versions can be chosen according to objects attributes and device capabilities. In regard to images, an user agent can choose all those with width and length smaller than or equal to some predefined values. If they happen to be the same, the quality value of the object is not changed, otherwise, the quality value would be decreased. If the browser agent is aware of the existence of proxy servers somewhere in between the origin server and itself, the version with bigger width and height can be chosen because the proxy can do the transcoding on the fly, but the quality value also needs to be decreased accordingly.

PAGE 89

78 Foos Home

I am

foo < /PFML > Figure 6-1. An Example of using PFML with both Fidelity and Priority tags. (The attribute values of the above examples are adopted from [RFC96] with some modification.)

PAGE 90

79 In the second step, the Remote Variant Selection Algorithm (RVSA) [HOL98a] could be used with the modified quality values. The overall quality Q of a variant is the value Q = round5( qs qt qc ql qf ) where round5 is a function which rounds a floating point value to 5 decimal places after the point, and where the factors qs, qt, qc, ql, and qf are determined as follows. qs Is the source quality factor in the variant description. qt The media type quality factor is 1 if there is no type attribute in the variant description, or if there is no Accept header in the request. Otherwise, it is the quality assigned by the Accept header to the media type in the type attribute. Note: If a type is matched by none of the elements of an Accept header, the Accept header assigns the quality factor 0 to that type. qc The charset quality factor is 1 if there is no charset attribute in the variant description, or if there is no Accept-Charset header in the request. Otherwise, the charset quality factor is the quality assigned by the Accept-Charset header to the charset in the charset attribute. ql The language quality factor is 1 if there is no language attribute in the variant description, or if there is no Accept-Language header in the request. Otherwise, the language quality factor is the highest quality factor assigned by the Accept-Language header to any one of the languages listed in the language attribute. qf The features quality factor is 1 if there is no features attribute in the variant description, or if there is no Accept-Features header in the request. Otherwise, it is the quality degradation factor for the features attribute, see section 6.4 of [2]. As an example, if a variant list contains the variant description {"paper.html.en" 0.7 {type text/html} {language fr}} and if the request contains the Accept headers Accept: text/html:q=1.0, */*:q=0.8 Accept-Language: en;q=1.0, fr;q=0.5 the remote variant selection algorithm will compute an overall quality for the variant as follows:

PAGE 91

80 {"paper.html.fr" 0.7 {type text/html} {language fr}} round5 ( 0.7 1.0 0.5 ) = 0.35000 With the above Accept headers, the complete variant list {"paper.html.en" 0.9 {type text/html} {language en}}, {"paper.html.fr" 0.7 {type text/html} {language fr}}, {"paper.ps.en" 1.0 {type application/postscript} {language en}} would yield the following computations: round5 ( qs qt qc ql qf ) = Q paper.html.en: 0.9 1.0 1.0 1.0 1.0 = 0.90000 paper.html.fr: 0.7 1.0 1.0 0.5 1.0 = 0.35000 paper.ps.en: 1.0 0.8 1.0 1.0 1.0 = 0.80000 In fact, this algorithm is more suitable for our versioning negotiation because the metadata in RVSA are used to describe Web objects but not the device information. With the object description and the on-hand device information, a client agent could therefore make a good choice. Advantages of Versioning Negotiation First, compared to agent driven negotiation, our approach saves one round-trip time. In the agent driven negotiation, when the user sends out a request, the server sends back the list of variants. Based on the list, the user agent chooses the right version according to its device information and sends over the decided choice of the object. Then the server delivers the requested version of the object. In versioning negotiation, the variant lists come with the XHTML index page so the user agent chooses the best version without requesting the variant list. This saves one round-trip time.

PAGE 92

81 Second, on the server driven negotiation, it is the origin site server who makes the decision on which copy to send out. This has several disadvantages. First, the decision is based on the resource description information like CC/PP sent from a user agent or some third-party Web site which is the repository of device information. In our approach, the decision is made by a user agent. It saves bandwidth because a CC/PP file is usually very large which contains comprehensive metadata to describe properties of hardware and software. Second, it is not secured to disclose the users information such as the OS version by sending out device information online. Third, in regard to Web caching, the server-driven adaptation is not always a good negotiation solution because it bypasses the caching server. Fourth, the transparent negotiation also has some drawbacks. It is designed to save bandwidth and take advantage of a caching server. But to decide an optimized version, it requires not only cached Web objects but also client profiles and object variant and attribute information. This would result in a significant modification of the current Web caching functionalities on the proxy server that are widely deployed. In the versioning negotiation, since the decision is made by a user agent and device information is always complete, a request always includes an explicit URL. Therefore, a Web caching server can simply return the requested page as it does now. The only difference is that XHTML pages have more annotation information for embedded objects than current ones. Web Caching on Versioning Negotiation Our approach improves the performance of content negotiation by fully taking advantage of the current Web caching mechanism. With Fidelity tags, the requested XHTML pages are embedded with object variant lists. Then the user agent makes the decision on fetching which object. Thus there is no more round-trip between client and

PAGE 93

82 server and no extra trip to fetch the device description. Since every version of Web objects are associated with a URL, an explicit request can come from a user agent as usual. So the browser cache, proxy cache, surrogate cache, and even origin server all behave like what they are doing now. Simulations and Analysis on Versioning Negotiation In this section, we conducted two simulations on both content negotiation with CC/PP and our versioning negotiation. We showed the experimental result that versioning negotiation outperformed the content negotiation with CC/PP. The simulation environment was set up as Figure 6-2 shows. The Web server is Apache. It hosts more than 1000 personal Web sites of CISE Department students and professors at the University of Florida so we are able to test the simulation with some real workload. Two CGI modules were put onto the server programmed with Perl. One is for CC/PP and the other is for versioning negotiation. The CC/PP module receives the users requests, retrieves the device information from a third-party site, matches different versions with device descriptions, and sends back the selected version to the client. We call our versioning negotiation module PAVN. It behaves like a normal Web server which simply returns pages. The matching process between devices and objects happens on the client side in PAVN. We used a Motorola i95 cellular phone as a client and programmed with J2ME and MIDP 1.0. Elapsed time is measured on the cellular phone and displayed on the phone screen. The downloaded pages and objects are not displayed because for both methods it takes the same amount of time for the two methods to render. The phone has 1.5M RAM, 160*120 screen, 8 bits color depth [MOT02]. The CPU speed is not disclosed by Motorola, but it is estimated to be around 100MHz [PHO03].

PAGE 94

83 i95cl Apache Web Server Nextel Tower CCPP PAVN Internet Figure 6-2. Simulation environment to co mpare performance on CC/PP and PAVN negotiation modules The simulation results are illustrated as a bar graph in Figure 6-3. The vertical axis indicates the round-trip time to fetch the Web objects. The horizontal axis shows the sizes of the downloaded objects. The plus sign on the object size means two objects were downloaded; for example, 1k+256 indicates th at two objects were downloaded. It means the size of the index page is 1k, and the size of the embedded object is 256 bytes. Each bar shows the average time of 15 runs. The Versioning Negotiation outperformed CC/PP in all 9 cases where both the CC/PP and PAVN algorithm are executed. Th e average saved time is about 870 milliseconds. To further explore the amount of the saved time, we analyzed the performance on the two server side modules carefully. The two CGI modules are very short. The PAVN CGI simply gets the request, opens the corresponding file, and sends it back. The CCPP CGI uses the Library for WWW in Perl (LWP) to fetch the device CC/PP file, then gets the image format information, for example, the width, height and the resolution, and finally opens the requested file and returns it.

PAGE 95

84 0200040006000800010000120001k+1k1k+5121k+2551k+01k512+512512+256512+0512256+256256+02560Object Size (bytes)Round-trip Time (ms) PAVN CCPP Figure 6-3. Simulation results on CC/PP and Versioning Negotiation We used the UNIX time command as a benchmark to measure the two programmed modules. Figure 6-4 shows the details returned by the time command. For the CCPP module, the majority of the extra time was spent on retrieving the CC/PP file from the Internet. The user process consumes 0.78 second, the system calls on network takes 0.11 second, including file opening and network connection setting up, and the total elapsed time is 1.35 seconds. Therefore, it takes about a half second to fetch the CC/PP file from the Internet by subtracting the first two numbers from the last one. Regarding the PAVN module, the total elapsed time is 0.34 second, the user process takes 0.28 second, and the system time consumes about 0.02 second on file operation. We therefore saved about 1 second on the server side by using PAVN instead of the CC/PP module. In our novel implementation, several issues are not considered. First, the CC/PP file is fetched from the proxy server which certainly saved a lot of time. Second, in the real

PAGE 96

85 00.20.40.60.811.21.41.6CCPPPAVNtime (seconds) total system user Figure 6-4. Time measured on the server side implementation of CC/PP, there are always some delta data sent to the Web server from the client as complementary information, for example, the upgraded operating system version or the size of the memory sticks which was just inserted into the expanded slots. The extra information will also cost some extra time for the CC/PP module. Third, we used an average size of CC/PP files, which is 4.24k bytes because we could not find out a standard CC/PP file for the Motorola i95cl phone [W3C01]. The processing time of the Versioning Selection Algorithm (VSA) on both server and phone is insignificant compared with the object delivering time spent on the wireless and wired networks. With a lack of benchmark tools on cellular phones, we could not find out the accurate time spent on the phone client as we did on the UNIX server. But we got several timestamps while our application was running. It takes only 25ms to parse the fidelities of one object as Figure 6-1 shows. But we use only this datum as a reference since it is measured inside the program and thus not accurate. It is interesting to note is that there is a significant delay on setting up a connection on a wireless network. The experiments show three cases to download 512k Web objects:

PAGE 97

86 256+256, 512, and 512+0. In PAVN, to download 512 bytes with one round-trip consumes 5398ms. But the others take 6959 and 6677ms separately. It is similar to the CCPP method. Therefore, it would be more efficient to download everything necessary at once on the current wireless network, which is similar to the WAP solution. But pushing Web contents is a preemptive solution which is opposite to our pulling method in versioning negotiation. Finally, we can see the trend of computing power of small devices and their connected wireless links will be developed extremely fast in the near future. The saved time by deploying PFML will be more significant. Moreover, we do not need different solutions to different devices. The ubiquitous Web will finally appear on all devices.

PAGE 98

CHAPTER 7 CONCLUSION AND FUTURE WORK Summary This dissertation presents a study of Web caching in the domain of pervasive computing. We ubiquitously deliver Web contents to mobile users with heterogeneous devices. We first pointed out the challenges. In the upcoming world of pervasive computing, users access information sources in the World Wide Web by a huge variety of mobile devices featuring heterogeneous capabilities, for example, with respect to display, data input, computing capacity, and so forth. These mobile devices coexist with fixed workstations resulting in an even broader diversity of device characteristics and capabilities. The miscellaneous devices are attached to the Internet by a variety of communication systems, such as cellular radio networks, local area wireless networks, dial-up connections, or broadband connections. The various communication systems offer different functionality and heterogeneous characteristics, for example, bandwidth, delay, and so forth [BUS03]. We presented an approach that joins the concepts of Web caching and XML in a uniform scheme so whichever the devices are being used and wherever the location is, a user can always get the same appearance of the Web contents within the same amount of response time. Generally, we classify Web contents into two categories: the personal profile such as the users bookmarks, contact information, and the public Web contents such as 87

PAGE 99

88 HTML pages, text files, image files, and so forth. We further make two subcategories on the public Web contents which are XHTML index pages and the contents with specific file formats, such as .txt, .jpg files. We solved the problems of each category separately and integrated them together. The Internet Caching Protocol was extended and named as x-ICP. It targeted delivering a personal profile and shortening response time for mobile users. When a user changes the point of attachment on the network, x-ICP transparently connects the Foreign Proxy with the Home Proxy and gets the personal profile ready. The x-ICP can also help users to fetch Web objects from the Home Proxy to reduce the response time and the overall traffic on the Internet. According to the experiments, if the user moves around on an intranet--the Foreign Proxy and Home Proxy are connected by the same backbone--the response time can be 1.22 times faster with x-ICP deployed than without it. The experiments also showed that with the constraint of the current Internet performance, users would not be able to benefit from cached copies on the Home Proxy unless their distance to the Home Proxy is no more than 201 miles. We proposed a new XML language called PFML to solve the delivering problem of public objects. The PFML consists of two tags: priority and fidelity. Priority tags are used by partiality adaptation to transport an XHTML page. Basically, a generic page for all devices in all network circumstances is generated by the Web author. But the different parts of the page are marked by the priority tags to indicate their importance compared with other sections. Therefore, users are able to download Web pages according to their preferences, device capabilities, and network conditions. All these can be done automatically by our Client and Server Priority Selection algorithms. Our experiment

PAGE 100

89 showed, with the help of priority tags and caching servers, a cellular phone can save about 1 second to download a Web page compared to downloading a normal HTML page. Fidelity tags are designed for versioning negotiation. It allows the user agent to determine which objects to fetch if multiple versions exist. The variant lists of objects are embedded into the index page and delivered to the user agent in the first place. Then our Versioning Negotiation Algorithm is running on the mobile device to choose the best version. Our experiment showed that the computation time on the small devices was not significant compared to the network transportation time. The current CC/PP solution takes 0.8 more second to deliver a Web object than our versioning negotiation method. The amount of time saved by our algorithms will be more significant when the transfer rates of wireless networks are faster. The Universal Mobile Telecommunications System (UMTS) will provide up to 10M bps by the end of 2005 [ARC03]. Furthermore, there will be about 135,000 hot spots in service to cellular/VoIP Wi-Fi integrated phones in 2006 [COM03], which rate is at least 11 Mbps. Future Work We hope in the future that all Web pages are embedded with PFML tags, and x-ICP is deployed everywhere so the ubiquitous Web contents can be presented, network traffic can be reduced, and user response time can be shortened. The most important experiment needed to done is to model the mobile users behavior, for example, what kind of Foreign Proxies they tend to use, how far they are from the Home Proxy, how long is the linger time, which devices are being used while moving, what is the speed of movement, and so forth. Unfortunately, the log files of the

PAGE 101

90 current proxy servers do not include all these aspects of information; and there would be some social problems if the user agents are allowed to track this information. If we are able to have this data, a more precise calculation can be done on measuring our methods, for example, how much bandwidth is saved on the Internet and how much response time is shortened to users when PFML is deployed.

PAGE 102

LIST OF REFERENCES [ARC03] Arc Electronics Inc., G and 3G Cellular Wireless, available at: http://www.arcelect.com/2G-3G_Cellular_Wireless.htm 2003 last access: 09/20/2003. [BAL98] Balakrishnan Hari, Challenges to Reliable Data Transport over Heterogeneous Wireless Networks, Ph.D. Dissertation, University of California at Berkeley, 1998. [BAR00] Barish Greg and Obraczka Katia. World Wide Web Caching: Trends and Techniques, IEEE Comm. Internet Technology Series, vol.38, no.5, May 2000, Pages:178-184. [BRA96] Brassard Gilles, Bratley Paul, Fundamentals of Algorithms, Prentice Hall, New York, 1996. [BUC03] Buchholz Sven and Schill Alexander, "Adaptation-Aware Web Caching: Caching in the Future Pervasive Web, in proceedings of the GI/ITG Fachtagung Kommunikation in Verteilten Systemen (KiVS 2003), Leipzig, Feb 26-28, 2003. [BUT01] Butler M. H. Current Technologies for Device Independence, Hewlett Packard Laboratories Bristol; External Technical Report HPL-2001-83; 30 March 2001 [CAM00] Campbell Andrew T. "Design, Implementation, and Evaluation of Cellular IP," IEEE Personal Communications Magazine, Volume: 7, Issue: 4, Pages: 42-49, August 2000. [CCP99] CC/PP Working Group, CC/PP, 1999, available at: www.ccpp.org, last access: 05/10/2003. [CHA00] Chakraborty Dipanjan, Chen Harry, Service Discovery in the Future for Mobile Commerce, ACM Crossroads, winter 2000, available at: http://www.acm.org/ crossroads/xrds7-2/service.html last access: 01/25/2002. [CHA02] Chang SF, "Optimal Video Adaptation and Skimming Using a Utility-Based Framework," in Proceedings of IWDC-2002 Capri Island, Italy, Sep. 2002. [CHI02a] Chi Chi-Hung, Cao Yang. Pervasive Web Content Delivery with Efficient Data Reuse, in proceedings of the 7th International Workshop on Web Content Caching and Distribution, Boulder, Colorado, August 2002. 91

PAGE 103

92 [CHI02b] Chi C., Wu Y. An XML-Based Data Integrity Service Model for Web Intermediaries, in proceedings of the 7th International Workshop on Web Content Caching and Distribution, Boulder, Colorado August 2002. [CIS01] Cisco Introduction to Mobile IP, 10/08/2001, available at: http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/moblip/mobil_ip.pdf last access: 11/15/2002. [COM03] Computer World, Megabit Mobile, Octorber 13, 2003, available at: http://www.computerworld.com/mobiletopics/mobile/technology/story/0,10801,85890,00.html?f=x596 last access: 10/20/2003,. [COM99] Comet Group in Columbia University, Cellular IP, 1999, available at: HTTP://www.comet.columbia.edu/cellularip/spec.htm last access: 12/05/2001. [COT00] Cottrell L., Matthews W. and Logg C. Internet Monitoring at SLAC, October 22, 2000, available at: Tutorial on Internet Monitoring & PingER at Stanford Linear Accelerator Center last access: 12/01/2002. [DAV01] Davison Brian D., A Web Caching Primer, IEEE Internet Computing, Vol. 5, Issue 4, Pages: 38-45, July/August 2001. [DAV99] Davison Brian D., A Survey of Proxy Cache Evaluation Techniques, in proceedings of the 4th International Web Caching Workshop, San Diego, California March/April 1999. NLANR and CAIDA. [DOU97] Douglis F., A. Haro, and M. Rabinovich. HPP: HTML Macro-Preprocessing to Support Dynamic Document Caching, In USENIX Symposium on Internet Technologies and Systems, Monterey, California, USA Dec. 1997. USENIX Association. [DUC92] Duchamp Dan, "Issues in Wireless Mobile Computing, in proceedings of the 3rd IEEE Workshop on Workstation Operating System, Pages: 1-7, April. 1992. [FOR94] Forman George H. and Zahorjan John, "The Challenge of Mobile Computing, University of Washington CSE Tech. Rep. #93-11-03, 1994. [FOX96] Fox A. and Brewer E. A.: Reducing WWW latency and bandwidth requirements by real-time distillation, in proceedings of the 5th International 3WC, Paris, France (1996). [GAD00] Gadde S., Chase J., and Rabinovich M.. Web Caching and Content Distribution: A View From the Interior, in proceedings of 5 th International Web Caching and Content Delivery Workshop (WCW00), Lisbon, Portugal, May 2000. [GOL98] Goldberg Arthur, Pevzner Ilya, and Robert. Buff.Caching Characteristics of Internet and Intranet Web Proxy Traces, in Computer Measurement Group Conference, Anaheim, California, USA December 1998.

PAGE 104

93 [GRI02] Grimm Robert. System Support for Pervasive Applications, Ph.D. thesis, University of Washington, December 2002. Available at: http://cs.nyu.edu/ rgrimm/one.world/papers/phdthesis.pdf last access: 09/11/2002. [IMI94] Imielinski Tomasz and Badrinath B. R., "Wireless Mobile Computing : Challenges in Data Management, Communications of the ACM, Pages: 19-27, Oct. 1994. [KNU02] Knutsson Bjorn, Lu Honghui, and Mogul Jeffrey. Architecture and Pragmatics of Server-Directed Transcoding, in proceedings of the 7th International Workshop on Web Content Caching and Distribution, Boulder, Colorado August 2002. [LEI01] Lei Z., Georganas N. D., "Context-based media adaptation for pervasive computing, Proceedings of Canadian Conference on Electrical and Computer Engineering, Toronto, Canada, May 2001. [LEM02] Lemlouma T., Layaida N., Content Adaptation and Generation Principles for Heterogeneous Clients, OPERA Project, INRIA Rhone Alpes. W3C DIAT Workshop 2002. [MIC00] Microsoft Corporation, Universal Plug and Play Device Architecture Reference Specification, June 2000, Available at: http://www.upnp.org /download/UPnPDA10_20000613.htm last access: 03/02/2002. [MOT02] Motorola Inc., I95cl Multi-Communication Device J2ME Developers Guide, 2002, available at: http://idenphones.motorola.com/iden/developer/ developer_documentation.jsp last access: 08/23/2003. [MUK94] Arup Mukherjee and Daniel P. Siewiorek, "Mobility: A Medium for Computation, Communication, and Control, IEEE Workshop on Mobile Computing Systems and Applications, Dec. 1994. [ORA01] Oracle Corporation, Akamai Technologies, Inc., Edge Side Includes, 2001, available at: http://www.esi.org last access: 11/15/2002. [PER97] Perkins Charles E., SLP White Paper topics, May, 1997 Available at: http://playground.sun.com/srvloc /slp_white_paper.html last access: 10/01/2003. [PER98a] Perkins Charles E. "Mobile Networking through Mobile IP, IEEE Internet Computing, Vol. 2, Issue 1, Pages: 58-69, January-February 1998. [PER98b] Perkins Charles E.. Mobile IP Design Principles and Practices, Addison-Wesley, 1998. [PHO03] Phone Description, Available at: http://www.ilmunc.org/ motorola_i95cl. html last access: 09/05/2003.

PAGE 105

94 [REK99] Rekesh John, "UPnP, Jini and Salutation A Look at Some Popular Coordination Framework For Future Network Devices," Technical Report, California Software Lab, 1999. Available at: http://www.cswl.com/whiteppr /tech/upnp.html last access 05/10/2001. [HOL98] Holtman K., Mutz A., Transparent Content Negotiation in HTTP, March 1998, Available at: http://www.faqs.org/rfcs/rfc2295.html last access: 08/10/2003. [HOL98a] Holtman K., Mutz A., HTTP Remote Variant Selection Algorithm -RVSA/1.0, March 1998, available at: http://www.faqs.org/rfcs/rfc2296.html last access: 08/10/2003. [SAT95] M. Satyanarayanan, "Fundamental Challenges in Mobile Computing, In Proceedings of the Fifteenth ACM Symposium on Principles of Distributed Computing, Pages: 1-7, Philadelphia, PA, USA, 1995. [SHI01] W. Shi and V. Karamcheti. CONCA: An Architecture for Consistent Nomadic Content Access, in proceedings of the WCCC Sorrento, Italy June 2001. [SMI00] Smith Craig Traceroute Whitepaper, 2000, Available at: http://www.informatik.unitrier.de/~smith/networks/tspec.html last access: 05/26/2001. [SMI98] Smith J.R., Mohan R. & Li C.. Transcoding Internet content for heterogeneous client devices, in proceedings of IEEE Conference on Circuits and Systems Vol.3, Pages: 599-602, May 1998. [SWI01] The Swiss Education and Research Network, TTL Value, 2001, Available at: http://www.switch.ch/docs/ttl_default.html last access: 07/12/2001. [TEW99] Tewari R., Dahlin M., Vin H., and Kay J.. Beyond Hierarchies: Design Consideratens for Distributed Caching on the Internet, in proceedings of the 19th International Conference on Distributed Computing Systems, Austin, Texas June 1999. IEEE. [TRE93] Treese Win, The Internet Index, December 16, 1993, available at: http://www.eff.org/Net_culture/Statistics/internet_index_7-8-93.index last access: 12/10/2001. [VAL98] Valko Andras G., Cellular IP A Local Mobility Protocol, IEEE 13th Annual Computer Communications Workshop, Oxford, Mississippi, October 1998. [VEI97] Veizades J., Guttman, Perkins, C. and Kaplan, S., Service Location Protocol, RFC 2165, June 1997. [W3C01] W3C, Device profiles, 2001, available at: http://w3development.de/rdf/ uaprof_ repository last access: 10/19/2003.

PAGE 106

95 [WAN99] Wang Jia, A Survey of Web Caching Schemes for the Internet, ACM Computer Comm.Rev., vol.29,no.5, Pages: 36-46, Oct. 1999. [WEI91] Weiser Mark, The Computer for the 21 st Century, Scientific American, Vol.265, No.3, Pages: 94-104, September 1991; available at: http://www.ubiq.com/hypertext/weiser/SciAmDraft3.html last access: 07/21/2001 [WEI93] Weiser Mark, Ubiquitous Computing, IEEE Computer Hot Topics, October 1993; A variation available at: http://www.ubiq.com/hypertext/weiser/ UbiCompHotTopics.html last access: 07/21/2001. [WES02] Wessels Duane. National Lab of Applied Network Research access logs, 2002, available at: ftp://www.ircache.net/Traces last access: 05/11/2002. [WOL99] Wolman Alec, Voelker Geoffrey M., Sharma Nitin, et al. On the Scale and Performance of Cooperative Web Proxy Caching, 17 th ACM Symposium on Operating System Principles, 1999. [WOR02] Worldcom Inc. Worldcom Latency Statistics, 2002, Available at: http://www1.worldcom.com/global/about/network/latency/ last access: 11/14/2002. [ZHA93] Y. Zhang and B. Bhargava, WANCE: A Wide Area Network Communication Emulation System, in proceedings of IEEE workshop on Advanced in Parallel and Distributed Systems, Pages: 40-45, Princeton, NJ, Oct. 1993. [ZHO99] Zhou Tao, Surfing Web-caching Technologies, October, 1999. available at: http://www.winnetmag. com/Articles/Index.cfm?ArticleID=7199 last access: 08/30/2002.

PAGE 107

BIOGRAPHICAL SKETCH Wenzheng Gu was born in 1972, in Beijing, China. He received his Bachelor of Science degree in computer science from Beijing Polytechnic University in July 1994. He then worked as a programmer in BGD Software Inc. until August 1995. He continued his education and received his Master of Science degree in computer science from the graduate school of Beijing Polytechnic University in August 1997. He worked as a System Engineer in the Network Department and E-business Department of IBM China. In the fall of 1999, he joined the Department of Computer and Information Science and Engineering at the University of Florida, Gainesville, to pursue his Doctor of Philosophy degree under the direction of Dr. Sumi Helal. His research experience and expertise include Internet computing, mobile computing, and pervasive computing. 96