Subject: Re: Taxonomy draft - web replication problems

From: Joe Touch <[email-masked]>
Date: Fri, 20 Aug 1999 15:28:44 -0700 (PDT)

> From [email-masked]  Fri Aug 20 15:09:48 1999
> Delivery-Date: Fri, 20 Aug 1999 15:09:48 -0700
> Return-Path: [email-masked]
> Subject: Re: Taxonomy draft - web replication problems
> X-ELM-OSV: (Our standard violations) no-mime=1; no-hdr-encoding=1
> To: [email-masked] (Joe Touch)
> Date: Fri, 20 Aug 1999 18:09:07 -0400 (EDT)
> Cc: [email-masked], [email-masked]
> From: [email-masked] (Jon Zeeff)
> 
> 
> A common real-world difference is that one can execute cgi programs on 
> a mirror and not on a cache.  Other distinctions are more easily 
> blurred.  

That depends - there can be caches that save CGI output,
and, when seeing a matching request, reply the response.

And mirror usually refers to the static data - not necessarily
the dynamic code, e.g., the the CGI code. I don't know if that
has a separate term or not, but it's possible to have a 'passive'
mirror of the data without the CGI.

It might be useful to leave these kinds of distinctions
out of the definitions, unless they're necessary to 
distinguish them.

Joe

> 
> > It seems like there are a few dimensions in which caching and replication 
> > differ:
> > 
> > 			Caching		Replication
> > 
> > what is copied		server output	server source 
> > 					(as Micah observed, though
> > 					I would apply it to all replication,
> > 					not just mirroring)
> > 
> > who initiates it	client		server
> > 			(unless push-
> > 			cached, which
> > 			blurs the line)
>

---

From: Joe Touch <[email-masked]>
Date: Fri, 20 Aug 1999 15:58:19 -0700 (PDT)

> From [email-masked]  Fri Aug 20 15:55:57 1999
> Delivery-Date: Fri, 20 Aug 1999 15:55:57 -0700
> Return-Path: [email-masked]
> Date: 	Sat, 21 Aug 1999 00:38:04 +0200
> From: Wojtek Sylwestrzak <[email-masked]>
> X-Accept-Language: pl, en
> To: Joe Touch <[email-masked]>
> CC: [email-masked]
> Joe Touch wrote:
> > > however for each of these definitions it would be relatively easy to
> > > find a counterexample. it might be premature to consider these now,
> > > but i'm sure we could give examples of mechanisms that copy server
> > > output but can hardly be called caching, are initiated by server,
> > > but are still considered to be caches etc.
> > 
> > The purpose of these definitions (or the matrix thereof) is
> > to provide a grounding for the base concepts. One thing
> > we know all too well in WREC is that there is:
> > 
> >         - a counter example for every definition
> > 

> > I.e., mirror refers to the server,or collection, not the
> > individual items. A datum is replicated; the collection is
> > mirrored. (at least that's what I'm trying to convey).
> > 
> 
> how about: a datum is copied, the collection is mirrored ?

Yes - and a cached copy is (by nature) temporary;
a replicated copy is permanent.

Joe

---

From: Oscar Ardaiz Villanueva <[email-masked]>
Date: Tue, 24 Aug 1999 20:08:50 +0200 (MET DST)

I think there is another dimension that can be added to your list , which is how the end users see the diference between a replica and a cache:
Object/Service location: Is a different service used  to locate the web object/service (which is the way replicas are found: dns round robin of replicas IP, URN..) or do you left the clients to discover, be configured, the location of servers/objects (which is the way proxies are found: proxies PAC, ICP,...).
But as you said they needed not to be coupled to caching or replication.

Oscar Ardaiz
UPC  Spain

---

From: michael rabinovich <[email-masked]>
Date: Tue, 24 Aug 1999 14:27:11 -0400 (EDT)

Joe Touch wrote:

> > > how permanent is it     temporary       permanent
> > >                                         (managed by the server,
> > >                                         flushed or updated via overwrites
> > >                                         by the server)
> >

Hi Joe and everybody.  I have been  passively following this forum 
for the lack of time but this discussion hits too close to home.

Here is the distinction I worked out or myself and used it in a 
tutorial on Web caching and replication without  seemingly confusing 
the audience too much.

First, I do not distinguish between mirroring and replication.  Yes, 
there is some intuitive feeling that a mirror refers to a "site" while 
a replica refers to a smaller granule.  Still I think this distinction 
is non consequential and as this discussion showed quite blurred.
Moreover, people still use the expressions like "site replica" 
and "file mirror", contrary to this intuition that we have been 
trying to capture.

As for the distinction between caching and replication, I define 
caching as creating a copy of an object at a point that would see 
requests for the object regardless of whether or not it has a copy.  
Examples: main memory cache on the browser, a proxy cache,
main memory cache at the server.  That is, caching creates copies 
along the normal path of request and data flow.

Replication, on the other hand is creating a copy of an object at 
a place that would not normally  see any requests for this object.   
Thus, requests must take a detour to get to this place.

Some corollaries:

* unless caching is done pro-actively (pre-fetching), it does not 
incur bandwidth overhead in the absence of failures.  Replication can 
create extra  traffic.

* caching points normally see both hits and misses while replicas only 
see "hits" (request for the content that resides at the replicated 
server).

* Caching can be synchronous and asynchronous with the request for 
the object; replication is always asynchronous.

* Caching can be done at the client side or content provider side; 
replication is done at the content provider side.  Thus, replication 
is currently more amenable to dynamic content (although there have been 
some recent reseach aimed at caching dynamic content - see Active 
Caches by Pei Cao or our work on HPP).

Now what about cooperative caches?  Don't requests take detours there 
to get from  one cache to another?  According to my definition, if 
individual nodes in the cooperative cache system
service *some* requests without detours and without regard for the 
content of their caches, then it's caching.  As an example, a high 
level cache in a squid hierarchy is indeed a cache.
Or caches in the CARP arrangement are also caches - each services 
requests from its clients regardless of the content of its cache.

Among the distinctions that I considered and rejected was that caching 
is client-centric while replication is done under the control of the 
content provider (but what about reverse proxies?).

Misha Rabinovich

---

From: LOVRIC Ivan CNET/DSE/CAE <[email-masked]>
Date: Wed, 25 Aug 1999 09:46:28 +0200

>along the normal path of request and data flow.

Normal path for a request needs to be clarified :
For instance transparent caching modifies the normal path of a request.
Also, when using ICP with siblings, the request may be redirected to a
sibling cache 
containing the requested URL, thus modifying the normal path.

I'd rather say that the final destination of the request is not modified
with a caching system (considering that a cache mesh acts as a virtual
unique cache from the origin request point of view) , while a replication
system changes the final destination .

>Thus, requests must take a detour to get to this place.
Agreed.