Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D

From: John Strassner <[email-masked]>
Date: Tue, 20 Feb 2001 14:36:30 -0800

I don't understand your "Huh?", as the application instances could just as 
easily be operating on the same replica, or one could build a more robust 
system that front-ends the replicas and handles conflicts there.

John

At 05:50 PM 2/19/2001 -0800, Paul Leach wrote:

> > -----Original Message-----
> > From: John Strassner [mailto:[email-masked]]
> > Sent: Monday, February 19, 2001 10:27 AM
> > To: [email-masked]
> > Cc: Kurt D. Zeilenga; [email-masked]
> > Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D
> >
> > <js>
> > Not true. First, applications can certainly build locking and other
> > mechanisms to isolate operations affecting an update.
>
>Huh? The application instances could be operating on different replicas,
>so will never even see the "locking" operations of the other. They will
>proceed as if they were isolated, and then their updates will clash
>laters. When the attributes being modified overlap partially but not
>completely, neither one of them will get a consistent set.

---

From: Jerry Combs <[email-masked]>
Date: Tue, 20 Feb 2001 19:51:12 -0800

I think the following item should be removed from the requirements doc.

>>>P6.  The protocol MUST support propagation of atomicity information.

The point of replication is the convergence of the committed state of the
object on that particular replica. Atomicity allows an application resolve
discrepancies at the time of the modification according to logic that is
inherently application dependent. Once the modification is committed to a
specific replica, the directory should only be responsible for replicating
the resulting committed state of the object. If there are changes to the
object on multiple replicas the replication mechanism should be responsible
for resolving the differences in state...it should not be responsible for
application level transaction integrity.

As an example, suppose you have a replica with a replication interval of 5
minutes. On this replica you modify an attribute 10 times during the 5
minute interval. When it is time to begin the replication the attribute has
a specific state. Should all ten "transactions" be replicated or should only
the current state be replicated? I contend that the replication mechanism
should only guarantee the replication of the current state. This reduces the
amount of replication traffic dramatically. Note that attributes that are
high priority could be replicated immediately and would therefore replicate
each state change. Both methods should supported.

If you accept that in a directory replication of state and not replication
of modification sequence is acceptable then you must agree that propagation
of atomicity is impossible.

Applications should be designed to deal with state and not modification
sequence. If a record of modification sequence is needed it can be
maintained separately as a log, audit database, etc. This can work, even for
the Provisioning application that someone mentioned because I've just
finished writing such an application.

JC

---

From: "Ryan Moats" <[email-masked]>
Date: Wed, 21 Feb 2001 07:35:31 -0600

I disagree.  The protocol must be able to support propagation
of atomicity information.   That's not to say you need to use
it in a particular scenario that you are directory administator
for.

Ryan

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Jerry Combs
Sent: Tuesday, February 20, 2001 9:51 PM
To: John Strassner; Paul Leach
Cc: [email-masked]; Kurt D. Zeilenga;
[email-masked]
Subject: Re: WG Last Call on the LDAPv3 Directory Replication I-D

JC

---

From: "Albert Langer" <[email-masked]>
Date: Tue, 27 Feb 2001 18:47:35 +1100

[Jerry] http://www.imc.org/ietf-ldup/mail-archive/msg00870.html
I think the following item should be removed from the requirements doc.

>>>P6.  The protocol MUST support propagation of atomicity information.

[Context re application integrity omitted as I want to focus on example
 below. See link above - AL]

[Albert]
As far as I understand the context (omitted) this "example" is in fact the
*reason* you are giving for not needing to propagate atomicity information
- ie unless I have misunderstood, you are not claiming that some actual
*harm* could result from implementing the current draft requirement, other
than the impact on performance.

The harm done by the requirement and the benefit from removing it is then
a claimed "dramatically" reduced amount of replication traffic to be
achieved by removing it.

But the *only* reduction in traffic possible from your proposal is
the updates made concurrently at each replica between
replication sessions. Those are *precisely* the updates that may
result in conflicts for which the propagation of atomicity information
is required in support of requirement MM5 to be able to fix any problems
that do turn out to arise. So you are asking for a trade off between
safety and performance. For such a trade off to be justified the
performance would *have* to be "dramatically" improved, as
indeed you claim.

Several people have now indicated that they support including some kind
of warning that multi-master replication is unsuitable for applications
with a high rate of concurrent changes - ie a high rate of changes to
the same entry at *any* replica between replications - never mind such
a high rate that there is also a high rate of changes to the entry at any
*single* replica between replication sessions. Your example of 10 changes
to a single entry at a single replica between replications would necessarily
imply a high rate of concurrent changes to the same entry at other replicas.

I haven't done the calculations, but taking into account the birthday
paradox etc I suspect it would imply that *most* entries are experiencing
concurrent changes between replications. I don't see how you could get
up to 10 happening to any significant enough number at a single replica
for "dramatically" reduced traffic, without at least 1 concurrent
change for most entries.

It would of course be possible to summarize the 10 modifications, but
you are proposing to optimize for *precisely* the situation that others
are saying is unsuitable for use of multi-master.

You would need to show they are wrong about that first.

In the thread where that discussion took place, you wrote,
concerning Paul's R/N formula:

[Jerry] http://www.imc.org/ietf-ldup/mail-archive/msg00856.html

This assumes that replication is implemented as a 1 to N function. If
transitive replication was implemented instead, each replicas efficiency
could be maintained by limiting the number of replicas that it communicates
to directly. While at low update rates transitive synchronization lengthens
the update interval, at high update rates it is vastly more efficient. Lack
of transitive synchronization will limit LDUP scalability. Transitive synch
also allows you to minimize the impact of slow communication links.

[Albert]
There was no such assumption and all work in this WG has assumed
transitive replication (for good reasons including scalability
and connectivity though I don't understand your point about efficiency
and slow communications links at all).

I do not read that as a response to the claims in that thread that
multi-master is unsuitable for high concurrency situations and
am not aware of any other argument you have presented that might
be relevant to that issue. So I am assuming you have not justified
your claim that "dramatically" reduced replication traffic could
result from your proposal and that therefore you have not
justified the proposal.

If anyone reading this finds themselves surprised to be agreeing
with me, please pause and check back above to make sure you haven't
been agreeing with something I haven't actually been saying.

PAUSE
==================================================================
==================================================================

Likewise of course I do not regard the URP design as acceptable
because the whole point of it is to achieve *exactly* what Jerry
has in mind. The design choice it makes is to summarize
changes to a single entry between replication sessions, which
can only be a useful optimization for the reasons Jerry gave,
but has not justified.