Dan, Fred, You are spot-on when you point out the difficulty with the term "dynamic data" or "dynamic content". Current caching technologies are limited in their capacity to deal with short TTL objects. Cache servers that struggle to cope with 3,000 static objects per second will be unable to cope with rapidly expiring content (usually defined as NO-CACHE). Seek times to stay up-to-date would never be fast enough and would rapidly overcome the cache appliance CPU. 'MagniFire' is approaching new attitude to solve this problem, freeing up the CPU and dealing with short TTL's. We are now performance testing equipment capable of locating and serving up to 10 million objects a second, which isn't a trivial task: We have to "parse" and reinterpret structure and structure location in the URI of every single seek object and be able to do it 10 Millions time in a second, each time it is requested, an action that would consume all available cycles of a normal CPU. This was previously inconceivable with current caching technology. The ability to seek in a nano-second time frame makes "dynamic content" appear "static", solving many of the issues in revalidation and content freshness and consistency. All existing solutions to dealing with "dynamic content" are currently implemented on the server-side, bypassing the ordinary network requests. In 'MagniFire' We think that the ability to cache popular and rapidly changing data is starting to look reasonable. Micha, __________________________________________________ Michael [Micha] Shafir, CTO, Founder MagniFire Networks. Tel: 972 3 6483120 Fax: 972 3 6483121 Mob: 972 54 657900 Email: [EMAIL PROTECTED] Web: www.magnifire.com _________________________________________________ -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Fred Douglis Sent: Friday, March 02, 2001 6:14 PM To: Dan Li Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: pulish WCIP version 01 Dan, Sorry I am getting these comments in after the I-D submission, and no doubt too late to affect a new submission before today's deadline, but I hope they're helpful moving forward. Also, not sure if it should just go to webi, or include the other lists, so I'm erring on the side of inclusion. Overall comments: I have a problem with the term "dynamic data". To me, dynamic data is something that changes all the time, such as a stock quote, and is inherently uncachable. "Frequently-changing" data is more appropriate, as long as the rate of access dominates the rate of change -- the observation from the DOCP work among others. So, I would search and destroy references to "caching dynamic data" and make it clear that you mean "frequently-changing" or maybe "semi-dynamic" data. Alternatively, one might redefine "dynamic data" to be absolutely clear about this distinction, something I've tried to do below, both when the term is introduced and in the Defs section. You changed reliable multicast to IP multicast and claimed that reliable delivery wasn't necessary because of the volume IDs, but in 3.3 it still says message delivery MUST be reliable. Should that be changed? Related work seems incomplete. I know not everything need be included, but for example, it's incestuous to include [4] and [5] but not earlier work on using volumes for invalidation -- my own incestuous suggestion there is: @InProceedings{cohen98, author = "Edith Cohen and Balachander Krishnamurthy and Jennifer Rexford", title = "Improving End-to-End Performance of the {W}eb Using Server Volumes and Proxy Filters", booktitle = "Proceedings of the ACM SIGCOMM conference", year = "1998", month = sep, pages = "241--253", note = "\url{http://www.research.att.com/~bala/ papers/sigcomm98.ps.gz}", } I also think the draft uses the first person too much -- lots of "we's" in there, or "let's lay out", or ... The detailed comments below are for the version that was just submitted as a formal I-D. I had annotated a recent version from a few days ago, but saw the new versions just as I was going to send in my comments. Sections that are completely new got only cursory examination. You'll need to merge these changes back into the original if you agree with them... Fred ---- Abstract Cache consistency is a major impediment to scalable content delivery. This document describes the Web Cache Invalidation Protocol (WCIP). WCIP uses invalidations and updates to keep changing objects up to date in web caches, and thus enables proxy caching and content distribution of large amounts of frequently changing web objects, where periodical revalidating objects one by one is unacceptable in terms of performance and cache consistency. Cache consistency of frequently changing objects is a major impediment to scalable content delivery, because periodically revalidating objects one-by-one is unacceptable in terms of performance and/or consistency. This document describes the Web Cache Invalidation Protocol (WCIP), which uses invalidations and updates to keep changing objects up-to-date in web caches. It thus enables proxy caching and content distribution of large amounts of frequently changing web objects. Table of Content Table of Contents 1. Introduction In web proxy caching, a document is downloaded once from the web server to the caching proxy, which then serves the document to end- users repeatedly out of the cache. This offsets the load on the web server, improves the response time to the users, and reduces the bandwidth consumption. When the document seldom changes, everything works out wonderfully. However, the hard part is when the document is popular but also frequently changing, i.e., the so-called "dynamic content". In web proxy caching, a document is downloaded once from a web server to a caching proxy, which then serves the document to end- users repeatedly out of the cache. This offsets the load on the web server, improves the response time to the users, and reduces bandwidth consumption. When the document seldom changes, everything works out wonderfully. However, the hard part is when the document is popular but also frequently changing. Truly "dynamic content," which is potentially different on each access, is inherently uncachable unless a window of inconsistency is allowable: for instance, one might cache a stock quote and serve a stale value for seconds or minutes, even though the raw data changes in real-time. In this document, we define "dynamic content" to refer to content that changes frequently, rather than content that can potentially change constantly. Dynamic content is quickly becoming a significant percentage of the strike "the" at end Web traffic, e.g., news and stock quotes, shopping catalog and prices, product inventory and orders, etc. Because the content is changing, the caching proxy has to frequently poll the web server for a fresh copy and still tends to return stale data to end-users. Specifically, a proxy using "adaptive ttl" is unable to ensure TTL strong cache consistency, and yet "poll every time" is costly. So cite Gwertzmann & Seltzer here? the content provider usually sets a very short expiration time or a content provider marks frequently changing documents as non-cacheable all together. This defeats the benefit of caching, even though those objects may be cached, should the proxy know when the document becomes obsolete [1]. Moreover, if the proxy can be informed of the change to the underlying data that a web object is generated from, the proxy can re-generate the web object on its own, making it possible to distribute dynamically computed content. ... To provide freshness guarantees to objects in the object volume, the caching proxy subscribes to the invalidation channel and obtains an up-to-date view of the object volume -- a process referred to as "volume synchronization". After the initial volume synchronization, to stay synchronized, the invalidation channel operates in either the server-driven mode or the client-driven mode (or a mix of both). s/the/a/g ... The two modes are merely the two extremes of a continuum, characterized by how soon the server proactively sends updates/heartbeats and how soon the proxy revalidates the volume. The sooner, the quicker objects are invalidated and thus the better consistency but also the more load on the server and the proxy. Regardless of the mode, same messages are exchanged between the invalidation server and the caching proxies, whose format is defined by "ObjectVolume" XML DTD. Each round of message exchange, whether initiated by the server or the client, is a process of "volume synchronization" and results in an up-to-date view of the object volume. Based on the up-to-date view, the proxy can provide freshness guarantees to all the objects in the volume. The two modes are merely the two extremes of a continuum, characterized by how soon the server proactively sends updates/heartbeats and how soon the proxy revalidates the volume. The sooner the revalidation, the quicker the objects are invalidated; this results in better consistency but also more load on the server and proxy. Regardless of the mode, the same messages are exchanged between the invalidation server and the caching proxies, whose format is defined by an "ObjectVolume" XML DTD [forward ref]. Each round of message exchange, whether initiated by the server or the client, is a process of "volume synchronization" and results in an up-to-date view of the object volume. Based on the up-to-date view, the proxy can provide freshness guarantees to all the objects in the volume. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. Since WCIP makes some extensions to HTTP, please refer to RFC-2616 [3] for HTTP related terminology. Following are WCIP related terms. WCIP-related Dynamic Content Web resources that change "frequently," where the definition of "frequent" depends on the access rate and desired consistency guarantees. [Or something to this effect...] ... Invalidation Server An application program that provides WCIP services to caching proxies. It maintains the master copy of the object volume and disseminates the volume and changes to volume to caching proxies. (The invalidation server logically differs from the origin server because a cache may fill a request from a CDN content server or a replica origin server. The cache may not be able to tell these various sources from the origin server. Besides, the WCIP service Strike "besides" may not reside on each or any of them. "invalidation server" capitalize "invalidation" uniquely identifies the source of the WCIP service.) ... Revalidation Interval A property of the client-driven mode. The invalidation client initiates volume synchronization with the invalidation server, when the "last synchronization time" was "revalidation interval" ago. The interval SHOULD be smaller than the freshness guarantees of all the objects in the object volume, to avoid unnecessary cache misses. smaller, or no greater than? Invalidation Latency The time between an object is updated at the origin server to the time the old copy is treated as stale at all the participating proxies. The goal of a freshness guarantee of X seconds is to guarantee that the invalidation latency is within X seconds at all times. Content Delivery Network (CDN) A self-organizing network of geographically distributed content delivery nodes (reverse proxies) for contracted content providers, capable of directing requests to the best delivery node for global load balancing and best client response time. ... 3.1 Freshness Guarantee WCIP provides reliable invalidations and consistency guarantees so that content providers could make their dynamic content cacheable. could -> can It's important that WCIP guarantees that, in the worst case, a proxy subscribed to an invalidation channel will not service stale content X seconds after the content is updated at the origin server, regardless of network partition or server failure. The content provider can specify the value of X, e.g., to 5 minutes. In the normal case, this is not hard. Using WCIP, the proxy will not deliver any stale object as soon as an invalidation arrives from the server. The invalidation latency only depends on network propagation and queuing delay, which are typically within a second. In other cases, however, when the network or the invalidation server is down, invalidations cannot reach the proxy timely. To ensure an upper in a timely fashion bound on the invalidation latency, the proxy MUST invalidate content automatically if it hasn't being able to synchronize the object been able volume for a certain period of time, assuming the server or network may be down and the volume may have changed. Therefore, to control the freshness, the content provider specifies a "freshness guarantee" for each object in the volume, while the caching proxy keeps track of the "last synchronization time". Then, upon serving a client HTTP request, the proxy MAY use the cached object only if the time elapsed since the last synchronization time is less than the object's freshness guarantee. Otherwise, the cached object is marked as stale and MUST NOT be served from the cache without HTTP revalidation. The proxy is RECOMMENDED not to remove the object right away as HTTP revalidation could turn out to be "Not Modified". the object right away as HTTP revalidation could result in an indication that the object is "Not Modified". ... The invalidation server picks the heartbeat interval while the invalidation client picks the revalidation interval. Both of them SHOULD be smaller than any of the freshness guarantees of the no larger? objects in the volume, to avoid unnecessary cache misses. Moreover, the invalidation server SHOULD send invalidations "reasonably" soon after it learns of an object change, but it MAY delay the synchronization until some time before the subsequent heartbeat. Such a strategy allows the server to batch multiple changes into one update, without inducing unnecessary cache misses. ... Object volume also serves as the unit of consistency. If the caching proxy obtains the up-to-date view of the volume, it follows that the caching proxy has the up-to-date view of every object in the volume (in terms of Last-Modified time and Etag). This allows one "volume synchronization" exchange to (in)validate all the objects in the volume, greatly improving efficiency compared to per-object HTTP validation. Moreover, when a web site updates its content, often it would like to preserve a consistent view of the site. I.e., it would like the end-users to see either entirely the new content or entirely the old content, not a bit of the new at some web pages and a bit of the old at other pages. By grouping these correlated web pages into one object volume, we can atomically invalidate the "one can" entire volume and thus preserve the coherent view. An object volume is described in XML (see section 5 for DTD). In for the DTD essence, it is a collection of object meta-data and can be retrieved incrementally based on its version. ... 3.3 Channel Abstraction Invalidation channel may be implemented in many different ways, An invalidation ... (2) Subscription: provide an interface for channel subscription based on the channel URI as well as notifying the upper layer whenever the subscription terminates unexpectedly. Once subscribed, the caching proxy can start send to and receive from the channel. start to send (4) Reliability: message delivery MUST be reliable, full duplex, and in sequence (wrt. the sender). Moreover, delivery SHOULD be real-time in that the average latency should be comparable to the network round-trip time from the sender to the receiver. Still true given the multicast change? ... (6) Scalability: help to ensure that the invalidation server doesn't become overwhelmed by excessive load, by providing either IP multicast (see later this section) or channel relay later in (see section 4.1). ... 4. Deployment Issues 4.1 Channel Relay An invalidation channel may have tens of thousands of invalidation clients. Channel relay points can improve the scalability of an unicast-based channel. Instead of subscribing directly to the origin invalidation server, some invalidation clients are redirected to a channel relay point. A channel relay point can perform one-to-many channel relay and many-to-one connection aggregation. (1) Channel Relay The channel relay point may have multiple clients subscribed to the same invalidation channel. It in turn only subscribes once to the original invalidation server. By multiplicatively relaying channel multiplicatively? Why not "hierarchically"? messages, it reduces the load on the invalidation server and helps scale the invalidation channel end-to-end. helps to scale Invalidation Server | | conn0 | | Channel Relay Point / | \ / | \ conn1 / conn2| \ conn3 / | \ / | \ Client1 Client2 Client3 A "dumb" relay point copies all messages from connection "conn0" to "conn1", "conn2" and "conn3", and vise versa. A "smart" relay point vice-versa also construct the up-to-date view of the volume as well as the constructs journal of changes to the volume, based on the messages it receives from the invalidation server. Then, it can respond to client-driven volume synchronization requests, instead of forwarding the requests all the way to the invalidation server. ... 4.2 Detect Changes Detecting changes is the job of the origin server and/or invalidation server. Web content may change because of updates from the content owner or updates from the content viewer. E.g., the content owner CNN.com updates its front page every 15 minutes, while Ebay updates its content whenever its customers post new auction items or bids. Therefore, changes may be detected in 4 ways. (1) When the script runs that generates content and updates the web source file (e.g., a news article is updated with the latest financial information), the script notifies the invalidation server which then sends out invalidations or delta-encoded updates to all participating caches. cite delta-encoding (2) When a piece of data in the database is modified via the database interface (e.g., the addition to the inventory of an addition books), a database trigger notifies the invalidation server the of the event. (3) When a HTTP request comes in (e.g., a POST request to add a new auction item), the origin server or its surrogate (reverse proxy) notifies the invalidation server the event. of the (4) The last but simplest way is for the invalidation server to poll the origin server periodically to find out if the object has changed. Given that there is only one invalidation server polling, the poll frequency can be very high, e.g., once every polling frequency minute, offering decent cache consistency as well. There are softwares providing change detection of web content. In There is software [cite] some cases, an event described above may invalidate multiple URLs. If the participating caching proxies are able to interpret such events, the invalidation message may carry the description of the event, instead of the list of invalidated URLs. This may be future work. This paragraph made no sense to me. I think what you mean is that WCIP can be used to tell systems like AIDE (my own), URL-minder, etc. about changes, and I fully agree -- and probably suggested this in the first place. But the second sentence about invalidation is a non-sequitur, and I don't understand the next sentence. How about: There is software providing user-level notification of changes to web content [cite]. WCIP could potentially be used to permit agents to subscribe to change notification, not for the purpose of cache invalidation, but to notify users. Integrating such functionality may be future work. 4.3 Discover Channels ... Example: Invalidated-By: wcip://www.cdn.com:777/allpolitics?proto=http This used to be "cnn.com" and got changed to "cdn.com" yet later references say cnn, and "allpolitics" seems specific to CNN. Are you sure about this change? 4.4 Join Channels ... being cached in the mean time. This guideline can be applied to meantime ... (2) ObjectVolume update: the invalidation server replies with the journal of changes to the volume since version "A" up until the latest version "B", if the journal of changes since version "A" is still available. The server SHOULD aggregate multiple updates to the same object; it only needs to report the last one. If the journal of changes is not available, it replies with the full copy of latest ObjectVolume. If "A" is equal to the latest "B", the server simply echoes back the synchronization request. (3) ObjectVolume processing: the caching proxy examines each object entry in the update, records its freshness guarantee, compares and compares the cached object (if any) with the entry. If the cached object's Etag is not equal to that in the entry and the cached object's Last-Modified time is earlier than that in the entry, the proxy marks the cached object as stale. If the entry URI is a directory path instead of filename, all cached objects with that directory prefix are marked as stale. ... However, if the volume indeed has changed, the invalidation server MUST send back an ObjectVolume description with a base equal to or smaller than 7. Here is an example: I'm not that into IETF lingo, but I thought that a specific example such as this wouldn't justify MUST rather than simply "must". Thoughts? .. (1) ObjectVolume update: if there're changes to the object volume, too colloquial -- there are ... (3) Update "last synchronization time": in this case, there is no synchronization request, just the server's update. To account for possible clock skews, the proxy MUST convert the "date" in skew ... 5.4 Serving Content When a HTTP request comes in with URI, the proxy searches its a URI ObjectVolume data structure for a matching entry. If an ObjectVolume entry is a directory path instead of filename, the entry is a filename applicable to the URI if the URI has that directory path as prefix. If multiple such directory entries match, the entry with the longest match is used. ... 6. Protocol State Machine [Not reviewed] ... (2) Public-key-based strong security with mandatory verification, i.e., the invalidation client obtains the public key of the channel during channel subscription (e.g., using HTTPS & SSL). Why not just say SSL; isn't HTTPS redundant? The invalidation server signs or encrypts the channel messages with the channel's private key. The invalidation client MUST verify the signature and discard the message if the signature doesn't match. ... 8. References 9 Mogul, J.C.; Douglis, F.; Feldmann, A.; Krishnamurthy, B., "Potential benefits of delta encoding and data compression for HTTP", ACM SIGCOMM 97 Conference. 10 Mogul, J.C.; Douglis, F.; Feldmann, A.; Krishnamurthy, B., "Potential benefits of delta encoding and data compression for HTTP", ACM SIGCOMM 97 Conference. Notice anything odd here? ... Full Copyright Statement "Copyright (C) The Internet Society (date). 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 implmentation 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 Truncated?
