Network Working Group M. Hamilton Internet-Draft JANET Web Cache Service Expires: January 15, 2002 I. Cooper Equinix Inc. D. Li Cisco Systems, Inc. July 17, 2001 Requirements for a Resource Update Protocol draft-ietf-webi-rup-reqs-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 15, 2002. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document seeks to establish the requirements for a Resource Update Protocol which may be used in conjunction with World-Wide Web intermediary systems such as caching proxies and surrogate servers to facilitate cache coherence. It is envisaged that RUP will include invalidation of previously cached objects as a key feature, while providing hooks for future extensions to richer functionalities, such as directing a surrogate to retrieve content using delta encoding or IP multicast. The main goal is to enable proxy caching and content Hamilton, et. al. Expires January 15, 2002 [Page 1] Internet-Draft RUP Requirements July 2001 distribution of large amounts of frequently changing web objects, where periodically revalidating objects one by one is unacceptable in terms of performance and/or cache consistency. Please direct your comments to WEBI mailing list webi@lists.equinix.com. To subscribe, email webi-request@equinix.com with body (un)subscribe. The mailing list archive is at http://www.wrec.org/webi-archive/. Revision Log: 1. state that RUP requirements focus on cache invalidation, and not on content retrieval or content push. 2. state that RUP should strive to provide hooks so that future inclusion of richer functionality is possible. 3. add to "introduction" more background material and the motivation for better web coherence. 4. clarify in "introduction" the main goal of RUP. 5. clarify in "scoping requirement" the relationship between managed and unmanaged delivery entities in RUP. 6. add a "terminology" section. 7. change "design goals" into "design guidelines", and add scalability and minimal functionality requirement. 8. classify various functional requirements into five areas. 9. describe the requirements for strong and weak coherence model and the behavior expected of a cache. 10. state that both server and client may initiate message exchange. 11. state that the protocol semantics and message formats should be self-contained and portable. 12. remove "content update" from the use cases. 13. rename "content update redirect" into "content location update". 14. add "content prefetch hint" to the use cases 15. state that "dynamic discovery of RUP sessions" is out of scope for the first version of RUP. Hamilton, et. al. Expires January 15, 2002 [Page 2] Internet-Draft RUP Requirements July 2001 16. state that resource grouping is decided outside of RUP and not negotiable dynamically. I.e., "targeted invalidation" is out of scope for the first version of RUP. 17. state the need for a feedback mechanism, as one of the operating modes, for sequential consistency and progress monitoring. 18. state that RUP must provide the means to describe the composition of a resource group, and describe the in-band as well as out-of-band modes as requirements. 19. state that RUP needs to support both enumeration and summary description (e.g., regular expression) of resource groups. 20. state the five RUP payloads: cache invalidation, location update, prefetch hints, removal and addition to resource groups, and adjustments to cache consistency parameters. 21. describe the requirements for a cache to provide RUP-controlled coherence and the requirements for clean transition between RUP controlled coherence and HTTP cache-control. 22. describe the requirements on an extension scheme using options (hints). And mandate that "content prefetch hint" and "content location update" must be define as options. 23. state that the security profile of a RUP session cannot be circumvented. However, alternate sessions may be provided with different security profiles. 24. switch the sections of the use cases and the functional requirements. 25. add more references to related work. 26. acknowledge people who've given comments on the mailing list or at the IETF meetings. 27. add pointers to the working group mailing list. Hamilton, et. al. Expires January 15, 2002 [Page 3] Internet-Draft RUP Requirements July 2001 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Design Guidelines . . . . . . . . . . . . . . . . . . . . . . 8 4. Scoping Requirement . . . . . . . . . . . . . . . . . . . . . 9 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Functional Requirements . . . . . . . . . . . . . . . . . . . 12 6.1 Coherence Model . . . . . . . . . . . . . . . . . . . . . . . 12 6.2 Naming and Framing . . . . . . . . . . . . . . . . . . . . . . 13 6.3 Client-Server Interaction . . . . . . . . . . . . . . . . . . 14 6.4 Network and Host Environment . . . . . . . . . . . . . . . . . 15 6.5 Host-to-host Communication . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 21 Hamilton, et. al. Expires January 15, 2002 [Page 4] Internet-Draft RUP Requirements July 2001 1. Introduction Cache invalidation and cache coherence protocols enable cooperation among content servers and web intermediaries by eliminating the round trips in a per-request cache validation model, e.g., using HTTP if- modified-since directive. One of the main problems addressed here is the fact that the current practices proved the existing HTTP cache control mechanisms unsatisfactory. Existing mechanisms are based on the assumption that the server knows the document expiration time at the moment when this document is delivered. This assumption in many cases is not correct, and we need a new mechanism for server-driven updates. A number of cache coherence or cache invalidation protocols have been proposed by the research community and the caching and content distribution industry. Approaches vary, with some proponents seeking to enhance existing protocols and others developing new protocols either specifically for this purpose or which include this functionality. Examples include WCIP [1], PSI [2] and DOCP [3]. A carefully developed mechanism for the communication of information about changes to Internet resources offers the potential for other functions above and beyond invalidation of cached objects. More general applications for this mechanism might include automated tracking of changes to related groups of resources for real-time 'mirroring' of collections of resources, and the sharing of information about cached objects between intermediaries from different vendors. Resource updates may also be an appropriate way of informing systems which generate content dynamically that the underlying data which they manipulate (e.g. to produce HTML pages) has changed. While RUP may facilitate these functions in the future, they are currently outside of RUP scope. The IETF's Web Intermediaries working group (WEBI) has been chartered to develop a Protocol based on requirements to be gathered here. For the reasons described above, we will refer to an abstract Resource Update Protocol (RUP, or simply 'the protocol') whose functionality will initially be limited to simple invalidation of cached objects, as a basis for future extensions to richer functionality. Note that RUP is at least conceptually a new protocol, but may in practice be based wholly or partly on existing protocols. The main goal of a RUP protocol is to improve cache coherence compared to HTTP's client-polling protocol in order to (a) provide stronger guarantees at a similar cost or (b) provide similar gurantees at a lower cost. Relevant costs include network load, server load, and/or client latency to revalidate cached objects. Hamilton, et. al. Expires January 15, 2002 [Page 5] Internet-Draft RUP Requirements July 2001 Specific consistency guarantees supported by RUP will be described below. Hamilton, et. al. Expires January 15, 2002 [Page 6] Internet-Draft RUP Requirements July 2001 2. Terminology This document uses terms defined and explained in the WREC Taxonomy [4], and the HTTP/1.1 specification [5]. The reader should be familiar with both of these documents. In this document, the term "surrogate" is shorthand for a demand- driven surrogate origin server, unless explicitly stated otherwise. Similarly, "origin server" refers to a surrogate's master origin server. Cache coherence and invalidation is discussed in detail in the caching literature, e.g. see [7] and [8] for background information. A RUP server is the entity that knows the state of the content and generates resource updates. A RUP client is the entity that needs to know the state of the content and receives resource updates from the RUP server. An invalidation is a signal from a RUP server to a RUP client to indicate that the master copy of a certain resource has changed. RUP must clearly define the actions this signal implies or mandates and the semantics the actions accomplish, in relationship to the RUP coherence models. E.g., RUP may specify (among many things) that a RUP client must not serve an invalidated cached object without an if- modified-since HTTP query. Hamilton, et. al. Expires January 15, 2002 [Page 7] Internet-Draft RUP Requirements July 2001 3. Design Guidelines 1. The protocol must be simple and extensible, and it should be possible to systematically extend the protocol to accommodate richer functionalities in future iterations of the protocol. 2. The protocol should not reinvent the same technologies, but leverage existing technologies (e.g. XML, HTTP, URIs) that have proven themselves with wide bases of deployment. 3. RUP should allow other protocols of similar nature to interoperate or co-exist with it. The protocol should be easy to integrate into applications such as content management engines and Web server-side software components. 4. The protocol must be scalable to tens of thousands of surrogates and caching proxies. 5. The protocol must define a set of minimal functionality that all implementations must support. If other functions exist, the protocol must define a default reaction to those functions. Hamilton, et. al. Expires January 15, 2002 [Page 8] Internet-Draft RUP Requirements July 2001 4. Scoping Requirement RUP should work across a wide range of deployment environments and should be designed for use by origin servers, its delegates, and Web intermediaries, including surrogates, CDNs, and caching proxies alike. User agents (e.g., browsers or crawlers) may in the future find RUP or its derivatives suitable for purposes beyond the core charter established at the writing of this document. RUP is motivated primarily by surrogates and CDNs, because there's much more urgent need for RUP among the more tightly coupled and managed content delivery systems. Therefore, if there are conflicts in requirements between the managed delivery entities and standalone caching proxies, RUP should accommodate those of the managed delivery entities but make them optional (e.g., whether to join a RUP session, whether to perform prefetch, and whether to accept per-object state). A RUP client should not have to support every operation. RUP should accommodate performance requirements of all classes of Web intermediaries by making support of potentially expensive features optional. RUP may guarantee support to specific features by mandating all Web intermediaries to acknowledge support of an optional feature at server request. Hamilton, et. al. Expires January 15, 2002 [Page 9] Internet-Draft RUP Requirements July 2001 5. Use Cases Please note that the protocol level details discussed here are only hypothetical at this stage, but necessary to support the examples. 1. Server-driven invalidation: in this scenario the RUP server would send object or resource group invalidations to the RUP clients, sending invalidation signals according to its own scheduling configuration. The connection between client and server could be established by either party, and could be persistent - so as to facilitate monitoring of the update guarantee, e.g., through heartbeat packets or positive acknowledgements. 2. Client-driven validation: in this scenario the RUP client would take the lead, querying the RUP server for the freshness status of an object or group of objects (e.g., denoted by a URI). The RUP server would reply with the latest changes since the last time the client asked - based on information such as Etag, timestamp, and/or version number. Whether and when the client asks the server is determined by the consistency guarantee the client is committed to provide, and should follow the semantic rules defined by the RUP protocol. 3. Content location update: in this scenario the RUP server is able to designate a new location as the source for a cached object. It could do that even if the object is fresh. The RUP server would use the location update to notify RUP clients that an object is to be fetched, e.g., from a regular web server, the parent caching proxy, a CDN peer, or a multicast object distribution channel. RUP may make this an optional use so that a standalone caching proxy may ignore the alternate location. 4. Content prefetch hint: in this scenario the RUP server may tag resources or resource groups as suitable for prefetch, and RUP clients may prefetch the content and pin it in their cache. Such use is expected to be common in surrogate, CDN, and CDN peering deployment scenarios, to provide updates for prepositioned content besides on-demand content. RUP may make this an optional use. A use case that is out of scope for the first RUP standard is "content updates". In this scenario, the RUP server would, instead of sending a cache invalidation and/or location update signal to the client, send the RUP client with either the full content of a modified object or a delta update showing changes against the previous revision. The reason for not supporting it right now is two fold. Hamilton, et. al. Expires January 15, 2002 [Page 10] Internet-Draft RUP Requirements July 2001 First, relative to cache invalidation, there's much less understanding of the kinds of content updates RUP may need. In particular, mixing signaling with data leads to problems including scaling, object consistency and security issues that are not well understood. Second, there are existing mechanisms addressing content retrieval, e.g., HTTP [5] and Delta Encoding [6], which also demonstrate the high complexity of such a functionality. RUP, however, will provide hooks for "content updates", i.e., through "content location update" (see use case 3). This allows RUP to leverage, instead of reinventing, existing mechanisms. RUP will not preclude future protocols that build on RUP to integrate more advanced content update functionality in the future. In short, RUP will not be used to update content or HTTP meta information of cached entities. As use case 3 illustrates, such updates can be implemented as a sequence of invalidate-and-fetch operations. Another use case that is out of scope for RUP is the dynamic discovery of RUP services. For example, the URI of a particular RUP resource group could be manually configured, sent as header information in the HTTP responses from the origin server, or distributed via a separate out-of-bound mechanism. Hamilton, et. al. Expires January 15, 2002 [Page 11] Internet-Draft RUP Requirements July 2001 6. Functional Requirements 6.1 Coherence Model 1. The protocol should make strong consistency possible, e.g., by returning positive acknowledgement upon receiving an invalidation message to signal the completion of cache invalidation or even content retrieval. If relay points are used, the relay node must preserve the semantics of positive acknowledgement, e.g., by waiting for every child client's acknowledgement before sending its acknowledgement upstream. The protocol shall allow a server to specify that an invalidation message be acknowledged or that an invalidation message not be acknowledged. Explicit acknowledgement may, for example, support strong consistency or support fail-over at CDN content routers. Conversely, running in no-acknowledgements mode may improve scalability. 2. The protocol should also make loose consistency available, for applications that do not require tight coupling, e.g., traditional batch mode mirroring applications. In particular, the system should provide delta consistency guarantees in which a server may specify a maximum staleness "delta" in seconds. If an object that a client is caching is updated, within delta seconds, the client will either (a) be notified of the update or (b) detect that its cache is no longer synchronized with the server. Note that this allows a client to enforce a worst-case staleness guarantee of delta seconds. 3. While participating in a RUP session, a cache should never return potentially stale RUP-controlled data without a warning that the data are potentially stale, e.g., via HTTP Warning: 110/111. 4. If a cache wants to transition a resource from RUP-controlled coherence to HTTP cache-control based coherence, it must first consider the resource stale and revalidated via HTTP (e.g., if- modified-since). Similarly, to transition a resource from HTTP cache-control to RUP-controlled coherence, it must first consider the resource stale and revalidate via RUP. 5. It is essential that the protocol support "express resynchronization". I.e., if a client becomes de-synchronized from a server, the client should be able to reconnect (resynchronize) quickly. There are a number of ways to support this, e.g., batch revalidation based on version numbers, incremental background revalidation, incremental foreground revalidation, delayed invalidation, log playback, etc. It's up to the RUP protocol design to decide on the specific mechanisms for revision control and express resynchronization of resources. Hamilton, et. al. Expires January 15, 2002 [Page 12] Internet-Draft RUP Requirements July 2001 6. Resource update guarantees must propagate correctly through the scaling mechanisms even if multiple levels of intermediary are used. 6.2 Naming and Framing 1. The protocol must enable the communication regarding an arbitrary group of resources. The protocol must be able to invalidate multiple resources with one message. A resource group can have multiple resources in it, denoted by a list of URIs (or regular expression URLs), i.e., the traditional "object URIs". RUP server must be able to add or remove resources from a resource group. 2. A resource group itself can be denoted as a URI, too, e.g., "wcip://server.com/channel7", as "resource group URI". It denotes not only a group of objects for update purposes, but also the method to access the updates. This resource group URI can then be widely shared by a content provider with its surrogates. 3. RUP must provide the means to describe the composition of a resource group. The assignment of an object to a resource group may either be made out of band (outside of RUP information exchange procedure), e.g., in the object's HTTP header. Or, the assignment can be in band, with a resource group definition message in RUP. RUP may specify both the "in-band" and "out-of- band" protocols. E.g., the HTTP header based approach specification is simple and makes it efficient to determine to which group an object belongs, while in-band specification should be supported so that RUP is self-contained. In particular, CDN operators would prefer not having to change the origin web server before anything can be put into a resource group, but rather self-describe the composition within the group. 4. RUP must support both summary description of a resource group, e.g., using regular expression or prefix matching, and enumeration of a resource group. Each deployment may choose what method(s) to use. 5. The grouping of resources is done outside of RUP, e.g., by the content provider, CDN operator, or traffic analysis tools. RUP is not requires to provide dynamic negotiation, between the RUP server and client, over the composition of a resource group. In other words, "targeted invalidation", in which a server only sends an invalidation about object X to clients that have registered callbacks on object X, is out of scope for the initial version of RUP. This is out of complexity and scalability Hamilton, et. al. Expires January 15, 2002 [Page 13] Internet-Draft RUP Requirements July 2001 concerns about servers (and clients) having to negotiate and maintain individual views of resource groups for all the clients (and servers) they speak to. It's anticipated that predefined resource groups will fit well with the majority of the RUP deployment cases (surrogates, mirror sites, and CDNs). 6. The protocol must define an extensible format for RUP messages which is capable of carrying a variety of payloads. Possible payloads include (1) cache invalidation, (2) content location update, (3) content prefetch hints, (4) removal and addition of resources to a resource group, (5) adjustments to cache consistency parameters, etc. While the above payloads may share the same RUP mechanism, it's not a requirement for the initial protocol to address all of them simultaneously. 7. As an extension mechanism, a RUP message may carry a set of options for a group of resource. The group may contain zero, one or more objects. The set of options may be empty. RUP must specify a generic option format and define the content prefetch hint and content location update as options. No option is mandatory. A RUP client can ignore any options it doesn't recognize or doesn't want to support. If positive acknowledgement is requested, the acknowledgement must indicate the options it has carried out. 6.3 Client-Server Interaction 1. The protocol must define "client" and "server" roles. It should be possible for either the server or the client to initiate information exchange. 2. We anticipate that the primary RUP clients and servers will be Web intermediaries and origin servers, although the protocol should not be so designed as to preclude use by other entities. For example, the origin server or servers may delegate the role of RUP server to a CDN which operates dedicated content signaling channels and servers. 3. The protocol should be designed to scale to systems where there are a large number (more than 10,000) surrogates of a given origin server. This may require multiple levels of intermediary relay points and/or IP multicast. 4. The protocol should be capable of operating efficiently on a wide variety of underlying media, high latency satellite links in particular will need to be considered. E.g., caching vendors have TCP optimizations that an administrator can turn on if the Hamilton, et. al. Expires January 15, 2002 [Page 14] Internet-Draft RUP Requirements July 2001 link is satellite. A reliable multicast protocol would use more FEC If the link is asymmetric. The analogy in RUP is that RUP should be able to turn off any client->server messages (such as ACKs and client-driven updates) if the link is satellite or if the transport is IP multicast. 5. To support sequential consistency and monitoring of the RUP clients, it must be possible to determine whether resource update messages have been missed, e.g. due to a client or server being down or unreachable. There must be a feedback mechanism which enables the RUP server to determine the extent to which resource updates have propagated to surrogates and carried out. E.g., if the feedback from a surrogate never comes back or comes back as failed, the RUP server may either delay publishing the content, syslog the failure, disable the surrogate that sent the failure code, or stop content routing to that CDN peer, etc. Specific deployments must be able to choose whether or not to operate with feedbacks. 6. It should be possible to reach a consistent state on all surrogates of a given origin server and collection of resources. I.e., RUP must guarantee that either a RUP client sees an update as intended or be able to detect that it might have missed an update. 6.4 Network and Host Environment 1. The protocol should be useable both in a surrogate/origin server relationship and a traditional caching proxy/origin server relationship. The protocol should also be general enough to be useable in content delivery network (CDN) environments to allow freshness control of CDN delivery nodes. 2. It must be possible for the protocol to be used in an environment where some or all communications are mediated through a firewall and/or Network Address Translation (NAT) device. The protocol design must identify issues involved in firewall/NAT traversal and provide ways by which these may be avoided or circumvented. These may not be explicitly security related concerns, e.g. working around any problems caused by use of Network Address Translation. 3. It must be possible for the protocol information to be relayed (single source, single destination) and/or be broadcasted (single source, multiple destinations) by RUP proxies. It must be possible for the protocol information to be cached (e.g., for broadcasting purposes) by RUP proxies. RUP must guarantee that Hamilton, et. al. Expires January 15, 2002 [Page 15] Internet-Draft RUP Requirements July 2001 the invalidation effect of a relayed messages on a compliant destination is the same as if the message reached the destination directly from the source. 6.5 Host-to-host Communication 1. The protocol should layer cleanly and independently on top of the underlying communication layers, e.g., TCP, HTTP, BEEP, or SOAP. The protocol semantics and message formats should be self- contained in that they stay the same regardless of the underlying transport, and thus portable to different transports. 2. The protocol must allow the information transferred between the RUP server and client to be authenticated and if necessary encrypted. In particular, RUP should be layered on top of the TLS and SASL mechanisms, so as to accommodate security needs in various current and future deployment scenarios, without having to enumerate them in the RUP specification itself. If either the RUP server or client is not willing or capable of the security profile of a particular RUP session, the session must not be initiated. Instead, an alternate session (and its security profile) may be provided for them, e.g., via alternate configuration or out-of-band discovery mechanism. 3. A mechanism providing for discovery of RUP sessions is not required to be specified within RUP. This should not preclude or be a pre-requisite for development of the protocol per se. RUP service could be manually configured, sent as header information in the HTTP responses from the origin server, or distributed via a separate out-of-bound mechanism. Hamilton, et. al. Expires January 15, 2002 [Page 16] Internet-Draft RUP Requirements July 2001 7. Security Considerations Intermediaries open up a large number of new security problems which do not exist in the classical end-to-end model of the Internet, by introducing a 'Man In The Middle' by design. As such, it is essential that this protocol level work on intermediaries takes care to devise means by which the integrity of the resources being updated can be preserved - or at least tested. The major risks associated with the protocol should be quantified and specifically addressed by the protocol design. Hamilton, et. al. Expires January 15, 2002 [Page 17] Internet-Draft RUP Requirements July 2001 8. Acknowledgements Thanks to Mark Nottingham, Oskar Batuner, Mark Day, Phil Rzewski, Fred Douglis, Lisa Dusseault, Ted Hardie, Joe Touch, Brad Cain, Hilarie Orman, Lisa Amini, Joseph Hui, Alex Rousskov, Mike Dahlin, Stephane Perret, Darren New, Christian Maciocco, Michael Condry, Renu Tewari, Tao Wu, and the rest of the WEBI mailing list for their contributions. The JANET Web Cache Service is funded by the Joint Information Systems Committee of the UK Higher and Further Education Funding Councils (JISC). Hamilton, et. al. Expires January 15, 2002 [Page 18] Internet-Draft RUP Requirements July 2001 References [1] Li, D., Cao, P. and M. Dahlin, "WCIP: Web Cache Invalidation Protocol", draft-danli-wrec-wcip-00.txt (work in progress), November 2000. [2] Krishnamurthy, B. and C. Wills, "Piggyback server invalidation for proxy cache coherency", In Computer Networks and ISDN Systems, Volume 30 1998. [3] Dilley, J., Arlitt, M., Perret, S. and T. Jin, "The Distributed Object Consistency Protocol", Technical Report HPL-1999-109, September 1999. [4] Cooper, I., Melve, I. and G. Tomlinson, "Replication and Caching Taxonomy", RFC 3040, January 2001. [5] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [6] Mogul, J., Krishnamurthy, B., Douglis, F., Feldmann, A., Goland, Y., van Hoff, A. and D. Hellerstein, "Delta encoding in HTTP", draft-mogul-http-delta-08.txt (work in progress), March 2001. [7] Belloum, A. and L. Hertzberger, "Maintaining Web cache coherency", In Information Research, Volume 6 No. 1, October 2000. [8] Gwertzman, J. and M. Seltzer, "World-Wide Web Cache Consistency", In Proceedings 1996 USENIX Technical Conference, January 1996. [9] Liu, C. and P. Cao, "Maintaining Strong Cache Consistency in the World-Wide Web", In Proceedings ICDCS97, May 1997. [10] Yin, J., Alvisi, L., Dahlin, M. and C. Lin, "Using Leases to Support Server-Driven Consistency in Large-Scale Systems", In Proceedings ICDCS98, May 1998. [11] Duuvvuri, V., Shenoy, P. and R. Tewari, "Adaptive Leases: A Strong Cache Consistency Mechanism for the World Wide Web", In Proceedings INFOCOM, 1999. [12] Li, D. and D. Cheriton, "Scalable Web Caching of Frequently Updated Objects using Reliable Multicast", In Proceedings USITS, October 1999. Hamilton, et. al. Expires January 15, 2002 [Page 19] Internet-Draft RUP Requirements July 2001 [13] Yin, J., Alvisi, L., Dahlin, M. and C. Lin, "Hierarchical Cache Consistency in a WAN", In Proceedings USITS, October 1999. [14] Yu, H., Breslau, L. and S. Shenker, "A Scalable Web Cache Consistency Architecture", In Proceedings SIGCOMM, 1999. [15] Yin, J., Alvisi, L., Dahlin, M. and A. Iyengar, "Engineering server-driven consistency for large scale dynamic web services", In Proceedings WWW10, 2001. Authors' Addresses Martin Hamilton JANET Web Cache Service Computing Services Loughborough University Loughborough, Leics LE11 3TU UK Phone: +44 1509 263171 EMail: martin@wwwcache.ja.net Ian Cooper Equinix Inc. 2450 Bayshore Parkway Mountain View, CA 94043 USA Phone: +1 650 316-6065 EMail: icooper@equinix.com Dan Li Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 94043 USA Phone: +1 650 823 2362 EMail: lidan@cisco.com Hamilton, et. al. Expires January 15, 2002 [Page 20] Internet-Draft RUP Requirements July 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Hamilton, et. al. Expires January 15, 2002 [Page 21]