Subject: RE: Taxonomy draft - web replication problems

From: Joel Halpern <[email-masked]>
Date: Mon, 23 Aug 1999 10:36:38 -0400

In watching this discussion about cacheing versus mirroring, I note that
people are tending to assume that certain behaviors are coupled.  In my
experience, unless there is something intrinsic that couples them,
assuming coupling is a mistake.  Several dimensions each of which could
be independent follow:

Push vs Pull - Did the origin server (treating such as well defined for
now), decided to put the information in the "sometype" replica, or did
the "sometype" replica decide to get / keep the information?

Expiration - Is the "sometype" replica responsible for expiring the
information based on its own clock, or will the information provider
notify it when the information should be considered invalid.
(Obviously, there are combinations.)

Full versus partial copying - This ne is slightly different in that I
doubt that one would ever build the system around "copy the entire
server".  Even "full copying" would just be some subtrees.  And one
could easily imagine cases where not even the entire tree from a given
point down was copied.

Scripts - There is a tendency to assume that script execution goes with
Push and originating execution.  While that is the current state of
practical affairs, binding that into the terminology and taxonomy of the
system would seem to be a mistake.  One can imaging, as the technology
gets more sophisticated, that partial databases and scripts could get
replicated in a demand fashion with distributed refresh and other
properties.

The point is that in trying to build the taxonomy we need to take into
account both what exists and what couplings are intrinsic versus
coincidental.  The taxonomy should not mandate couplings that may well
not be needed in the future.  This is closely related to the name of the
group.  The point of the exercise is that there truly are a spectrum of
behaviors in many dimensions, and we need ways of talking about them.
There may be useful names for certain specific combinations, because
they are frequently built.  But we should be careful not to confuse that
with the general elements of the system.

Yours,
Joel M. Halpern

PS: I think that actually many members of this group have a similar view
to what I am trying to say above, but I could not detect it in the
recent conversations.

---

From: George Michaelson <[email-masked]>
Date: Tue, 24 Aug 1999 08:02:57 +1000

Both exist from the same servers! As a mirror operator, I know that we
both get asked to actively be a mirror by content owners, and have to
ask if we can replicate. And I know that for some sites we mirror we
asked, and other mirrors *of the same prime site* are in some sense 
more 'official' which is extremely galling.

There is an added twist here that some origins 'police' their mirrors
and others do not. I'd say there is a dimension of Service-Level-Agreement
here in terms of what is considered 'acceptable' staleness of mirrors
which varies on a case-by-case basis. Maybe we can be setting the agenda
for what is a user centric view? or a taxonomic input into the parameters
of how mirrors and content owners negotiate about this?

There is another semi-legalism here: Some origins *DEMAND* you take the
whole tree (well sub-tree) of some content. Notably, commercial ones
who insist you take advertizing.

Don't think its that clear. Scripts often don't go over well in mirroring
and while an initial execution runs on the mirror, subsequent calls go back
to the parent because of hard-coded URLs.

I think on the coupling issue, you are right. I'm not sure (coming from
a mirror managers perspective) I agree.

This drifts a bit from a taxonomy issue, but I think it helps to remember
that caches, proxies and mirrors are about two things: QoS and Money.

The QoS dimension matters most to users in the main. Apart from a branding
issue (faster downloads from us!) there isn't much in that for a provider
of service. But money talks. Mirrors can have a 10:1 or better leverage
over the offshore data-fetch in re-use and that is a very large financial
incentive to direct traffic internally.

But that also means many of the issues you raise above come into play since
they are about control of the process. I think the issues that come up
reflect the knowledge and motiviations of both sides of the fence!

cheers
	-George