Exploiting Result Equivalence

in Caching Dynamic Web Content

Ben Smith, Anurag Acharya, Tao Yang, and Huican Zhu

Department of Computer Science, University of California

Santa Barbara, CA 93106

Abstract

Caching is currently the primary mecha-nism for reducing the latency as well as band-width requirements for delivering Web con-tent. Numerous techniques and tools havebeen proposed, evaluated and successfullyused for caching static content. Recent stud-ies show that requests for dynamic web con-tent also contain substantial locality for iden-tical requests. In this paper, we classify local-ity in dynamic web content into three kinds:identical requests, equivalent requests, andpartially equivalent requests. Equivalent re-quests are not identical to previous requestsbut result in generation of identical dynamiccontent. The documents generated for par-tially equivalent requests are not identicalbut can be used as temporary place hold-ers for each other while the real documentis being generated. We present a new pro-tocol, which we refer to as Dynamic ContentCaching Protocol (DCCP), to allow individ-ual content generating applications to exploitquery semantics and specify how their resultsshould be cached and/or delivered. We illus-trate the usefulness of DCCP for several ap-plications and evaluate its e�ectiveness usingtraces from the Alexandria Digital Libraryand NASA Kennedy Center as case studies.

1 Introduction

As many Web sites evolve to provide so-phisticated e-commerce and personalized ser-vices, dynamic content generation becomesmore popular. Using multi-processor orcluster-based servers can speedup resource-intensive dynamic content generation [6, 12,24]. If successful, caching can provide sig-

ni�cant additional bene�t by reducing serverload, end-to-end latency and bandwidth re-quirement. Numerous techniques and toolshave been proposed, evaluated and deployedfor caching static content. There has beenrecent interest in caching dynamic Web con-tent as well [5, 7, 10, 14, 16]. Dynamic contenthas three forms of locality: identical requests,equivalent requests, and partially equivalentrequests.

� Identical requests: These requestshave identical URLs which result in thegeneration of the same content. Recentstudies [14, 16] have shown that this lo-cality can be successfully exploited forcaching.

� Equivalent requests: The URLs ofthese requests are syntactically di�er-ent but result in generation of identi-cal content. For example, map servers(e.g. [13, 23]) frequently impose a grid onthe coordinate space and return the samemap when presented with any locationwithin a given region in the grid. As an-other example, news servers may wish toreturn di�erent front-pages for requestsfrom users from di�erent regions or dif-ferent sites. In this case, requests fromall clients in a group are equivalent.

� Partially equivalent requests: Theserequests are syntactically di�erent butresult in generation of content whichcan be used as a temporary place-holderfor each other. For example, docu-ments which are conditionally distilledto a lower-resolution version by a service(e.g., TranSend [12]) can be used as aplace-holder for the originals. As anotherexample, maps(e.g., MapQuest [13]) andaerial images (e.g., the TerraServer [17])

with more than a given degree of overlapcould be used as placeholders for eachother.

Exploiting similarity between dynamicdocuments has been shown to be bene�cialfor fast Web page delivery based on delta-encoding [4, 15, 18]. In this paper, we presenta new protocol, which we refer to as the Dy-namic Content Caching Protocol (DCCP), toallow individual content generating applica-tions (e.g. CGI applications, Java servletsetc) to specify equivalence between di�erentGET-based requests they serve. This infor-mation can be used by web caches to ex-ploit these additional forms of locality. Iden-tical requests and equivalent requests can di-rectly ful�lled using previously cached re-sults. For partially equivalent requests, pre-viously cached content can be immediatelydelivered as an approximate solution to theclient while actual content is generated anddelivered. This allows clients to browse par-tial or related or similar results promptlywhile waiting for more accurate information.

We have designed DCCP using the exten-sion mechanism provided in HTTP 1.1 cachecontrol directives [11]. This has several ad-vantages. First, specifying result equivalenceinformation as an extension of the HTTPheader allows DCCP to be deployed incre-mentally | servers, proxies and individualcontent generating applications can be up-graded individually. In many cases, exist-ing CGI scripts can be upgraded to gener-ate these headers simply by using a shortPerl or shell script as a wrapper. Second,since HTTP 1.1 speci�es that headers mustbe propagated by compliant caches, DCCPdirectives can be expected to reach mostcaches. Finally, a declarative header-basedspeci�cation of caching requirements allowsvalue-added proxies such as TranSend [12] tocompose server-provided directives and hintswith their own. For example, the TranSendproxy provides a distillation service for het-erogeneous clients. A distilled version of aweb document is a lower-resolution (or a sum-mary) version of the original and can be re-turned in response to a request for the origi-nal document. Since this functionality is pro-vided by an intermediate node, the ability toaugment and compose cache control speci�-

cations allows the results of such processingto be e�ectively cached by web caches closerto the client.

This paper is organized as follows. We�rst summarize the related work and thenpresent a description of DCCP. We illus-trate its utility for a variety of applica-tions including a customizable news service, alocation-dependent weather information ser-vice, server-side image maps, and a geograph-ically indexed digital library. Finally, wediscuss our current cache design and imple-mentation for DCCP and evaluate the ef-fectiveness of DCCP using real traces fromthe Alexandria Digital Library and NASAKennedy Center and a synthetic trace for aweather forecast application.

2 Related Work

Exploiting similarities between dynamicdocuments generated by multiple invocationsof the same web application was �rst pro-posed in [4, 15] for delta-encoding. This ideawas explored further by Mogul et al. [18] asquery clustering. They analyzed web proxyand packet-level traces to evaluate the ex-tent of similarity between dynamic docu-ments with the same \URL pre�x" (usuallyidentifying the generating application) butdi�erent su�xes (usually arguments to thegenerating application). They found thatthere is substantial locality in \URL pre�xes"{ the 100780 distinct dynamic content re-quests in their proxy trace were based on just12004 pre�xes. They also found that exploit-ing such similarities in delta-encoding can of-fer signi�cant performance advantages. TheDRP protocol [21] uses a checksum algorithm(e.g. MD5) to identify �le equivalence andavoid unnecessary �le download if checksumvalues do not change. These proposals placethe responsibility of creating equivalence (orpartial equivalence) classes on a caching agentand a server, with little or no support fromthe applications. DCCP, on the other hand,allows individual web applications to explic-itly specify equivalence between di�erent doc-uments they generate, which can help delta-encoding in identifying similar documents.

The idea of partial result delivery has been

considered by Dingle et al. [9]. They proposethat a caching agent could send previouslycached data to a client so she/he could browsean old version while current data is beingfetched. Optimistically transferring poten-tially out-of-date data to reduce end-to-endlatency is also considered by Banga et al. [4]in delta-encoding. In this work, they pro-pose sending the cached version of a dynamicdocument to the requesting agent (client orthe next level proxy) while a delta is be-ing fetched. DCCP lets application usersexplicitly de�ne partial equivalence betweenthe cached results and a new query and wecan utilize the infrastructure of [9] or [4] toachieve partial result delivery in the imple-mentation of a DCCP-aware caching agent.

Cao et al. [5] propose that a piece of Javacode (a cache-applet) be attached to each dy-namic document. This code is run whenevera request is received for a cached document.Cache applets can rewrite the cached docu-ment, return the cached document or directthe cache to refetch or regenerate the docu-ment. This approach, referred to as ActiveCache, is extremely exible and can be usedto maintain consistency in an application-speci�c manner as well as dynamically modifyexisting documents. However, the exibilityof Active Cache comes with a price. It re-quires starting up a new Java process (vir-tual machine or compiled code) for every re-quest. Keeping track of result equivalence re-quires creation and maintenance of a pattern-matching network. Since the cache-appletfor each document is independent (for secu-rity reasons), cache-applets used to imple-ment result-equivalence-based caching wouldneed to save and restore its pattern-matchingnetwork to persistent storage. Depending onthe access pattern, this can be a signi�cantperformance limitation. In contrast with thegenerality of Active Cache, DCCP is morerestrictive. The trade-o� is that this de-sign simpli�es implementation and providesopportunities for optimization. The limitedscope and the declarative nature of the DCCPdirectives alleviates security concerns. Us-ing a single global pattern-matching networkallows processing for related patterns to beshared. Finally, since the structure and thefunction of the pattern-matching network isknown to the cache, it can maintain portions

of the network in memory.

Iyengar et al. [16, 7] propose that cacheservers export an API that allows individ-ual applications to explicitly cache and in-validate application-speci�c content. Thesetechniques are developed for caching iden-tical requests at original content providersand may not be feasible for proxy or clientcaches. These techniques can be integratedwith DCCP when DCCP is deployed atserver-sites.

In previous research, we have consideredcooperative caching for dynamic web contenton a cluster of servers [14]. The research focusis to study how clustered nodes collaboratewith each other in terms of caching and theTime-To-Live method is used for maintain-ing result consistency. However, this workuses complete URLs as names for documentsand has no notion of equivalent or partiallyequivalent requests.

Douglis et al. [10] propose that serversshould make the structure of a dynamic doc-ument available to caches and that cachesshould construct the desired document on de-mand. The idea is that a dynamic documentbe speci�ed as a static part, one or more dy-namic parts and a macro-based template thatcombines them. The static parts and thetemplate can be cached whereas the dynamicparts are fetched anew for every request.

3 The Dynamic ContentCaching Protocol (DCCP)

The goal of DCCP is to let web applicationsexploit query semantics and specify equiva-lence or partial-equivalence between the dy-namic documents they generate. DCCP hasbeen de�ned using the extension mechanismprovided in HTTP 1.1 cache control direc-tives [11]. Figure 1 presents the proposed di-rectives (see Section 4 for examples). Eachdocument can contain one or more equiva-lence directives. Each equivalence directivespeci�es the set of requests that this docu-ment can be used to ful�ll. The set of re-quests is speci�ed using a pattern over theset of arguments embedded in the URL, clientcookies, and the domain name and IP address

directive := eq result | sim resulteq result := equivalent result =conditionsim result := partial result= conditioncondition := arg = pattern | (arg = pattern) op conditionarg := domain | IP address | �eld name | cookie namecookie name := cookie:�eld nameop := \&&" | \||"pattern := range | regexprange := [number, number]regexp := \Perl syntax"

Figure 1: DCCP syntax for specifying equivalence directives. Field names are those argumentnames in a GET-based query.

of the machine from which the query is orig-inated. There is no authentication require-ment implied in these arguments { caches im-plementing DCCP are expected to providebest-e�ort values for these arguments.

The language used to specify the equiva-lence patterns provides equality for all argu-ments and range operators for numeric ar-guments. For example, \[0.0,100.0]" speci-�es any real number between and including0 and 100. Patterns can be composed us-ing logical operators (\&&" stands for \and"and \jj" stands for \or"). The current ver-sion of DCCP also includes regular expres-sions over alphanumeric and special charac-ters for string arguments as an experimentalfeature. We use Perl syntax [22] for regu-lar expressions. Note that a directive neednot specify values for all arguments. When acache agent (e.g. a proxy server) receives a re-quest, it extracts the application argumentsfrom the URL, and the identity argumentsfrom request header as well as the identityof the requesting machine. Note that DCCPhas been designed for handling GET-basedqueries.

Since dynamic documents are generatedon demand, they usually have greater con-sistency requirements than static documents.HTTP 1.1 provides several cache control di-rectives to manage consistency. The cur-rent version of DCCP does not propose ad-ditional directives for this purpose. We be-lieve more experience with dynamic docu-ments is needed to determine the set of com-monly used consistency requirements. If nec-essary, we could add directives to specify op-tions such as polling periodically. The main

problem with detailed consistency directivesis that a proxy may not implement the di-rectives which can result in incorrect resultsbeing delivered to clients. Thus our currentfocus is to support the class of applicationswhich can bene�t from DCCP with the exist-ing HTTP 1.1 consistency mechanisms.

4 Applications

In this section, we illustrate how DCCP canbe used to specify result equivalence for a va-riety of content generating applications.

Alexandria Digital Library: The Alexan-dria Digital Library (ADL) [3, 20] providesgeo-spatially-referenced access to largeclasses of distributed library holdings.Current ADL collections contain morethan 7 million entries of maps, satelliteimages, aerial photographs, text docu-ments, and scienti�c data sets. Each entryhas geographical extent represented asa minimum bounding rectangle in longi-tude and latitude and is spatially indexed.Queries used in the current version of ADLlook like this: GET /cgi-bin/draw map?

lat=36.81818181&lon=-115.45454545&

ht=75.0&wd=180.0 HTTP/1.1.

Consider the scenario where the ADLserver knows that the maps it is serving havea limited resolution. In that case, it can usethe DCCP equivalence directives to de�ne re-gions contained in the same map as equiva-lent. For example, for the above query, itcould reply:

HTTP/1.1 200 OK

Server: Swala/1.8a

Content-type: text/html

Cache-control:

equivalent result=``lat=[36,37]&&lon=

[-115,-116]&&ht=[74,76]&&wd=[179,181]''

The caching agent would associate this pat-tern with the map. If a subsequent requestis received with arguments that match thispattern, the caching agent can return thatresult instead of calling the application andre-executing the request. We evaluate the im-pact of using DCCP for ADL dynamic con-tent requests in Section 6.1.

Server-side image maps: Image maps [19]are used to provide intuitive and attractivelabels for web links. Server-side image mapsconsist of images that is embedded in a webpage. When a user clicks on a portion ofthe image, the browser submits a GET re-quest to the server and which includes thescreen coordinates as parameters. Client-side image maps can also be used to trans-late coordinates within simple image regionsinto appropriate HTML links. A client-sitebrowser does such a translation and thusclient-site image maps are preferable in termsof performance. However, server-side imagemaps are useful in cases where the imagemap is too complicated for a client-side im-age map or a server needs to process clickedscreen coordinates. There are a numberof high volume sites including latimes.com,and washingtonpost.com use the server-siteimage maps.

The typical number of regions on an im-age map is fairly small (e.g., from �ve to �f-teen) while the possible number of coordi-nates is usually at least two orders of mag-nitude greater. Specifying result equivalencefor all coordinates using DCCP can signi�-cantly improve the performance of server-sideimage maps. A cache without equivalencematching would be required to store all com-binations of coordinates to generate a signif-icant number of cache hits. With DCCP, theequivalent result already present in a cachecan be identi�ed without involving the server.We evaluate the impact of using DCCP forimage maps in Section 6.2.

Weather Service: Weather servers use dy-namically generated content to provide up-

to-date weather information for the requestedlocation. Typically location information, zipcode or city name, is encoded in the re-quest URL. Such requests, however, can beoverly precise. Twenty zip codes mighthave the same weather information, but sincetheir URLs are di�erent, a cache with nosupport for result equivalence would requiretwenty cache entries to provide complete cov-erage. With DCCP, a weather server canspecify that the same page should be re-turned for all requests in the same region.Figure 2 provides an illustration for zip-codes in and around the University of Cal-ifornia, Santa Barbara. The request is GET

/cgi-bin/weather.cgi?zip=93101 HTTP/1.1.

HTTP/1.1 200 OK

Server: Swala/1.8a

Content-type: text/html

Cache-control: equivalent result=

``zip=93111||zip=93106||zip=93117''

Figure 2: DCCP directives for a weather ap-plication

Customized news services: There are sev-eral forms of customized news services. Thesimplest of these customize the content basedon the location of the requesting clients. Thisis similar to the di�erent editions that news-papers publish targeting speci�c regions. Forsuch a scenario, all requests for a news pagefrom the same geographical region (or Inter-net domain) would be equivalent. For exam-ple, all clients from .uk machines would bepresented with United Kingdom speci�c newsstories. The �rst time the page is accessed,the server must run the application to gener-ate the customized web page; subsequent re-quests for the same page from machines witha .uk domain name can be serviced from thecache. The DCCP directive for this case ispresented in Figure 3.

News services with greater degree of cus-

HTTP/1.1 200 OK

Server: Swala/1.8a

Content-type: text/html

Cache-control: equivalent result=

`` domain=*.uk''

Figure 3: DCCP headers for a UK-speci�cweb page

HTTP/1.1 200 OK

Server: Swala/1.8a

Content-type: text/html

Cache-control: equivalent result=``sports=yes&&clinton=yes&&movies=yes''

Cache-control: partial result=``sports=yes&&clinton=yes''

Cache-control: partial result=``sports=yes&&movies=yes''

Cache-control: partial result=``clinton=yes&&movies=yes''

Figure 4: DCCP directives for a user-pro�le-speci�c web page

tomization could use previously stored pro-�les to customize the news contents for in-dividual users. Such a service can facilitatecaching of its documents by marking docu-ments generated for users with identical pro-�les as equivalent and documents generatedfor users with substantially overlapping pro-�les as partially-equivalent. Figure 4 providesan illustration.

5 Design of a DCCP-awarecache prototype

The primary challenge for the design andimplementation of a DCCP-aware cachingagent is to be able to e�ciently main-tain and use information about equivalenceand partial equivalence of cached documents.We have developed a multi-stage pattern-matching network for this purpose based onthe Swala cooperative web cache [14]. In thissection, we describe the structure of this net-work and how the insertion and search oper-ations are implemented.

In the DCCP model, each application spec-i�es its result equivalence independently. Asa result, a dynamic document generated byan application can be speci�ed to be equiv-alent only to other documents generated bythe same application. Accordingly, our proto-type maintains a separate pattern-matchingnetwork for every application. Each applica-tion is identi�ed by its net-path-name. Thenet-path-name for a URL consists of thelongest pre�x that contains no arguments.Our prototype uses a hash table (with net-path-names as keys) to quickly retrieve thepattern-matching network corresponding to aURL.

We discuss how we can build an e�-cient pattern matching network for each

application with the same net-path-nameas follows. In general a pattern matchingrule can be transformed into a sequenceof conjunctive pattern phrases connectedby logical OR. For example, pattern"map=USA&&lat=[34,37]&&lon=[-119,-117]

jjmap=USA&&city=foo" contains two conjunc-tive phrases. Given a set of conjunctivephrases derived from the same rule or fromdi�erent rules, we partition them into a setof clusters and each cluster has conjunctivephrases with the same argument namesused in their exact match and range matchpatterns (discussed below). For example,two pattern phrases ``map=USA&&zip=93111''

and ``map=USA&&zip=93016'' are in the samepattern phrase cluster.

We discuss how each pattern cluster ar-ranges its data structure for result matching.Given conjunctive pattern phrases withineach cluster, we classify patterns into threeparts in increasing degrees of complexity andsearching within each cluster contains threestages:

� Exact match. All patterns are of formargument=val. These patterns can behashed together. Searching within thiscluster can start from the correspond-ing hash table so that only results sat-isfy those exact match patterns are can-didates for further searching.

� Range match. All patterns are of formargument=[val1, val2]. Searching fora result under these conditions is sim-ilar to the problem of point intersec-tion searching [2]: given a set of ob-jects speci�ed with multi-dimensional in-tervals, �nd an object that contains aquery point. In our current implementa-tion, we have used the R*tree data struc-ture to group all such range match pat-terns together.

� Complicated string match. Allpatterns are of form argument=

regular expression pattern. Thesepatterns contain complicated stringmatching and so far we have not founda good way to organize a set of suchpatterns for e�cient searching. Ourcurrent solution is to linearly scan suchrules to �nd one result that matchesthese string matching patterns.

Thus the �rst stage of searching within eachcluster is to use a hash table to narrow thesearching space, i.e. �nd potential resultswhich satisfy all exact match conditions. Thesecond stage of searching is to use a pointintersection data structure to further narrowthe searching scope. The last stage of search-ing linearly scans all candidate results afterthe above two-stage �ltering.

Each pattern network for an applicationwith the same net-path-name consists of alayered graph with a single designated rootnode. Each child of this root node is a sub-graph corresponding to each pattern cluster.Each cluster subgraph contains a hash tablefor exact match patterns and data structuresfor range match patterns. The cached dy-namic documents constitute the leaves of thisgraph. A dynamic document is attached to anode in the graph if and only if the sequenceof tests occurring on the path from the root tothis node successfully satis�es all conditionsspeci�ed by the DCCP rule of this document.Note that since each document can have mul-tiple DCCP directives and since each direc-tive can have multiple conjunctive-phrases, acached document can be associated with mul-tiple interior nodes in the pattern-matchingnetwork.

When a new DCCP-annotated dynamicdocument is inserted into the cache, thecaching agent extracts the DCCP directivesand the URL of the request that generatedthe document. It parses the URL to ex-tract the net-path-name for the request anduses it to �nd the root of the associatedpattern-matching network. It parses theDCCP directives and transforms them intoa set of conjunctive-phrases and inserts eachconjunctive-phrase into the network. Sincecached dynamic documents may become staleand the rule for the same URL may change,

the pattern network needs to be updated pe-riodically.

When a new URL query arrives from aclient, the prototype parses the URL to ex-tract net-path-name for the request and usesit to �nd the root of the associated pattern-matching network. It then extracts the ar-guments from the URL and the cookies fromthe header. It also extracts the IP addressof the requesting machine by querying thesocket structure and does a reverse lookup todetermine the domain name of the request-ing machine. It then uses these values to per-form tests against the pattern-matching net-work. Notice only some of query parametersrequired by the network are extracted for thematching purpose. If the match is success-ful, that is, the match operation reaches thenode corresponding to a valid cached docu-ment, the corresponding document is deemedequivalent to the one requested by the clientand is returned in response to the query. No-tice that there may be multiple cache entriesmatching a new query and the system returnsthe �rst matchable cache entry it �nds.

Our above optimization is targeted at rulesthat mainly use exact match or range pat-terns. It is possible that for complex patterns(particularly those making liberal use of reg-ular expressions), trying to determine resultequivalence could take an inordinately longtime. To handle this case, we suggest thatthe system should limit the amount of timespent searching for a single request. Since re-sult equivalence is only a hint, terminatingthe search early and fetching a new copy ofthe document from the server is safe.

For implementing progressive delivery ofpartially-equivalent results, we can use themultipart/x-mixed-replaceMIME type, amechanism available in the Netscape browserfor providing continuously updatable webpages. The previous work has used that fordelivering stale data [9].

6 Evaluation

To measure the space and time e�ciencyof equivalence matching, we performed testsfor the following three applications: map de-livery with boundary error tolerance, infor-

mation retrieval based on server-side imagemaps, and providing weather forecast basedon zip code. We use real traces for the �rsttwo applications and a synthetic trace forweather forecast.

The goal of our evaluation was to esti-mate the performance improvement, if any,for DCCP-aware caching agents. For this, wemainly used two metrics: cache hit ratio andthe volume of communication between thecaching agent and the content provider (if thisinformation is available). These metrics allowus to run repeatable experiments and to focuson the inherent performance improvements {independent of the network characteristics.In the ADL experiment, we also measuredthe end-to-end performance to demonstratebene�ts in terms of response time reduction.

In these experiments, we ran a DCCP-aware proxy on a 248MHz, 128MB Sun Ultra-30 with Solaris 2.6. All the code was compiledwith gcc -O.

6.1 Alexandria Digital Libraryweb trace

In this experiment, we tried to estimatethe performance improvement that can beachieved by using DCCP for spatial im-age searching and retrieval requests in theADL system [3]. We have used an ADLuser access trace for September and Octo-ber 1997. This trace contains 69,337 re-quests and there are 28663 requests involvingCGI. Of those dynamic requests, 21,545 werecgi-bin requests invoking one of two scripts:draw map and map-gif. These scripts re-turn portions of maps, based on the param-eters which include central-latitude, central-longitude, height and width. Of those 21545map requests, 7026 requests use an identicalURL to access an ADL startup image withzero latitude and longitude and the remain-ing 14529 requests access maps with di�erentparameter values. We used DCCP equiva-lence directives for those 14529 map requeststo improve the cache hit ratio. We speci�edtwo map areas to be equivalent if the di�er-ence of above four parameters between twomaps is within a speci�ed error tolerance ra-tio (for example, 5% or 10%). Two requestsare identical if the tolerance ratio is 0.

In this experiment, we set up a server atRutgers University in New Jersey and ranboth clients and the DCCP-enabled proxy atUCSB. The clients launch requests sequen-tially based on the trace to the proxy and theproxy can respond quickly if it has cacheddata since they are linked with a local net-work, or it fetches data from Rutgers. Theround-trip latency between UCSB and Rut-gers was around 82 milliseconds, measuredby using \ping". The server at Rutgers doesnot have the ADL data installed, and it em-ulates the real ADL server at UCSB by exe-cuting each CGI request with processing timeand result size same as what the UCSB ADLserver would have. This experiment assumesthat the server is fast enough to handle con-current requests and it does not consider loadimpact among simultaneous requests. Theexperiment was conducted at midnight whenInternet tra�c is relatively stable and the av-erage results are reported by running this ex-periment multiple times. There are minorvariations among di�erent runs; however, thedeviation is fairly small.

The server processing time for each requestwas measured in 1997 [14]. At that time,we replayed the log against the ADL serverto measure the response time and responsesize of each request. Considering today's ma-chines can be 3-fold faster than the ADLserver machine used in 1997, we have scaleddown the request processing time accordinglyin this experiment. The average processingtime for all 28663 dynamic requests is about0.5 seconds. The average processing time forall map requests (21545) is 169 ms while itis 162 ms for those 14529 requests whose re-sults include the DCCP headers. The reasonfor the large di�erence in the average timebetween all dynamic requests and all map re-quests is that there are a certain number ofADL requests involving time-consuming spa-tial database searching.

Table 1 shows the bene�ts of equivalencecaching for processing all dynamic ADL re-quests in this trace. The table shows that forexact matches, a 38.6% cache hit is achiev-able and this is because there are a large num-ber of repeated requests with identical URLs.If the application can tolerate a 5% or 10%relative error, the hit percentage increases to57.1% and 64.5% respectively. The total size

Error tolerance 0% 5% 10%

Number of cache hits 11074 16370 18482Cache hit percentage 38.6% 57.1% 64.5%Saved communication 48MB 65.2MB 75MBPercent reduction in communication 41.5% 56.3% 64.8%Ave. response time for a cache hit 4.8 ms 4.5 ms 4.4 msAve. response time for a cache miss 773 ms 852 ms 958 msAve. response time per request 476 ms 368 ms 340 ms

Table 1: Impact of result equivalence on cache performance when all dynamic requests areconsidered.

of data shipped in this trace is 115.6MB andthe forth and �fth rows show the server-proxycommunication volume saved due to the de-ployment of DCCP. The sixth row is the av-erage request response time (from a clientlaunches a request until it receives a result)for those requests whose results are fetchedfrom the proxy cache at UCSB. The sev-enth row is the average request response timefor those requests whose results are fetchedfrom the Rutgers server due to cache misses.The eighth row is the average request re-sponse time for all dynamic requests. The re-sults show that DCCP with tolerance 10% is40% faster than only caching results of identi-cal requests in terms of the average responsetime. If tolerance 5% is used instead, then itis 29.3% faster.

Now we focus on those map requests whosereturn results use the DCCP directives andthere are 14529 such requests. Table 2 showsthe bene�ts of equivalence caching and costincurred due to the use of DCCP in process-ing those map requests. The table shows thatfor exact matches, only a 13.6% cache hit isachievable. If the application can tolerate a5% or 10% relative error, the hit percent-age increases to 49% and 62% respectively.The total size of data shipped for these re-quests is 61.3MB and the forth and �fth rowsshow the server-proxy communication volumesaved due to the deployment of DCCP. Thesixth row is the average request response timefor all those map requests. The average costfor pattern matching network managementand equivalence searching varies from 4.4 to4.8 milliseconds per request while the mem-ory usage for the entire pattern-matching net-work varies from 330KB to 900KB.

The performance improvement achieved byDCCP-aware caching agents comes, however,at the cost of additional memory to storethe pattern-matching network. Even thoughthe cost may not be large for many ap-plications (e.g., see Table 2), it is conceiv-able that the memory requirement can growrapidly if su�cient locality is not present inthe request stream. This situation can betaken care of by imposing a bound on theamount of space used for the network. Whenthe caching agent runs out of space for thepattern-matching network, it purged old en-tries using an LRU discipline. To understandthe impact of such a restriction, we conductedadditional experiments in which we limitedthe amount of memory that could be used forholding the pattern-matching network. Ta-ble 3 presents the results. The second row inTable 3 indicates percentage of space avail-able compared to the situation when thereis su�cient space. The third row shows thecache hit ratio under di�erent space avail-ability and error tolerance ratios. The resultshows that this trace still has very good tem-poral locality and a high hit percentage canbe maintained even when only half of the re-quired space is available.

6.2 NASA Kennedy Space Centerweb trace

In this experiment, we tried to estimatethe performance improvement that can beachieved by using DCCP for server-side im-age maps. For these experiments, we used atrace from the NASA Kennedy Space Cen-ter WWW server in Florida [1] to quantifythe bene�t of equivalence matching for im-age map type workloads. The trace contains

Error tolerance 0% 5% 10%

Number of cache hits 1975 7146 8959Cache hit percentage 13.6% 49% 62%Saved communication 7.9MB 26.MB 37MBPercent reduction in communication 12.8% 46.6% 60.3%Ave. response time per request 346 ms 217 ms 156 msAve. cache search/insert overhead 4.8ms 4.5ms 4.4msMemory usage 900K 450K 330K

Table 2: Impact of result equivalence on cache performance for those DCCP-deployed requests.

Error tolerance 0% 5% 10%

Percent space available 100% 80% 50% 100% 80% 50% 100% 80% 50%

Cache hit ratio 13.6% 12.8% 12.3% 49% 46% 45% 62% 58% 56%

Table 3: Impact of limited memory for the pattern-matching network.

1,569,898 requests, of which 20,925 are for theimage map countdown69. We removed in-valid requests, for a total of 20,774 requests.Image maps transmit the coordinates wherethe client clicked back to the server script,which translates the coordinates to a URLor returns a result. We have plotted the hitpattern in Figure 5. For each point that wasclicked a hollow circle was plotted. The re-gions that have solid black areas are wheremultiple clicks occurred and correspond tobuttons on the image map. Each buttonmaps to the same URL, while points that donot fall into a button area result in an er-ror message from the script. The image mapcountdown69 has eleven buttons, as can beseen from the heavy concentration of dots ineleven regions. The scattering of dots out-side of the buttons are clicks which do notcorrespond to buttons and result in an errormessage. We de�ne each button as an equiva-lent region, as well as the error message as anequivalent region, resulting in twelve distinctregions on the image map.

Using standard URL matching results in acache hit of 15,592 hits, and a 75.1% hit ra-tio. Using result equivalence for all pointsin the same region, the hit ratio increases to99.9% or twelve cache misses, one for eachregion. The searching time and space cost isinsigni�cant for this case because there areonly twelve unique results and there are onlytwelve unique rules one per dynamic docu-ment.

It should be noted that for this trace, usingclient-site imagemaps can achieve the samegoal as DCCP; nevertheless, this experimentdemonstrates the e�ectiveness of DCCP ifserver-site images are deployed.

6.3 Weather forecast based on zipcode

For this experiment, we generated a syn-thetic trace. We assume that the total num-ber of zip codes is 99999 and this numberis chosen based on the fact that a zip codein the U.S. has �ve digits. There are about3143 counties in USA and for this test we as-sume that zip codes are randomly distributedamong counties and each county in USA hasthe same weather condition within the sametime period. In terms of access patterns ofour synthetic trace, we assume a Zipf distri-bution [25, 8]. While we do not have evidenceto support this assumption, we believe it ismore realistic than a uniform distribution.

For a randomly generated trace with500,000 requests, the average searching andnetwork management cost is 0.12 millisec-onds with a hit ratio of 99%. The reasonfor small time overhead is that there is asingle application with one argument name(zip code). Hashing e�ectively indexes all zipcodes, which allows for fast searching. Thespace usage is 1.6MB for indexing all 99999zip codes in the pattern matching network be-cause each rule enumerates all equivalent zip

0

50

100

150

200

250

300

350

400

0 100 200 300 400 500

Figure 5: Hit pattern for /cgi-bin/imagemap/countdown69 from the NASA trace. The hol-low points correspond to coordinates where users clicked on the original image map. Boxescorrespond to buttons on the original image.

codes for the corresponding result. Imposinga limit on space consumption does not de-grade the cache hit ratio much because thereare actually only 3143 unique results.

7 Concluding remarks

The primary contribution of this work isthe DCCP protocol which allows a web appli-cation to specify result equivalence betweenthe di�erent documents (and groups of doc-uments) it generates. This information canbe used by proxies and other caching agentsto speedup delivery of dynamic web content.We have illustrated the utility of this proto-col for several applications and preliminaryexperiments indicate that the protocol is ca-pable for achieving high cache hit ratios withfairly small space and time overhead.

DCCP can be extended to express morecomplicated patterns (e.g. inequality) and afew directives can be further added to the cur-rent DCCP for supporting basic features suchas banner rotation and access logs, which arenecessary for commercial Web sites [5]. Still,

compared to Active Cache, the functionalityof such a declarative protocol is more restric-tive. The trade-o� is that the declarative andlightweight nature of this caching protocol al-lows simpli�ed security control and better ef-�ciency.

We have not evaluated bene�ts of using ourprotocol for sending partially equivalent re-sults and this issue needs to be addressedin the future. Under our current protocolimplementation, searching equivalent resultswith complicated string matching rules canbe time-consuming and caching may be lesse�ective if imposing a searching time limit.One possibility is to restrict the use of stringmatching. Our current DCCP design is tar-geted at GET-based queries and there are alarge number of dynamic requests which usePOST-based queries. We plan to study theabove issues after we gain more applicationexperience with DCCP.

Acknowledgments. This work was sup-ported in part by NSF CCR-9702640, IIS-9817432. We would like to thank FredDouglis and anonymous referees for their de-tailed comments and thank K V Ravi Kanthand Ambuj Singh for providing their R* tree

code.

References

[1] ACM SIGCOMM. The Internet Traf-�c Archive. http://ita.ee.lbl.gov/index.html,Mar 1999.

[2] P. K. Agarwal and J. Erickson. Geo-metric range searching. In Advances inDiscrete and Computational Geometry (B.Chazelle, J. E. Goodman, and R. Pollack,editors), pages 1{56. Contemporary Mathe-matics 223, AMS Press, 1999.

[3] D. Andresen, L. Carver, R. Dolin, C. Fis-cher, J.Frew, M. Goodchild, O.Ibarra,R. Kothuri, M. Larsgaard, B. Manjunath,D. Nebert, J. Simpson, T. Smith, T. Yang,and Q. Zheng. The WWW Prototype of theAlexandria Digital Library. Proceedings ofISDL'95: International Symposium on Dig-ital Libraries, Aug. 1995.

[4] G. Banga, F. Douglis, and M. Rabinovich.Optimistic deltas for WWW latency reduc-tion. In Proc. of USENIX'97, pages 289{303, Jan. 1997.

[5] P. Cao, J. Zhang, and K. Beach. ActiveCache: Caching dynamic contents on theweb. In Proc. of Middleware'98, pages 373{388, 1998.

[6] J. Challenger, P. Dantzig, and A. Iyengar.A Scalable and Highly Available System forServing Dynamic Data at Frequently Ac-cessed Web Sites. In Proc. of SC'98 (HighPerformance Networking and Computing.Formally known as SuperComputing), Nov.1998.

[7] J. Challenger, A. Iyengar, and P. Dantzig.A scalable system for consistently cachingdynamic web data. In Proc. of IEEE INFO-COM'99, Mar. 1999.

[8] M. E. Crovella and A. Bestavros. Self-Similarity in World Wide Web Tra�c: Ev-idence and Possible Causes. In Proc. ofACM SIGMETRICS Inter. Conf. on Mea-surement and Modeling of Computer Sys-tems, Apr. 1996.

[9] A. Dingle and T. Partl. Web cache coher-ence. In Proc. of Fifth International WWWConference, May 1996.

[10] F. Douglis, A. Haro, and M. Rabinovich.HPP: HTML macro-preprocessing to sup-port dynamic document caching. In Proc.of USENIX Symp. on Internet Technologiesand Systems, pages 83{94, Dec. 1997.

[11] R. Fielding, J. Gettys, J. Mogul, H. Frystyk,L. Masinter, P. Leach, and T. Berners-Lee.Hypertext Transfer Protocol { HTTP/1.1.Network Working Group RFC 2616, June1999.

[12] A. Fox, S. Gribble, Y. Chawathe, E. Brewer,and P. Gautheir. Cluster-based network ser-vices. In Proc. of 16th ACM Symposiumon Operating System Principles (SOSP'97),pages 78{91, Oct. 1997.

[13] GeoSystems Global Corpora-tion. The MapQuest Home Page.http://www.mapquest.com, 1999.

[14] V. Holmedahl, B. Smith, and T. Yang.Cooperative caching of dynamic contenton a distributed web server. In Proc. ofSeventh IEEE International Symposium onHigh Performance Distributed Computing(HPDC-7), pages 243{250, 1998.

[15] B. Housel and D. Lindquist. Webexpress:A system for optimizing web browsing in awireless environment. In Proc. of 2nd In-ternational Conf. on Mobile Computing andNetworking, pages 108{116, Nov. 1996.

[16] A. Iyengar and J. Challenger. Improvingweb server performance by caching dynamicdata. In Proc. of USENIX Symp. on Inter-net Technologies and Systems, pages 49{60,Dec. 1997.

[17] Microsoft Corporation. The TerraServerHome Page. http://www.terraserver.com,Mar 1999.

[18] J. Mogul, F. Douglis, A. Feldmann, andB. Krishnamurthy. Potential bene�ts ofdelta-encoding and data compression forHTTP. In Proc. of SIGCOMM'97, pages181{94, Sept. 1997.

[19] D. Raggett, A. L. Hors, and I. J. (Eds.).HTML 4.0 Speci�cation. W3C Recom-mendation, http://www.w3.org/TR/REC-html40/, April 1998.

[20] T. Smith. A digital library for geographi-cally referenced materials. IEEE Computer,29(5):54{60, 1996.

[21] A. van Ho�, J. Giannandrea, M. Hapner,S. Carter, and M. Medin. The HTTP Distri-bution and Replication Protocol. Submittedto W3C. http://www.w3.org/TR/NOTE-drp, August 1997.

[22] L. Wall, T. Christiansen, and R. L.Schwartz. Programming Perl. O'Reilly &Associates, Inc., Sebastapol, California, sec-ond edition, Sep 1996.

[23] Xerox PARC. The Xerox Map Viewer.http://pubweb.parc.xerox.com/map, Mar1999.

[24] H. Zhu, B. Smith, and T. Yang. Schedul-ing optimization for resource-intensiveweb requests on server clusters. In Proc.of 11th Annual ACM Symposium onParallel Algorithms and Architectures(SPAA'99), pages 13{22, June 1999.http://www.cs.ucsb.edu/research/rcgi.

[25] G. K. Zipf. Human Behavior and the Prin-ciple of Least E�ort. Addison-Wesley, Cam-bridge, MA, 1949.