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

[Jerry Combs <jwcombs@xxxxxxxxxxxxxxx>]

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.

JC
Principal Consultant
JWCOMBS@xxxxxxxxxxxxxxx


On 2/20/01 9:35 AM, "Paul Leach" <paulle@xxxxxxxxxxxxxxxxxxxxxx> wrote:

> Very roughly, if there are N replicas, and each can tolerate an update
> rate (if it were the only replica) of R, then the total update rate
> supportable by the replicated directory would be R/N.
> 
> I do not believe that the replication frequency has much to do with it,
> unless a low-ish frequency causes many updates to be transferred per
> replication interval and thereby leads to increased efficiency (due to
> some batching effect or other).
> 
>> -----Original Message-----
>> From: John Strassner [mailto:jstrassn@xxxxxxxxx]
>> Sent: Tuesday, February 20, 2001 8:21 AM
>> To: Ed Reed
>> Cc: Albert.Langer@xxxxxxxxxxxxxxxxxxxxx; Kurt@xxxxxxxxxxxx;
>> ietf-ldup@xxxxxxx
>> Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D
>> 
>> 
>> This seems reasonable, but I would suggest that we quantify
>> this, perhaps 
>> in terms relative to the (average) replication frequency of
>> the system. 
>> Thoughts?
>> 
>> regards,
>> John
>> 
>> At 08:41 AM 2/20/2001 -0700, Ed Reed wrote:
>>> Hmmm...I've found a point of agreement with Albert ;-)... see [eer]
>>> 
>>> =================
>>> Ed Reed
>>> Reed-Matthews, Inc.
>>> +1 801 796 7065
>>> http://www.Reed-Matthews.COM
>>> 
>>>>>> "Albert Langer" <Albert.Langer@xxxxxxxxxxxxxxxxxxxxx> 02/17/01
>>> 01:30PM >>>
>>> [Kurt]
>>> At 04:39 PM 2/17/01 +1100, Albert Langer wrote:
>>>> Put succinctly: LDUP directories won't interoperate. Period.
>>> 
>>> I would say that two LDUP peers could interoperate (from
>>> a protocol perspective) but that this, in itself, does
>>> not:
>>>         1) preserve LDAP/X.500 semantics nor
>>>         2) provide "equally capable" replicas.
>>> 
>>> The former issue can not be resolved unless one requires
>>> transactional consistency in multiple master replication.
>>> The latter issue can be tackled by writing a very tight
>>> applicability statements.
>>> 
>>> [Albert]
>>> 
>>> ...snip...
>>> 
>>> A necessary consequence of multi-master, as opposed to single master,
>>> is that in addition to transient inconsitencies between data
>> read from
>>> different directory servers there will also be problems with
>> data read
>>> from a single server. There are 2 options possible for multi-master:
>>> 
>>> 1) Conflicting updates to the same entry are prioritized so that only
>>> one succeeds and the others are rolled back. That necessarily results
>>> in different behaviour to single master directories but is not
>>> fundamentally inconsistent with LDAP semantics and does not prevent
>>> interoperability. Problems arising can be resolved by users
>> rather than
>>> sysadmins by notifying them of lost updates (whether due to
>> name conflicts
>>> or
>>> other conflicts). An applicability statement should clearly indicate
>>> that multi-master is unsuitable in any situation with a high rate of
>>> concurrent changes to the same entries.
>>> 
>>> [eer] I certainly agree that we should make clear (if we have not
>>> already), that multi-master is unsuitable in any situation with a
>>> high rate (say, frequently faster than the time it takes for a change
>>> to fully propagate to all registered replicas) of concurrent changes
>>> to the same entries at different master replicas.
>>> 
>>> The "frequently..." qualifier represents my own bias as to what
>>> is "reasonable" and might be changed to simply say "faster than...".
>>> 
>>> [/eer]
>> 
>