Proactive Unicast and Multicast Web Cache Management Joe Touch, Katia Obraczka, John Heidemann, Amy Hughes, Anand Oswal Computer Networks Division USC/Information Sciences Institute As part of ISI's Large-Scale Active Middleware (LSAM) project [1], we are currently examining the uses of proactive loading in both unicast and multicast web cache systems. We believe that proactive services are key to the evolution of the web to a truly interactive information infrastructure. Proactive cache loading uses page access history hints and decoupled client feedback to direct server loading of a client-side cache [2]. Early tests of a similar system based on FTP access showed an average per-response latency decrease from 2 RTTs to 0.6 RTT, in exchange for a 7x increase in bandwidth [3]. Similar experiments on HTTP traffic show that similar performance is achievable, and that source preloading is the only technique that can reduce perceived response time below that of speed-of-light latency [4]. We are currently performing two experiments on proactive cache management, one unicast and the other multicast. The unicast system includes the development of a remote-access cache loading protocol, to permit unsolicited "PUT" commands, and cache feedback of "GOT" (vs. the current "GET") when a local cache hit occurs [4]. This feedback would require extension to the Internet Cache Protocol (ICP) [10]. Such feedback is critical to directing the server preloading in a decoupled fashion. Several other groups are investigated the use of server-directed client-side prefetching. The OCEANS group at Boston University uses servers to include MIME tags with hints for client-side prefetching, where the tags are labelled by probability of access [6]. A group at the Inst. of Comp. Science, FORTH (Greece) uses proxies to prefetch popular documents based on a server-supplied set of hints [7]. Both groups prefetch from the client-side, which adds a unidirectional propagation latency and places additional load on the client. Geographical push-caching combines server-direction of client prefetching with retrieval cost metrics [8]. In addition, we are developing techniques to isolate the preloading traffic from the conventional request/response web services, both in the network and at both client and server. Isolation ensures that the costs of performing proaction do not affect components not participating in the proaction. Proactive effort must be opportunistic, and have little or no cost to direct request/response exchanges. We are developing isolation techniques that do not depend on network support for QoS. For the multicast case, we are developing both a custom reliable multicast transport and a protocol for automatic group configuration [1]. The transport protocol is based on off-line acknowledgements, to permit servers to preload multiple caches without requiring the caches to dedicate processing resources to detection and correction of errors, unless either the cache is otherwise idle or the object in question has an explicit pending request from a nearby client. In addition, the transport protocol allows the client to demand immediate deliverly of a portion of a file (i.e., front of an audio file), without requiring the entire file before the response completes. We are also developing a multicast rendezvous management protocol for the association of 'communities of interest'. Web servers and multicast-capable caches automatically aggregate based on server hotspots and client interests. The goal is to provide proactive multicast web dissemination without stalling pending requests, in order to form large groups with common interests. For example, if a server detects that its Olympics pages are of current frequent interest, it creates a group for that topic. Clients that hit that server frequently find that topic, and can allocate a portion of their cache to multicast preloads. In this way, any individual hit at the server is broadcast to the group showing interest. This differs from the subscription model of push services, e.g., PointCast [5]. In these services, caches are preloaded based on explicit subscription; in our model, the server is anticipating the requests of the client, and uses cost/benefit analysis and history information to direct the preloading. There are a variety of cache replacement algorithms to govern this cost/benefit, most common is 'least-recently used' (is replaced first). Algorithms tuned to Web caches are being examined By Rooster and Abrams at Virginia Tech. [9]. They prune the cache based on the cost of replacement, rather than by strict usage locality. These techniques are directly applicable to the server prioritization of presends. We have also found that proaction maps efficiently to non-traditional network characteristics, such as asymmetries of bandwidth, power (battery client, wall-power server), and access method (shared vs. dedicated). In these systems, client prefetching maps poorly to asymmetric channels where the uplink is multiaccess and the downlink is broadcast, e.g., satellite or cable modem links, because it increases the probability of contention on the uplink. References: [1] LSAM web pages, http://www.isi.edu/lsam/ [2] J.D. Touch, "Defining `High Speed' Protocols : Five Challenges & an Example That Survives the Challenges," IEEE Gigabit Networking Workshop, Toronto, 1994. Also in IEEE JSAC., special issue on Applications Enabling Gigabit Networks, Vol. 13, No. 5, June 1995, pp. 828-835 (also ISI/RS-95-408). http://www.isi.edu/~touch/pubs/jsac95.html [3] J.D. Touch and D.J. Farber, "An Experiment in Latency Reduction," Proc. IEEE Infocom, Toronto, June 1994, pp. 175-181 (also ISI/RS-95-403). http://www.isi.edu/~touch/pubs/infocomm94.html [4] LowLat web pages, http://www.isi.edu/lowlat/ [5] Pointcast web pages, http://www.pointcast.com/ [6] Bestavros, A., "Speculative Data Dissemination and Service to Reduce Server Load, Network Traffic and Service Time for Distributed Information Systems," Proc. of 1996 Int'l Conf. on Data Eng., New Orleans. Mar. 1996. [7] Markatos, E., Chronaki, C., "A Top-10 Approach to Prefetching on the Web," Tech. Rpt. No. 173, Aug. 1996, ICS-FORTH, Heraklion Crete, Greece. [8] Gwertzman, J., Seltzer, M., "The Case for Geographical Pushcaching," Proc. of the 1995 Workshop on Hot Operating Systems, Orcas Island, WA, May 1995, 51-55. [9] Rooster, R., Abrams, M. "Proxy Caching that Estimates Page Load Delays," (working paper), Computer Science Department, Virginia Tech., Dec. 1996. [10] Wessels, D. Claffy, K. "Internet Cache Protocol (ICP), version 2," National Laboratory for Applied Network Research, UCSD (working draft), Nov. 1996.