Making Web Client Caching Cooperate at LAN Level

Making Web Client Caching Cooperate at LAN Level

Jing-Wen Jin, Silvio Lemos Meira, and Fabio Q. B. da Silva

Departamento de Informática

Universidade Federal de Pernambuco

RECIFE, PE, BRAZIL

[e-mail] , [e-mail] , [e-mail]

Abstract In this paper, we investigate possibilities of making Web LAN-level client caching cooperate. The research was motivated by the fact that since LAN's usually have very high bandwidths, any communication within a LAN can be performed very efficiently. By adopting this caching scheme, much more client requests can be satisfied locally at very high speeds. Besides, external networks, servers and proxies will receive less burden. This work focuses on investigating its feasibility in the context of the Web and comparing the performance of several cooperative caching algorithms from different aspects: hit ratios, local proxy load, local network load and access latency. Performance of each individual client is also evaluated in terms of latency and machine load.

Keywords: WWW, Cooperative Caching, Caching Algorithms

1 Introduction

Ever since the first graphic browser came out in 1994, the WWW has gained an unprecedented growth of popularity due to the convenience of its use and the wide variety of information it provides. As a consequence of this, servers and networks around the world began to receive high loads at hectic times, making users of this whole giant system more and more sensitive to the latency observed. Caching is now well known to be an effective way of mitigating these problems. As the Web developed, caching has also been made to adapt to the environment and to follow the general need. Initially, it was isolatedly implemented on Web spots and much research has gone into developing or analyzing caching systems for some particular sites or levels. Later on, the continuous growth trend of the Web forced researchers to further develop sophisticated caching systems to cater to the present or future demand [1,2,3,4].

Among the existing work, the Harvest caching project [5,2] is no doubt the most prominent one. Now renamed as "Squid" and "NetCache", and being maintained separately by two research groups, Harvest-like caching systems are being implemented in many countries and continents. A worldwide systematical caching mesh has thus emerged on the Web¹. Basically, these systems consist of hierarchies of proxies with options for cooperation, i.e., proxies in a system can communicate with their siblings and/or parents for requested documents. However, the problem with configuring a pair of WAN-level proxies as parent-child or siblings is that, as WAN's usually have low bandwidths, communications between them can be quite slow. In addition, frequent message exchanges among proxies may worsen the neighboring network congestion. Furthermore, although a tree-like hierarchy endures scaling problem to some degree, it can cause serious performance problems when the load becomes excessively high, because the root-proxy might become a bottleneck of the underlying sites. Although the last problem can be somewhat alleviated by replacing the top-level cache with a pointer server [6], augmenting the power of the root machine, or developing a scalable proxy architecture for this level, like the one developed at NCSA for servers [7], these should not be considered first-choice solutions. Until now, we fail to exploit some important resources, which are capable of improving performance of caching systems from their bases.

The Internet, as we know it today, can be mainly described as a collection of sub-networks. Usually, these sub-networks, due to their size restrictions, are able to adopt certain kinds of designs and transmission technologies so as to run at speeds from 10 to 100Mbps, which are much faster than common WANs. Consequently, transmission within a LAN can be performed with extremely low delays. The idea here is to try to exploit LAN-level resources to increase caching performance: by making client caches within a high-bandwidth LAN cooperate, more requests can be satisfied locally almost instantaneously. In addition, external proxies and networks will receive less loads in general.

This study thus aims to investigate issues related to client caching cooperation. The paper is organized as follows. We begin by describing the motivation of our research and discussing its viability in the context of the Web. We then investigate some viable possibilities for it by presenting 4 cooperative caching algorithms in Section 3, describing our evaluation methodology in Section 4 and showing test results in Section 5. We discuss some related work in Section 6 and conclude this paper with some future directions in Section 7.

2 Motivation and Viability

In this section, we describe our motivation for this research and slightly discuss the viability of making client caching cooperate in the context of the Web. However, issues such as privacy and security are left out from our discussion.

2.1 Motivation

Our idea of making client caching cooperate stems both from present advantages and from some foreseeable future applications.

Client-level caching is now ubiquitous: every browser in use such as Netscape and Explorer implements caching. But in current situations, other than their own cache, users can benefit from no one else's, i.e., a user A cannot access a document being stored in user B's cache, even if they are on the same network segment. Although a proxy can be adopted today just for this kind of resource sharing, as this single cache attends requests coming from a group of people, it is unable for it to retain a particular document (unless extremely popular ones) for very long, because arriving documents can rapidly purge existing ones. Therefore, it's quite common that a client holds some documents which the proxy doesn't. We might just increase proxy's cache space to a certain point to eliminate this phenomenon, knowing the cost of disk is becoming less and less expensive. However, as the trend of Internet application is for multimedia, the increasing need for storage space will ultimately balance this cost reduction. At present, it's not uncommon to have hundreds or even over a thousand clients sharing a single proxy. These first-level proxies are usually medium-power machines with hundreds of megabytes on disk devoted to caching. Suppose we have 500 users each with 5MB of disk configured for caching, then adding up all these spaces, we have 2.5GB in total, which is usually several times larger than a single proxy's.

Furthermore, to simply forward whatever request to the local proxy can make it overloaded and add more delays to all requests. With cooperation, the proxy can function as an intermediary by redirecting requests to other clients. Not having to physically offer documents can save the proxy many tasks, and thus make it less subject to burden. In conclusion, we want to exploit not only the cache space of the clients, but the processing capacity of their machines as well.

As to the future applicability of this caching scheme, a few words have to be said. In the field of networking, applications such as video-on-demand have long been subject to great interest. We are certain that this kind of service will ultimately be realized, and buildings connected to the Internet (with domestic equipment accessing digital audio and video) will be in the marketplace in a few years. Certainly, the idea of sharing a video or audio clip stored in a particular house among neighboring homes or buildings, as it will avoid bulks of information from repeatedly fetched from distant servers, will be worth investigating. However, we do not attempt to address this problem in this article.

2.2 Viability

Client caching cooperation requires that client software have the ability of functioning as servers. Technologically, this feature can easily be implemented. The main concern is that, as many Web clients are personal computers not available 24 hours a day, cooperation is restricted to the time intervals when they are turned on. But still, there are a reasonable number of sub-networks on the Internet that keep their computers on all day long. In such environments, client-caching cooperation is surely applicable. The idea may be applied only on a moderate scale today, but as computer networking evolves rapidly, future environments will tend to be more suitable to adopt such caching scheme.

Human factors might also hinder the idea from being widely implemented. People will only be willing to set their browsers to cooperate if cooperation brings de facto advantages to themselves. For this reason, we need to know the quantitative amount of performance improvement that cooperation can offer. This will be the main focus in the rest of this paper.

3 Cooperative Caching Algorithms

The introduction of cooperation raises the issue about the coordination of this new caching level. Many approaches or algorithms can be found in the literature [8,9,10], and new ones can also be thought of. In this study, we choose to analyze 4 algorithms: Direct Client Cooperation, Simple Forwarding, Centrally Coordinated Caching and Hash-Distributed Caching. Simple Forwarding and Central Coordination are previously examined by Dahlin et al. [8] in the realm of distributed file systems². Although an algorithm also called Direct Client Cooperation was presented in their research, it is functionally different from the one in our study. The descriptions of these algorithms are shown below, where we will be describing some foreseeable advantages and drawbacks. In this study, each individual cache adopts LRU to manage local cache space.

3.1 Direct Client Cooperation

The most intuitive approach is to make clients cooperate directly: when a client requests a document which is not cached locally, it multicasts³ a request to all other clients agreeing to cooperate, asking for the document. The document can then be retrieved from the first client who gave an affirmative response. Similar criterion is also adopted by Harvest-like caches [2]; instead of the first client, a Harvest-like cache retrieves a document from the first proxy which gave an answer. In case nobody answers within a certain time interval, the request will be forwarded to the local proxy, if there is one. Two features of this algorithm make it appealing: besides it's simplicity (only client software need to be modified), it minimizes the load imposed on the proxy, because the improvement on client cache hit ratio achieved by cooperation imposes absolutely no extra workload on the proxy. However, client machines are more subject to burden, especially when the client population is large, because each client cache miss necessarily causes a request to all other clients. The algorithm is presented below.

Algorithm 1. Direct Cooperation

3.2 Simple Forwarding

In order to avoid multicasting messages to all users on each local cache miss, the proxy can be elected as an intermediary which maintains a list of the documents cached by the clients (cache state list). When a client requests a document which is not cached by itself, it sends the request to the proxy. The proxy then tries to supply the data from its own cache. Failing this, the proxy checks the state list and forwards the request to the client that caches the document, if there is any. In order not to cause unnecessary access latency and increase the proxy's load, the client receiving the forwarded request passes a copy directly to the client which made the request. In case no registration is found in the state list, the request will then be sent to the remote server, as usual.

This approach requires a state list to be implemented at the proxy side. For performance reasons, it would be nice to keep this list in memory in order to avoid disk accesses in cases of cache lookup. To enable the proxy to keep the exact information about each client's cache state, clients must report to the proxy for every content change made in their cache. This approach resembles that of the CRISP project [11].

Algorithm 2. Simple Forwarding

3.3 Centrally Coordinated Caching

The main drawback with the above algorithms is that as the clients still manage their caches independently, cache space is not used efficiently, because a single document might be duplicated in different caches. In order to reduce chances of unnecessary duplication, one solution is to adopt some kinds of coordination which can effectively control cache space utilization. The natural candidate for this task is the local proxy.

The extreme case is to deprive clients of the right to manage their own caches. Instead, the proxy will coordinate those spaces. Every client request should then go through the proxy. Undoubtedly, this approach optimizes the use of cache space and therefore maximizes the global hit ratio. But in compensation, local cache hit ratio will decrease (thus increasing network and proxy load), because the clients do not maintain their caches according to their own necessities. An intermediary approach is to split client cache space into 2 portions: one of them coordinated centrally by the proxy (central coordination), and the other still managed by the own client (local coordination). Here, we partition the cache at a central/local ratio of 8:2. When a client requests a document which is not found in its locally managed portion of cache, it sends the request to the proxy. The proxy offers the document if it is stored in its own cache. Otherwise, it searches the centrally coordinated cache and forwards the request to the client detected to be the owner of a copy, if there is any. If all these searches fail, the document will be retrieved from its origin server.

Dahlin et al. [8] treated the centrally coordinated cache as the backing store of the server memory, which corresponds to our proxy. When the server needs to allocate space for the newly arrived document, it purges some old documents from its cache and sends them to the centrally coordinated cache. Nevertheless, to transfer all evicted documents from proxy to client caches would cause too much traffic. In order to avoid or minimize this load, we establish that the proxy only holds documents larger than 20KB in its cache, and evicted documents will not be sent to any client cache. Upon arriving from the remote servers, documents smaller than 20KB are sent to central cache (together with a copy to whom made the request via multicast⁴), and stored there for public use. There are two advantages by doing so. First, multicasting does not cause extra local network load. Second, as centrally coordinated cache is in reality located distributedly across different client sites, and Web caching is document-based (with document size ranging widely), to distributedly store documents into cache "slots" (each client cache is like a slot) will cause some kind of fragmentation, because the last portion of each client cache is often too small to store any Web document. Just as small page size can reduce fragmentation in paging systems, caching small documents at client sites can minimize space waste. The algorithm is presented below, where the function Best returns the identity of the client which best fits the document. In case no client has enough space to hold it, the function chooses the client which caches the LRU document. Note that the order with which some of the instructions appear in the algorithm is not necessarily absolute, some of them can be executed concurrently with other instructions.

Algorithm 3. Centrally Coordinated Caching

3.4 Hash-Distributed Caching

Having the proxy centrally coordinate client cache contents is not the only way for the clients to discover previously cached documents which are dispersed across several places. There is a well-known technique for resource discovering - hashing. We can adopt a hash function in a caching system using which clients can identify the appropriate individual who possibly caches a copy of the desired document. In order not to cause too many local cache misses, we also divide a client cache into two portions at a public/local ratio of 8:2, the same as the previous algorithm. The whole caching system works as follows: on a local client miss, the URL of the requested document will be hashed to determine who holds a copy, should this document be cached by anybody in the group. A request is then sent to this potential client. The returned answer might be negative. In such a case, the request will be forwarded to the local proxy. If the document is not cached by the proxy either, it will then be supplied by its origin server. Upon receiving the document, the proxy checks its size⁵ in order to decide whether to cache it in its own cache (when document size is larger than 20KB) or to send it to the public cache (when the size is smaller than 20KB), together with a copy to the client who made the request via multicast.

For simplicity, in this study, we assume that the number of clients is constant since the caching system is initially established. The adopted hash function is classical: URL hash(URL) mod n, where n is the number of the clients. However, in reality, the population on the Internet changes over time, and a change on the domain of the hash function usually causes previously cached items to be hashed to new locations, meaning either these items will become useless because clients will be looking for them in different locations, or it will cause a major traffic problem if the old items are reallocated within the new client domain. For the purpose of minimizing this disorder, Karger et al. [12] investigated possibilities of consistent hashing by defining different "views", where a view is the set of caches of which a particular client is aware. The "smoothness" property of their hash function guarantees that smooth changes in the set of caching machines are matched by a smooth evolution in the location of cached objects. Future study can include this feature.

Algorithm 4. Hash-Distributed Caching

4. Methodology

To evaluate the performance of each algorithm, we conducted trace-driven simulation on real workloads. As current Web browsers lack the implementation for log collection, a client log is rare. Our test will be based on the workloads collected by Cunha et al. [13], which, to our knowledge, is the only client log available to the public.

The original workload consists of requests made by 600 users of the Computer Science department at the Boston University. However, many of these users made only insignificant numbers of requests. We think that as the log was collected soon after the Web came out, when many users rarely knew the system, users might browse a few pages just to have fun or get some basic notion about the WWW. Therefore they cannot be classified as actual Web users. Having this concern, we excluded half of the population who made fewest requests during the log collection. The final log consists of over 280 thousand requests made by 300 users. The first 10% of the log are used to warm up the caches.

In our simulation, all of the clients are considered equal in terms of hardware and cache configuration. We assume that the local network has the properties shown in Table 1. These data are derived from [14], where rtt is the round-trip time, bw the bandwidth, mss the maximum segmentation size and STT the segment transmission time. Each client has a cache of 600KB on its local disk, and connects itself to a local proxy with 30MB of cache space. These values are much lower than those actually adopted, mainly because the collected workload is not big enough to enable us to evaluate the system in a long term. However, as the primary objective of this study is to offer comparative, rather than absolute results, adopting smaller, but proportional values is still acceptable. The important thing is to evaluate the algorithms under the same conditions. All clients, remote servers and the proxy keep data on their local disk which has 3ms of seek time, rotates at 7200 RPM (rotations per minute) and transfers data at a speed of 8MB/s.

Table 1
: Network characteristics.

network	rtt	bw	mss	STT
LAN(Ethernet) WAN(Fast-Internet)	0.7ms 89ms	8.72Mb/s 1.02Mb/s	1460B 512B	1.28ms 3.85ms

In order to understand by how much cooperation can improve caching performance, simulation results of the four algorithms are compared against a base case, where there is no cooperation, as is the current situation.

5 Simulation Results

In this section, we compare the simulation results basing on four parameters: hit ratios, proxy load, network load, and access latency. The results of the last three are converted to a percentage scale. We also present performance of each client in terms of speed and machine load individually. For this study, it is assumed documents did not change during the period of log collection. A hit thus occurs when the document is actually found in the cache.

5.1 Cache Hit Rates

The first parameter to compare is the hit ratio. Figure 1 (top-left) reveals the hit ratio achieved in each caching level for the algorithms. The total height of each bar represents the miss ratio for each algorithm's local cache. As the algorithms Base, Direct Cooperation and Simple Forwarding manage the local client caches normally, all of them achieve the same local hit ratio. Due to local cache space reduction, Central Coordination and Hash Distribution have this ratio decreased. However, as these two algorithms manage cache space more efficiently, their global hit ratio, which is the sum of the hit ratios achieved by local client caches, remote client caches, and the proxy cache, is higher than those of other three. The number of requests reaching remote servers has decreased significantly from the Base case to the cases where cooperation is adopted, with a reduction of 17.3% for Direct Cooperation and Simple Forwarding, 28.6% for Central Coordination and 28.4% for Hash Distribution. Remote client cache hit ratio seems incredibly high for Central Coordination and Hash Distribution. But we should remember that these hits are for documents smaller than 20KB, thereby the increased amount of client machine load will not be that high. Similarly, as the proxy only caches documents larger than 20KB, low proxy cache hit ratio might still imply a high amount of proxy load caused by supplying documents from its cache.

Figure 1:
Comparisons of simulation results in terms of hit ratios (top-left); proxy load (top-right); local network load (bottom-left) and latency (bottom-right). 1 is for the Base case; 2 for Direct Cooperation; 3 for Simple Forwarding; 4 for Central Coordination and 5 for Hash Distribution.

Although most intuitive, cache hit ratio only gives us a superficial understanding of caching performance improvements. More practical parameters than it are local proxy load, local network load and access latency, which will be the next parameters to analyze.

5.2 Proxy Load

Our goal is not to impose too much extra load on the local proxy compared with the base case. Otherwise, the introduced queuing delay may worsen the performance of the proxy, making it a bottleneck of the whole local system. Earlier, we predicted that Direct Cooperation would definitely have this load decreased. As the other algorithms impose extra work on the proxy, it seems like the proxy will receive more workload than the base case, but some of the extra work is compensated by the proxy acting simply as an intermediary.

For this calculation, we adopt the criteria used by Dahlin et al. [8], assuming that a small network message costs one load unit; a block data⁶ transfer costs two units; a network data transfer costs one for overhead plus two for data transfer for a total of three units. The authors did not, however, consider the load caused by cache lookup. To be more realistic, we charge each cache lookup one load unit, since doing so will make our results even more conservative. The calculated results are quite close to our prediction. Among all algorithms, Direct Cooperation is indeed the one that reduces proxy load to the lowest. Figure 1 (top-right) shows that all of these cooperative algorithms have proxy load decreased to some degree, corroborating our previous assumption that even if the proxy is attributed some extra task for the sake of cooperation, the amount of work would be well compensated by distributing loads on client machines. The other loads segment shows the proxy load caused by cache lookups, state list updates and request redirections.

5.3 Local Network Load

Contrary to proxy load, local network load will increase definitely for all cooperative algorithms because cooperation necessarily generates more local communication. Besides document size, we charge 512 bytes for header information and each network message. The results are depicted in Figure 1 (bottom-left). The other loads segment represents the percentage of bytes transferred due to multicasting messages, cache state list update messages and hashing messages. Direct Cooperation and Simple Forwarding have local network load increased by only up to 3% in comparison with the Base case because multicasting or cache state list update messages only cause an insignificant amount of traffic. However, Central Coordination and Hash Distribution increase HTTP traffic by about 20%, suggesting that these algorithms are not practical in LAN's which are already highly congested. Nevertheless, if the HTTP traffic contributes only to a small proportion in total amount of traffic within the LAN, an increase of 20% would have little effect on the network congestion in general. For the comparison of access latency, we assume that the local network has sufficient bandwidth to support cooperation, so that the additional network load does not add too much queuing delay to document retrieval time.

5.4 Access Latency

As access latency depends on many dynamic factors such as queuing delays on the networks, on the proxy, on the remote servers, and on the client machines, it's difficult to give a precise measurement of this factor. Having this concern, we decide to ignore queuing delays and compare the algorithms on the basis of intrinsic values. This is acceptable since the queuing delay caused by traffic increase can be somewhat balanced by the time improvement gained due to proxy load reduction.

For data communication delay through the network, we use the model developed by Heidemann et al. [14], which considers the handshaking and slow start behaviors of the TCP. We consider 1ms for each cache lookup (assuming that the index of each cache is maintained in main memory, i.e., no disk access is needed) and 5ms of timeout on each multicast request for the case of Direct Cooperation. Figure 1 (bottom-right) illustrates the access latency of each algorithm converted to the percentage scale. Direct Cooperation and Simple Forwarding have access latency decreased by 12% in comparison with the Base case. For having managed cache spaces more efficiently, Central Coordination and Hash Distribution are able to intercept more requests locally than other algorithms, implying that the latency is further reduced.

5.5 Individual Comparisons

In this section, we compare client performance individually. This aspect is important because even the aggregate performance seems promising, some clients might refuse to cooperate if their individual performance is worsened. The comparisons are made on the basis of latency and machine load. In Figures 2 and 3, the x-axis indicates the number of requests made by each client.

Figure 2:
Each client’s speedup or slowdown.

Figure 3:
Machine load increase of each individual client.

Access latency of individual clients of each cooperative algorithm is compared against the base case. Speedups (above the line) are calculated as the ratio between original access latency (base) and new access latency (cooperative algorithm). Figure 2 shows no client is harmed with Direct Cooperation and Simple Forwarding. For Central Cooperation and Hash Distribution, a few inactive clients⁷ are slowed down, but only by very tiny amounts, indicating cooperation does nearly no harm to individual client in this respect.

While adopting cooperative caching, client machine load is foredoomed to receive higher loads. The measured results in Figure 3 indicate Direct Cooperation causes much more burden on client machines than any other algorithms, largely because every client cache miss causes a request to all other clients. A few inactive clients have this factor increased by more than tenfold. Simple Forwarding is among the best in this respect because the only imposed machine load other than the normal load is caused by those requests forwarded by the proxy where it knows for certain which client owns a copy of the documents being requested. From a general point of view, client machine load increase is inversely proportional to the client's activeness, which means it's more unfair to inactive clients than to active clients, in terms of their machine load, if cooperation is adopted. Table 2 shows the total amount of load increase on client machines. Direct Cooperation is impractical because it tripled client machine load for the workload studied, which contains a large number of clients. This algorithm will only be more viable when the number of clients is small so that each client is not frequently perturbed by others' cache miss. The amount of increase is tiny for Simple Forwarding and modest for Central Coordination and Hash Distribution.

Table 2:
Total machine load increase.

Algorithm	Direct	Simple	Central	Hash
Client Machine Load Increase (%)	204	7	35	35

6 Related Work

So far only cooperative proxy caching has been investigated in the context of the Web [1,2]. No work has yet proposed client-caching cooperation. However, the idea has been around for a long time in other research areas such as traditional file systems [8,15,9] and client-server database systems [16].

Dahlin et al. [8] also investigated 4 cooperative caching algorithms in great detail. In their study, Central Coordination increases server (proxy, in our case) load by 10%. This is not the case in ours. Our simulation shows proxy load is always lower in a cooperative caching system than in a normal one. Sarkar and Hartman [9] presented a very low-overhead decentralized algorithm, which uses hints to allow clients to control caches. According to their evaluation, such hint-based algorithm could reach performance comparable to that of existing centralized algorithms. The major motivation for designing such algorithm is to reduce the cost of maintaining exact cache information in the system. Blaze [15] also investigated the possibilities of making large-scale file systems more scalable by allowing clients to share data each other. He introduced the notion of dynamic hierarchical caching, in which adaptive client hierarchies are constructed on a file-by-file basis. His simulation study shows that a dynamic hierarchy can reduce server load by a factor of two to three, without increasing too much latency.

7 Conclusions

Just as proxy-caching cooperation imposes load both on the cooperative proxies and on the neighboring networks, client-caching cooperation inevitably generates more local network traffic and imposes heavier loads on client machines. Despite these two drawbacks, making Web client caching cooperate is still promising in terms of proxy load, global hit ratio and most importantly, access latency. Note that our simulation only considered client caching on disks. Caching in main memory of the client machines can further reduce access latency.

As each algorithm has its own strengths and weaknesses, application of the algorithms in real environments should be studied individually. Some networks can sacrifice more local bandwidth in order to achieve a high global cache hit ratio by adopting Central Coordination or Hash Distribution. Others may not have sufficient bandwidth to support these algorithms. So they might prefer to adopt Direct Cooperation (if the client population is not large) or Simple Forwarding even if the global hit ratio is not so high as that of the other two.

Roughly speaking, Central Coordination and Hash Distribution perform similarly in many respects. The most noticeable difference is that Hash Distribution increases network load a little more than Central Coordination. In spite of this shortcoming, Hash Distribution may still be more appealing than Central Coordination because it provides robustness, which Central Coordination does not. In case the local proxy fails, clients in a Hash-Distributed caching system may still access the public portion of the caches without any problem. But in a Centrally Coordinated caching system, the failure of the local proxy causes the main caches (not only the proxy's, but also the central portion of the clients') to become useless. For future study, it would be worth investigating more sophisticated hash functions such as the one presented by Karger et al. [12] concerning consistent hashing. Other cooperative algorithms such as N-chance Forwarding, Weighted LRU [8] and hint-based [9] can also be studied.

Acknowledgments

We are grateful to the authors in [13] for making their client traces available to the public. We would also like to thank the anonymous reviewers for their valuable comments on an earlier version of this paper.

• [1] R. Malpani, J. Lorch, D. Berger. Making World Wide Web Caching Servers Cooperate. In Proceedings of the Fourth World Wide Web Conference, Boston, USA, Dec 1995.
• [2] A. Chankhunthod, P. B. Danzig, C. Neerdaels, M. F. Schwartz, K. J. Worrell. A Hierarchical Internet Object Cache. Technical Report 95-611, University of Southern California, March 1995. http://catarina.usc.edu/danzig/cache.ps
• [3] L. Zhang, S. Michel, K. Nguyen, A. Rosenstein, S. Floyd, and V. Jacobson. Adaptive Web Caching: Towards a New Global Caching Architecture. Third International WWW Caching Workshop, June 1998.
• [4] A. Heddaya and S. Mirdad. WebWave: Globally Load Balanced Fully Distributed Caching of Hot Published Documents. In Proceedings of 17th IEEE International Conference on Distributed Computing Systems, Baltimore, Maryland, USA, May 1997.
• [5] C. Mic Bowman, P. B. Danzig, D. R. Hardy, U. Manber, M. F. Schwartz and Duane P. Wessels. Harvest: A Scalable, Customizable Discovery and Access System. Technical Report CU-CS-732-94, Department of Computer Science, University of Colorado - Boulder, March 1995. ftp://ftp.cs.colorado.edu/pub/techreports/schwartz/Harvest.Jour.ps.Z
• [6] D. Povey and J. Harrison. A Distributed Internet Cache. In Proceedings of the 20th Australian Computer Science Conference, Syndey, Australia, February 1997. http://www.psy.uq.edu.au/~dean/project/
• [7] E. D. Katz, M. Butler, R. McGrath. A Scalable HTTP Server: The NCSA Prototype. In Proceedings of the First International WWW Conference, May 1994.
• [8] M. D. Dahlin, R. Y. Wang, T. E. Anderson, D. A. Patterson. Cooperative Caching: Using Remote Client Memory to Improve File System Performance. In Proc. of First Symposium on Operating Systems Design and Implementation, pages 267--280, November 1994.
• [9] P. Sarkar and J. Hartman. Efficient Cooperative Caching Using Hints. In Second USENIX Symposium on OSDI'96, pages 35--46, October 1996.
• [10] A. Leff, J. L. Wolf, and P. S. Yu. Replication Algorithms in a Remote Caching Architecture. IEEE Trans. on Parallel and Distributed Systems, 4:1185--1204, November 1993.
• [11] S. Gadde, J. Chase, M. Rabinovich. A Taste of Crispy Squid. Workshop on Internet Server Performance (WISP98), June 1998.
• [12] D. Karger, E. Lehman, T. Leighton, M. Levine, D. Lewin and R. Panigrahy. Consistent Hashing and Random Trees: Distributed Caching Protocols for Retrieving Hot Spots on the World Wide Web. In Proceedings of the Twenty-ninth Annual ACM Symposium on Theory of Computing, pages 654--663, El Paso, Texas, May 1997.
• [13] C. Cunha, A. Bestavros, M. Crovella. Characteristics of WWW Client-Based Traces. Technical reports BU-CS-95-010, Boston University Computer Science Department, July 1995. URL: ftp://cs-ftp.bu.edu/techreports/95-010-www-client-traces.ps.Z .
• [14] J. Heidemann, K. Obraczka and J. Touch. Modeling the Performance of HTTP Over Several Transport Protocols. IEEE/ACM Transactions on Networking, 5(5):616--630, October 1997.
• [15] M. A. Blaze. Caching in Large-Scale Distributed File Systems PhD thesis, Princeton University, January 1993.
• [16] M. J. Franklin, M. J. Carey and M. Livny. Global Memory Management in Client-Server DBMS Architectures. In Proceedings of the International Conference on Very Large Data Bases, pages 596—609, August 1992.

¹

http://www.nlanr.net/Cache/

²

Simple Forwarding corresponds to Greedy Forwarding in their study.

³

The purpose of using multicasting here is to make efficient use of network bandwidth and CPU resources.

⁴

As multicasting only applies to UDP, and current HTTP is built on top of TCP, a new caching protocol need to be developed or the HTTP must be extended to support multicasting. Although UDP is not so reliable as TCP (due to its connectionlessness feature) in wide area networks, it is sufficiently reliable in local area networks.

⁵

Usually, size information is available in the header returned by the server.

⁶

A block is 512 bytes large in this study.

⁷

We call clients who made small numbers of requests during the log collection inactive and those who made large numbers of requests active. This convention follows the one adopted by Dahlin et al. [8].

Publication Dates

• Publication in this collection
  04 Feb 1999
• Date of issue
  Nov 1998