Subject: Fwd: I-D ACTION:draft-danli-wrec-wcip-00.txt

From: Ian Cooper <[email-masked]>
Date: Wed, 15 Nov 2000 08:12:39 -0800

>To: IETF-Announce: ;
>From: [email-masked]
>Subject: I-D ACTION:draft-danli-wrec-wcip-00.txt
>Date: Wed, 15 Nov 2000 06:41:12 -0500
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
>         Title           : WCIP: Web Cache Invalidation Protocol
>         Author(s)       : D. Li, P. Cao, M. Dahlin
>         Filename        : draft-danli-wrec-wcip-00.txt
>         Pages           : 26
>         Date            : 14-Nov-00
>
>Cache consistency is a major impediment to scalable content
>delivery. This document describes the Web Cache Invalidation
>Protocol (WCIP) which uses invalidations and updates to keep
>changing objects up to date in web caches. Moreover, it allows
>automatic one-to-may relay and many-to-one aggregation in a CDN
>(content delivery network) environment.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-danli-wrec-wcip-00.txt
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>         "get draft-danli-wrec-wcip-00.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>         [email-masked].
>In the body type:
>         "FILE /internet-drafts/draft-danli-wrec-wcip-00.txt".
>
>NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>
>Content-Type: text/plain
>Content-ID:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-danli-wrec-wcip-00.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-danli-wrec-wcip-00.txt>

---

From: Dan Li <[email-masked]>
Date: Wed, 15 Nov 2000 12:57:41 -0800

Hi, please take a look of the WCIP draft before the IETF meeting, as we'd 
spend time on issue discussions and won't cover the draft in detail. This 
draft is a strawman, at least the following things need more work:

- clearly define the relationship of wcip with normal cache-control directives.

- specify in more detail the role of relay point, especially for channel 
aggregation. Can we or can we not aggregate heartbeats, possibly but 
cutting freshness guarantee.

- pick a security model. Use SSL, or PGP signature, or both, and also the 
security of the channel info.

- do we need a default port number? pros and cons wrt. to port 80.

- are people happy with persistent TCP connection? are people happy with 
"delta consistency" (vs. eventual consistency, strong consistency, or 
anything else).

- in the absence of a off-the-shelf realtime reliable multicast protocol, 
can we still run wcip on multicast UDP for scalability. See section 3.2.3.

- preloading, log reporting, advanced event notification, programability, 
... future stuff on vertical peering and dynamic content

What do people think?

Dan

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 20 Nov 2000 18:32:00 -0800

First of all, thanks for presenting WCIP for consideration; having something
specific to talk about is a great way to get discussion moving.

That having been said, here are some things that come to mind when reading
wcip;

* Motivation - The draft motivates itself as solving problems in dynamic
  content caching. While I don't want to start nit-picking at this stage,
  IMHO it's important to properly motivate the work, and an invalidation
  protocol doesn't address this issue; it addresses cache coherence where
  resource freshness isn't predictable.
  
* Variants - We'll need to very carefully specify how object variants should
  be handled; in some cases, it will be desireable to invalidate a limited 
  selection of variants (e.g., english and german but not japanese), while in
  others it should be possible to invalidate all variants of a particular
  resource.  
 
  This should be probably addressed in the channel description format and/or
  the invalidation message format.

* Transport - WCIP seems to use a hodge-podge of transports, including HTTP,
  a yet-to-be-described TCP protocol, and multicast. I'd argue that there
  should be one transport, or at most two, if multicast is really necessary. 

  I'm personally doubtful about using multicast, both because of its poor
  deployment and the fact that it requires specifying two separate models
  for using WCIP. It should be noted that I'm not exactly familiar with the
  issues in multicast, but then again IETF is full of people who are, so
  hopefully this issue can be sorted soon.

  I'd very much like BXXP to be addedd to the list of possible components to
  reuse (in design issues). It's a much more functional, clean and
  extensible framework than HTTP, from what little I know.  

Cheers,

-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA)

---

From: Dan Li <[email-masked]>
Date: Mon, 20 Nov 2000 19:20:18 -0800

>   resource freshness isn't predictable.

I'd say the motivation for WCIP is two fold, for dynamic content and for 
vertical peering. Dynamic content refers to a list of things (frequently 
changing, personalized, and dynamically generated from databases). The 
current "ObjectList" DTD covers only case 1 (frequently changing ones), but 
the trajectory is to carry more complex event notifications for 
personalization and dynamically generated stuff. By vertical peering, I 
refer to things like preloading, delta update, and log reporting, etc. This 
is mainly leveraging the notification transport (the channel and the relay).

>   the invalidation message format.

Agreed. At first glance (read:don't take my word seriously), the origin 
server and/or the invalidation server can set different ObjectNames to 
denote different variants (note that invalidations are done based on 
ObjectNames), and then we may use regular expression matching for 
invalidating a bunch of them. Another approach would be the cache just has 
to be aware of all the HTTP variant fields and the invalidation DTD has to 
provide fields for those variants. E.g., do a match on all HTTP entity 
headers, ... I hope we don't complicate things too much.

>   should be one transport, or at most two, if multicast is really necessary.

I think "transport" deserves more discussion. There are really two 
components in WCIP, 1. a notification transport (including the concept of 
channel, relay point, and appl-layer multicast), and 2. the 
semantics/messages carried by this transport (right now is ObjectList, but 
will expand).  Along this line, there's plenty of room to clearly separate 
this two and allow growth (separately) in both of them. How Beep (formerly 
BXXP) fits in here? a foundation for building WCIP transport?

regards,
Dan

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 21 Nov 2000 13:16:45 -0800

> is mainly leveraging the notification transport (the channel and the relay).

Perhaps "vertical peering" isn't the most fortunate phrase to use here, as
it may confuse the issues ;)

> BXXP) fits in here? a foundation for building WCIP transport?

IIRC, BXXP is the name, 'beep' is how you pronounce it, as well as the WG
name. From what little I've seen/read so far, it may be a good transport
framework/foundation.

The XML Protocol WG in the W3C is defining a packaging mechanism for XML
over arbitrary transport (which may eventually include BXXP). While I'm not
(yet) suggesting that we look at using their work, examining their approach
to these issues may be educational for us. Disclaimer - I'm a member of that
WG.

---

From: Dan Li <[email-masked]>
Date: Mon, 27 Nov 2000 21:06:01 -0800

>   should be one transport, or at most two, if multicast is really necessary.

Did anyone have experience with TIBCO/Rendezvous software (or Globalcast's 
software, for that matter). They seem to provide reliable multicast 
messaging, a publisher/subscriber model. Could be a transport for cache 
invalidation etc.

I'd like to first understand their wide-area-network implications, e.g., 
latency, scalability. Also, the performance of fine-grained message 
filtering. Any input?

Dan