Subject: RE: High update rates and network delay

From: "John McGarvey" <[email-masked]>
Date: Tue, 6 Mar 2001 18:04:57 -0500

[Albert]
Likewise A cannot receive updates from D at the same time it is sending
updates to D, so the slow link is effectively half duplex.

>> I do not find that restriction in the current architecture draft. The
current draft says that a server can't be in concurrent session as a
consumer with two or more suppliers for the same replication context.  But
I don't think it says that a server can't be in concurrent sessions as a
consumer and as a supplier.  In section 7, it says "A two way exchange
requires two replication sessions; one session in each direction."

[Albert]
I'm inclined to agree with the architecture drafts approach of just
deferring such issues until basic standards for interoperability are in
place, although it seems clear that "optimal" interoperability will require
full standardization of link and schedule selection algorithms (and many
other aspects not yet addressed at all).

>>The approach I suggested does affect basic standards for interoperability
and the current drafts.  I suggested that a partial update vector could be
sent by the consumer to receive only those updates that originate on a
subset of the writeable servers, so that update paths through the topology
could be optimized.  If this idea has merit, the current drafts should be
changed to allow partial update vectors to be sent, which is disallowed at
present.  We can probably defer the task of explicitly defining algorithms
for optimizing these update paths.

-- John McGarvey

---

From: "Albert Langer" <[email-masked]>
Date: Wed, 7 Mar 2001 17:05:38 +1100

Ed could you please clarify my confusion on whether
a replica can concurrently have a supplier and a
consumer session?

[Albert]

[John M]

[Albert]
Whoops! I can't find it in the architecture draft either. For some
unknown reason I read "two replication sessions; one session in each
direction" as implying that one would follow the other. But there is
clearly no such implication - it reads at least as well for
overlapping concurrent sessions.

I'll have to take a closer look as I don't think I understand how
the Update Vector that gets updated at the end of a session works
in this situation, or why there is no special provision for two
way sessions in the replication protocol. I've always assumed
there was a deliberate simplification here that avoids some
complexities when supplying updates at the same time as
recieving them - ie at any given moment any given replica is either
acting as a supplier for multiple consumers, or a consumer from 1
supplier, but never both. Doesn't seem to be what it actually
says though.

Anyway, the assumptions on which a large part of my response to you
were based look pretty shaky. Sorry about that ;-)

[Albert]

[John M]

-- John McGarvey

[Albert]
I think we might be at cross purposes here. Certainly if we are going to
do it now, the architecture draft would have to be amended to remove the
restriction. But in addition it would have to specify what partial update
vectors can be sent. You would need to write some text on that at the
same time as proposing removal of the restriction (with more detailed
text to go in the actual standards). The specification would have to
at least guarantee eventual convergence, and therefore could not
just "permit" implementations to do whatever they like as regards
partial update vectors. Algorithms for *optimizing* the update paths
could be deferred, perhaps with related information model changes
for coordinating the choice of common algorithms. But at least a
minimal algorithm that just guarantees eventual convergence
using a partial update vector instead of a complete update
vector would be necessary.

My other suggestion is that if you are writing an I-D on that,
a good start would be to just demonstrate that it works with
new replicas joining and leaving the replication network,
given that it is arbitrarily and sporadically connected
with arbitrary and dynamically changing schedules and
replication agreements - starting with a demonstration
of that for the case of a full update vector. (I'm not
even sure how that works with full update vectors at
the moment ;-)

My comment about "deferring" was not intended to suggest
that your proposal (*with* some specification ;-) could
be deferred until after architecture was finalized, if
we are going to do something like that in version 1.

I meant I was agreeing with what I assumed to be the
authors intention of leaving anything that isn't
strictly necessary for viable interoperability until
version 2 if doing it in version 1 would substantially
complicate implementation.

ie We MUST have eventual convergence (and atomicity and
sequential ACI updates ;-) and SHOULD optimize for
high update rates and network delay. So if you have
an easily added way to do, or even prepare for, some
optimization then it should be added, otherwise it
should not.

My belief was that it will be quite difficult
to specify partial update vectors and therefore should
not be done for version 1 as there is no requirement
that we MUST do it. It looks like the assumptions
behind my belief aren't very convincing so don't
let that deter you from writing a spec.

Hmm, I see an interesting parallel with an assumption
that others may have made two years ago that atomicity
would be difficult and was not required - unfortunately
without actually having done the requirements analysis
before deciding on a design and then doing the
architecture. I suspect that because we currently
don't have an architecture that meets even the
MUST requirements, you may have plenty of time in
which to write a spec for your addition - but
I'd still recommend starting now ;-)