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

["Paul Leach" <paulle@xxxxxxxxxxxxxxxxxxxxxx>]

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]
>