As the Internet continues explosive growth and has seen a corresponding increase in network loads and latency, network caching acts out a vital role in the performance of the Internet and cost saving. Effective caching system can reduce retrieval latency, network load and server load by avoiding pulling the same document several times over the same connection[DESIRE 97A]. It became one of the most important and promising research areas within the Internet community and there has been much work for defining and making high performance network cache system.

Performance measurement or analysis activities are indispensable for identifying bottlenecks and making high performance network cache system. Even though much work has been done on network caching area, most of them have focused on the performance improvement or analyzing access characteristics of local caches, but not on cache networks'. Although many people are interested in the usefulness of cache network and hundreds of caches has been established all over the world, we have been just scratching the surface of this area that there are no well-defined metrics, methodologies or analysis tools yet. The reason lies in the lack of collaboration among cache operators or researchers who has different focuses, policies, background, and lies in its relatively recent introduction compared with the case of a single local cache which has been studied thoroughly for many years in other traditional computer or file system caching areas. For these reasons, a few national or international joint projects for measuring the performance of cache network started[TERENA 97, APAN 97, DESIRE 97B]. In this report, our experiences gained from operating national cache network in Korea will be presented, with focus on hit-ratio and latency. Consistency on a cache network will be remained as the one of future works. We present costs (ICP overheads and latency induced by cache network itself when cache miss occurs) and benefits (reduction of traffic on the network and latency) of cache network in Korea by analyzing behavior of two cache servers. One is cache.kaist.ac.kr which is a child cache for campus-sized network in KAIST, and the other is cache.kix.net, the one of our national root caches in Korea.

Figure 1. Interconnection map of cache servers in Korea

3.1 bandwidth saving and data retrieval time in cache hierarchy

3.1.1 Data collection

We have collected logs from cache.kix.net which shows its status of 8 month operation. Table 1 shows the starting date, duration, number of requests and amount of data volume served of our data set.

3.1.2 Methodology

From logs of cache.kix.net, we measure the following; the number of request, Data volume served, retrieval latency to handle the request and transmission speed. By taking the average of 8 months on each parameters, we can show the operation status of cache.kix.net.

3.1.3 Result and analysis

The 57%(166670/day) of the total request is local hit, 24%(71496/day) is direct fetch, 12%(36309/day) is parent fetch, 5%(16196/day) is sibling hit. The 30%(1151MB/day) of total data volume is served from local, 32%(966MB/day) is from direct fetch, 21%(632MB/day) is from parent cache and 5%(145MB/day) is from sibling cache. Because the hit and Kbytes served by sibling cache is not so high, we came to know that bandwidth saving from cache hierarchy is low. From Statistics of data volume served and retrieval time, we found that it took long time for parent to fetch which is 12 seconds to fetch 1Kbyte. The above result had launched us to investigate on whether the latency is acceptable.

3.2 Experiment on Cache cooperation - retrieval latency

In this section, we discussed the effect of global cache cooperation in Korea by measuring retrieval latency. In 3.3, we will discuss ICP overhead when cache.kix.net cooperate with other domestic caches.

3.2.1 Global cache cooperation

As Figure1 shows, cache.kix.net has a mutual parent relationship with sv.cache.nlnar.net which is one of nlanr cache[Wessels 96 ]. For those object that are not in Korea, our international link is used regardless of overseas cache has the object or not. Even though neighboring cache has the object, we should use the international bandwidth to get the data from the cache which is outside Korea. In this section, we focused on measuring the retrieval latency when cache.kix.net has a neighboring relationship with overseas cache bacause global cache cooperation does not have a close relationship with our international bandwidth saving.

3.2.2 Data sets

We collected data which had been requested more than 300 times a day and data which had been in au domain from the log of cache.kix.net.

The first goal of this work was to analyze how configuration of cache cooperation -especially global cache cooperation - in Korea influences the performance of our cache. When we configure our cache, we need to consider the following questions; which cache to use, whether to configure specific cache as parent or sibling. Moreover, the necessity of cache cooperation with overseas cache also needs to be considered. To answer those questions, We designed a simulation in which we can measure latencies on various cases.

The following paragraph gives a brief description on the designed simulation. We used squid [squid 97]caching proxy for this test. The steps are following;

Our simulation is the following; pa.cache.nlanr.net is used as sibling for squidA and sv.cache.nlanr.net is used as sibling for squidB. We requested squidA and squidB the same data set and measure the data retrieval latency from each cache. Next, Using the same data set, squidA is configured to have no neighboring relationship. We requested the same data set to the squidA immediately and measured the latency. After that, pa.cache.nlanr.net is used as parent for squidA and sv.cache.nlanr.netis used as parent for squidB. Again, We requested the same data set to the squidA and squidB and measured the latency of each cache.

3.2.4 Results and Analysis

If we run squids for this test on the same host which we want to measure the latency, we can simulate the same network condition as our original cache. Following the above steps that has been described in 3.2.3, we can compare the different configurations of cache. After the simulation, we can get data transferred per second on each test.

In this measurement, we compared the transferred data size per second, according to the various configurations and data sets. Data transferred per second is a good metric to measure the data retrieval latency. The larger the value of data transferred per second, the little data retrieval latency. In figure 3, we can find that the retrieval latency caused by global cache cooperation is high. More elaborated experiments is need, but we can see that cooperation with overseas cache may prolong the latency.

In Figure 4, we can see that transferred data per second from case a is larger than case b. The sv.cache.nlanr.net has a better link to au domain data than pa.cache.nlanr.net and pa.cache.nlanr.net has a better link to cache.kix.net than sv.cache.nlanr.net. Fetching from sv.cache.nlanr.net cause more timeouts than from pa.cache.nlanr.net (case B has 13 urls of timeout and case A has 4 urls timeouts). So, it is better to configure pa.cache.nlanr.net as parent on au domain because timeout happens more frequently when the link to parent cache is not good. From this result, we can see it is better to have different cache configuration for each domain.

This is our first version of analysis. This measurement may become different according various situation. As a further work, we are going to measure the latency on more various data set on a different international cache on different time of test.

3.3 Overhead due to ICP

ICP(Internet Cache Protocol) is a lightweight message format used for communicating among web caches and it is used to exchange hits about the existence of objects in neighboring caches[Wessels 97A]. This section addresses measuring the effect of cache cooperation based upon overhead due to ICP. When the cache set up neighboring relationship with other cache it sends the ICP packet to neighbor cache on every request. We focused on measuring the additional ICP traffic generated by exchanging ICP message. proxy.kren.ne.kr and cache.kaist.ac.kr has been chosen for this analysis. The former is a sibling of cache.kix.net and the letter is a child of cache.kix.net. We measured ICP traffic generated by neighboring cache and transferred data volume from cache.kix.net.

3.3.1 Data Sets

Table3: data set collected to measure ICP overhead

3.3.2 Result and analysis

4. Benefits and costs : cache.kaist.ac.kr for campus-sized network as one of the child caches in cache network in Korea

4.1 Data

We have collected access traces from cache.kaist.ac.kr. Table 4 summarizes the traces, listing: starting date, duration, the number of client hosts making requests, the total number of requests, total data volume and number of parents. Each trace contains 7 or 9 days of Web access. To analyze the effect of configuring parent cache, one is experimented with no parent caches and the other is done with 2 parent caches.

4.2 Methodology

Table 5. Summary of data sets : requests for objects in Korea

Table 6. Summary of data sets : requests for foreign objects

The percentage of the number of requests for domestic objects in collected logs was 53~57%. However, byte ratio of it was 43-46%. More requests and less bytes, because the average size of requested domestic objects was smaller than that of foreign objects.

4.3 Analysis

Table 7. Hit ratio (%) : domestic objects

Table 8. Hit-ratio (%) : foreign objects

We could get similar result in case of requests for foreign objects also, which require international bandwidth consumption, except that overall hit ratio was lower because there are much more objects and request distribution for them is scattered. The sum of local hit and sibling hit was 30~40%. By adding parent caches, 40~50% of international bandwidth could be saved. National cache network in Korea was very successful in terms of bandwidth saving and reducing server load.

Table 9. Average latency in retrieving domestic objects (seconds)

Table 10. Average latency in retrieving foreign objects (seconds)

For faster response and efficient use of ICP packets, we have tried to make neighbor relationships with caches whose average RTT (round-trip time) from our cache server is 2~10ms. If RTT is larger than 15ms, ICP hit ratio was terribly small (less than 0.1~1%) and this kind of relationship was just the waste of bandwidth.

4.4 Latency induced by consistency checking

5. Conclusion

On the other hand, international cache cooperation on Global high performance research network is becoming the one of challenging issues in network caching area. We will address this issue in APAN cache network by modeling, deploying cache hierarchy in Asia-Pacific region and link it to the rest of the world. Cache network on the Global high performance research network is anticipated as an excellent environment for modeling and experiments of advanced network caching in global context, including large object caching, policy coordination, multicast-aware caching, etc.

References

[Jung 97A] J. Jung and K. Chon, Nation-Wide Caching Project in Korea - Design and Experiment, NLANR Web Caching Workshop, Jun 1997.

[Jung 97B] J. Jung and K. Chon, Replicache: Enhancing Web Caching Architecture with Replication of Large Objects, MS thesis, Department of Computer Science, KAIST, Dec 1997.

[Hamilton 97] M. Hamilton, J. Martin, I. Melve and K. Hoadley, Network Monitoring for Cache Servers, accepted proposal by TERENA TTC meeting, Oct 1997.

[Kim 97] H. Kim and K. Chon, Update Policies for Network Caches, SAL-TM-75, Department of Computer Science, KAIST, Jun 1997.

[Rousskov 97] A. Rousskov, On Performance of Caching Proxies, submitted to SIGMETRICS'98, Department of Computer Science, North Dakota State University, Fargo, N.D, Dec 1997.

[Wessels 96] D. Wessels and K. Claffy, Evolution of the NLANR Cache Hierarchy : Global Configuration Challenges, UC, San Diego, Nov 1996.

[Wessels 97A] D. Wessels and K. Claffy, Internet Cache Protocol (ICP) -version 2, Internet RFC-2186, Sep 1997.

[Wessels 97B] D. Wessels and K. Claffy, Application of Internet Cache Protocol (ICP) - version 2,ICP) -Internet RFC-2187, Sep 1997.

[Squid 97] http://ircache.nlanr.net/squid.

Appendix A. Cache Result Codes and Peer Status Codes

Appendix B. Hardware/software equipment of Web caches in Korea