Hi, Martin, thanks for taking it up. I'd say that on the high level, the
requirement would be: "An invalidation protocol to provide a strong cache
coherence mechanism while avoiding the latency penalty of validation,
usable in proxy as well as surrogate configurations." A line taken directly
from the WG charter.
One little quibble though is the definition of "strong" coherence. Much
prior work had shown that "strong" coherence is simply impossible, unless
we modify the conventional definition. What makes more sense may be the
term "delta consistency", or "freshness guarantee", which is tunable. There
are scenarios where consistency within 10sec is required while in others
cases consistency within 10min is required, etc. "freshness guarantee"
captures this aspect of customer requirement nicely so we aren't giving
ourselves an impossible job to do.
Thanks!
Dan
At 07:24 PM 2/8/01 +0000, Martin Hamilton wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Content-Type: text/plain; charset=us-ascii
>
>Hi - I've been asked to help Ian Cooper edit the WEBI Resource Update
>Protocol requirements document, of which more below.
>
>If you don't know me already, I help to run a busy Web caching service
>over here in the UK (currently running at 240Mbit/s peak bandwidth,
>100m URL requests/day, 1TB content transferred/day), and have also
>done a fair bit of hacking behind the scenes to keep this stuff
>working. I'm hoping this will make me a useful person to act as
>editor, but please holler if you feel (later, of course... :-) that
>I'm not pulling my weight.
>
>What we're looking initially are some contributions from you guys
>(anonymously, if you fear retribution from your employers :-) for RUP
>requirements and non-requirements, along the lines of:
>
> * Stuff that's indispensible
> * Stuff that would be good to have, but not essential
> * Things you really don't want to see in RUP
>
>Note that this document doesn't have to justify doing RUP, since the
>WG is explicitly chartered to produce IDD and RUP in the first place!
>
>What we (the editors) would like from you initially is, for each
>distinct requirement you can identify:
>
> 1) Description
> 2) Justification
> 3) Status - essential, desirable, not-required
> 4) Prior art - existing implementations, protocol specs,
> published papers and patents(!)
>
>We're hoping to put together an initial I-D for February 22nd, in
>time for the March IETF cut-off. Whether we do depends largely on
>you, so please don't hold back...
>
>Send your requirements to me directly unless you feel that the list
>would benefit from discussing them before they go into the I-D.
>
>Cheers,
>
>Martin
>
>
>
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.0.4 (GNU/Linux)
>Comment: Exmh version 2.1.1 10/15/1999 + martin
>
>iD8DBQE6gvJTVw+hz3xBJfQRAgUBAJ0ZTtNxb2yDGnp7wxPfSv2fFc5U3ACgk1qK
>ipAyO1FLXJhrE+sAe+az9ls=
>=ASXz
>-----END PGP SIGNATURE-----
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:22:56 MST