[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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?