Subject: Candidate re-charter/new WG

From: Ian Cooper <[email-masked]>
Date: Fri, 03 Nov 2000 20:10:26 +0000

Now that we appear to have gotten to the end of the WREC work items (there 
will be a new version of the Known Problems document - just changing the 
order of things as an outcome of the Pittsburgh meeting - submitted in the 
next few days), we need to decide how to move on.

Below is a candidate (re)charter to take WREC forward as the "Web 
Infrastructure" group (thanks to those who have given input of their 
varying types).  As you'll see, the idea is to take on two work items that 
we believe are essential for web infrastructure going forward.

There is some cross over with the invalidation protocol with the CDNP 
folks.  Since such a protocol is applicable to both areas, and since the 
CDNP folks look to have plenty of other interesting things to work on, 
WREC/WEBI appears to be a good place to work on this essential issue.

Likewise, there is some degree of cross over with the intermediary 
discovery protocol.  In order to have some hope of moving away from 
interception proxy environments, we need to help user agents find 
intermediates (proxies, extensible proxies, surrogates).  Given that this 
is an area where two proposed WGs (CDNP, OPES) would also have an interest, 
and since it doesn't appear to be directly in scope for either, we feel 
that WREC/WEBI is the best place for this.

Why the name change?  As (caching) proxies and surrogates become essential 
components in the web infrastructure we need to examine interactions 
between these systems.  "Web Replication and Caching" doesn't seem a 
sufficiently descriptive group name.  There also appears to be a general 
feeling of WREC=bad (and the name when spoken doesn't help any) that we'd 
like to try and move away from.

At present it's not totally clear whether we should be going direct to a 
working group in San Diego, or whether we should go through a BoF stage to 
discuss the area and determine whether the group is necessary (and if not 
where the work items should be handled).

Apologies for the short notice, but obviously we need to get an idea of 
what we're doing in time to request a meeting in San Diego.  Truncating the 
distribution to the WREC list (the "webi" list has *not* been set up yet) 
would probably be a good idea.  (I'd set a Reply-To but I don't know how to 
drive that part of my mail agent ;-) )

Comments please!

--------------------------->8-------------------------------------------

Web Infrastructure (webi)

Co-chairs:
    Mark Nottingham <[email-masked]>
    Ian Cooper <[email-masked]>

Mailing Lists: [TENTATIVE]
    General Discussion: [email-masked]
    To Subscribe: [email-masked]
    Archive: ftp://ftp.ietf.org/ietf-mail-archive/webi

Description of Working Group:

This working group will address specific issues identified by the WREC 
working group in the world wide web infrastructure, providing generic 
mechanisms which are useful in several application domains (proxies, 
content delivery surrogates).

Work items for this group will be:

1) 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.

2) An intermediate service discovery mechanism, consisting of:

   a) An intermediary service description format, which describes what
      services an intermediary or arbitrary group of intermediaries is
      willing to provide, and

   b) A discovery protocol for locating relevant service descriptions within
      a single administrative domain.

   Both components will take into consideration current practice, related
   work in the IETF, and a reasoned set of requirements, which will include
   the need to provide a reasonable alternative to interception proxies.

Service discovery, and other issues pertaining to coordination between 
multiple administrative domains are explicitly out of scope of this group.

Protocols associated with the provisioning of value added services, 
including the vectoring of adaptation requests to other devices, is also 
out of scope for this group.

Goals and Milestones:

Feb 01: Requirements document for intermediary discovery and description
Feb 01: First draft invalidation protocol
Mar 01: Meet at Minneapolis IETF
Apr 01: First draft intermediary discovery protocol
Jul 01: First draft intermediary description mechanism
Aug 01: Meet at London IETF
Dec 01: Invalidation protocol finalized
Dec 01: Salt Lake City
Jan 02: Intermediary discovery protocol finalized
Mar 02: Intermediary description mechanism finalized
Apr 02: Re-charter

---

From: Dan Li <[email-masked]>
Date: Sun, 05 Nov 2000 01:06:23 -0700

I think it's a good idea to have a focused forum to get something done. A 
web cache invalidation protocol will bring much value to reverse proxies 
(surrogates), forward proxies, and CDNs alike. Having WEBI devoted to it is 
a good thing.

Whatever WREC is bad for, I hope the execution of WEBI would remove any 
residue of that.

At 08:10 PM 11/3/00 +0000, Ian Cooper wrote:
>is an area where two proposed WGs (CDNP, OPES) would also have an 
>interest, and since it doesn't appear to be directly in scope for either, 
>we feel that WREC/WEBI is the best place for this.
>
>what we're doing in time to request a meeting in San Diego.  Truncating 
>the distribution to the WREC list (the "webi" list has *not* been set up 
>yet) would probably be a good idea.  (I'd set a Reply-To but I don't know 
>how to drive that part of my mail agent ;-) )
>
>Comments please!
>
>

---

From: jason andrade <[email-masked]>
Date: Sun, 5 Nov 2000 20:44:01 +1000 (EST)

> (surrogates), forward proxies, and CDNs alike. Having WEBI devoted to it is 

Apologies if this is an ignorant question, but where do mirror sites fit
in the scheme of things.. are they just less sophisticated reverse proxies?

I've been listening to wrec for a little while now and have never heard
anyone mention them..

and will webi have anything to do / talk about them ?

cheers,

-jason

---

From: Henrik Nordstrom <[email-masked]>
Date: Sun, 05 Nov 2000 12:35:50 +0100

> in the scheme of things.. are they just less sophisticated reverse proxies?

Good question.

I thought mirrors was covered as one subset of the "surrogate" concept,
but it seems this has been narrowed down to only cover "reverse proxies"
and similar constructs, with a vague reference to something undefined
called "delegates", or the wording is a bit too dim.

If the goal is still that mirrors are one form of surrogates then
perhaps the last sentence should be reworded and maybe moved down to the
"reverse proxy" section...

Change proposal:

    Devices commonly known as "reverse proxies" and "(origin) server
    accelerators" are both more properly defined as a type of
                                                 ^^^^^^^^^^^^
    surrogates acting as caching http->http gateways to replicate
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    the content.
    ^^^^^^^^^^^

--
Henrik Nordström

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 5 Nov 2000 09:16:56 -0500

>in the scheme of things.. are they just less sophisticated reverse proxies?

Hope you have seen the _whole_ plan and not only the proposed charter for WEBI.

If not, see below.

   paf

>  Michael Condry
>  Ian Cooper
>  Mark Day
>  Mark Nottingham
>  Hilarie Orman
>
>  ----------------------
>
>  There are currently multiple proposals for IETF Applications Area working
>  groups related to Web transport/content distribution; WREC/WEBI, OPES and
>  CDNP. This discussion proposes deliniations between the groups, in order to
>  clarify their roles.
>
>  Historically, WREC focused on caching and replication. WEBI is proposed to
>  replace WREC and slightly broaden its scope to include issues of general
>  import to intermediaries. WEBI work items will be distinguished by being
>  generic, in that they are not specific to one application domain (such as
>  content peering or value-added proxies). For example, invalidation
>  mechanisms and intermediate discovery protocols are of interest in multiple
>  applications. Note that if requirements for a particular application can not
>  be met by a general mechanism, it may be appropriate to define an
>  application-specific mechanism as well. WEBI might produce other groups as
>  workload requires.
>
>  The Open Proxy Services architecture (OPES) allows for services to be
>  constructed "inside the network", allowing both the overlay of value-added
>  services and the introduction of a processing model in intermediaries. OPES
>  work items will be distinguished in that they involve definition and/or
>  support of value-added services on intermediaries. For example, this may
>  include a means of vectoring messages to "callout servers" and configuration
>  and managment of services, but should exclude general content routing
>  mechanisms.
>
>  Content Distribution Network Peering (CDNP) defines a model and mechanisms
>  for the interconnection and cooperation of networks for content-related
>  tasks: direction (directing requests for content), distribution (moving
>  content out to surrogates) and accounting (tracking the delivery of content
>  from surrogates).  A single network may have its own mechanisms for these
>  tasks, and WEBI may define or standardize elements of those mechanisms. CDNP
>  focuses on the interactions required for direction, distribution, and
>  accounting between two or more networks with different administrations,
>  where the networks are potentially using different local mechanisms for
>
>  Within WREC/WEBI, OPES and CDNP are largely orthogonal. The groups
>  should cooperate in order to avoid conflicting specifications.

---

From: "Micah Beck" <[email-masked]>
Date: Sun, 5 Nov 2000 09:57:44 -0500

> in the scheme of things.. are they just less sophisticated reverse
proxies?

As someone who is very interested in mirroring technology as a form of
content distribution, I would point out that mirrors have implementation
issues which are different from reverse proxies, and that mirroring
technology can be at least as sophisticated as a reverse proxy and offers
some capabilities which are not offered by http->http gateways of any kind.

Henrik Nordström wrote

>    accelerators" are both more properly defined as a type of

Depending on its policy and implementation, a mirror can be
indistinguishable from a "reverse proxy" or "origin accellerator" so I
believe mirrors should be included as a type of surrogate.  If they are not,
then the work I am most interested in will not be covered.

Micah Beck

---

From: Wojtek Sylwestrzak <[email-masked]>
Date: Sun, 5 Nov 2000 20:19:25 +0100 (MET)

> then the work I am most interested in will not be covered.

I second on that.

My other feeling though is, that we are too much tempted to
cover mirrors and other (?) proxies with a single abstract notion 
and thus risk oversimplifying the mirrors issues. Remember the earlier
discussion on how replication is different to mirroring ? (no, don't want
to go there again). Just a comment.

However I agree that we should not leave mirrors out, and perhaps
consider them surrogates. Would it complicate anything ?

--w

---

From: Wojtek Sylwestrzak <[email-masked]>
Date: Sun, 5 Nov 2000 20:26:06 +0100 (MET)

> Hope you have seen the _whole_ plan and not only the proposed charter for WEBI.

Are you saying that mirroring fits both into CDNP and WEBI 
within the proposed plan ? 
We'd not like to have it lost somewhere in the middle.

--w

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 5 Nov 2000 15:55:14 -0500

>We'd not like to have it lost somewhere in the middle.

It is up to people on this mailing list to decide that. We run by consensus...

I just wanted people to see what is currently written about all three 
proposals, in a consistent way, so I was sure that you know what is 
behind the three proposed charters.

    paf

---

From: "Mark Day" <[email-masked]>
Date: Sun, 5 Nov 2000 21:13:38 -0500

> in the scheme of things.. are they just less sophisticated

Apologies in turn if I now ask an ignorant question, but what aspect of
mirror sites would you want to standardize?  Answering that question in a
little more detail may make it easier to determine where it should be
discussed.

Thanks in advance,

--Mark

Mark Stuart Day
Senior Scientist
Cisco Systems
+1 (781) 663-8310
[email-masked]

---

From: jason andrade <[email-masked]>
Date: Mon, 6 Nov 2000 12:27:34 +1000 (EST)

> little more detail may make it easier to determine where it should be

i look after a couple of mirror sites and also look after some mirror
distribution networks for archives.  there's little to nothing in the
way of standards for mirrors.  there are a number of tools available and
a loose `confederation' of mirror admins who exchange knowledge but that's
about it.  the wheel often gets re-invented in new and wonderful ways.

from what i've seen WREC/WEBI seem to be able producing standards and
it would have been useful to know if this could be applied to mirrors
and if it clearly couldn't maybe there needs to be another forum for
those sorts of discussions/work.

apart from "raw" mirror sites, there's also been some work on redirect
protocols being used into mirror sites and things like that are not
well understood or deployed yet, which they might be if there was a
clear way to implement them (or not as the case may be)

as an example, not too many squid cache admins allow for close to gigabyte
sized individual files in their archive, yet mirrors are sending terabytes
of this kind of data around the net daily.

-jason

---

From: "Micah Beck" <[email-masked]>
Date: Sun, 5 Nov 2000 22:12:38 -0500

> of this kind of data around the net daily.

As Jason points out, mirror servers have the capability to create surrogates
for services which are not easily replicated using current caching and CDN
technology.  Of particular interest to me is uncachable content generated by
code executing on the mirror.

Currently, creating a mirror site which includes such executable content is
very difficult when the mirror is to be installed on a server that is not
identical to the origin server.  This is because of the absence of standards
for the operating environment, language and API for executable code and the
mechanisms by which such code is transmitted to the mirror server.  This
problem is very closely related to the problem of establishing standards for
installing new services on an Extensible Proxy.

Current CDN operators and ASPs seem happy to define proprietary mechanisms
for creating mirrors of executable content, and will require that their
customers conform to their proprietary APIs in order to take advantage of
them.  This is seen as a way of locking their customers into their
particular server networks.  As these APIs become more complex,
interoperability will become impossible.  Definition of some basic standards
would at least allow some executable content (using only basic services that
can be standardized) to operate across CDN and ASP server networks.

Micah Beck