RE: Comments on ldup-replica-req-00.txt

[Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx>]

> -----Original Message-----
> From:	Uppili Srinivasan [SMTP:USRINIVA@xxxxxxxxxxxxx]
> Sent:	Wednesday, April 22, 1998 6:49 AM
> To:	alan.lloyd@xxxxxxxxxxxxxxxxxxxx; owner-ietf-ldup@xxxxxxx
> Cc:	ietf-ldup@xxxxxxx
> Subject:	Re: Comments on ldup-replica-req-00.txt
> 
> > John wrote:
> > Reduced, but not eliminated. Say you have a set of N masters for an
> entry.Each server maintains an > increasing counter which is
> > used to tag attribute
> > values as they're updated.  These tags are then used to determine
> which
> > values are communicated to each of its peers. The question is: 'How
> do
> > you avoid each server having to know the highest tag value sent from
> > each other server?'  This seems to be the big scalability problem
> for
> > multi-master directories.  How does X.500 solve this?
> 
> John: Why will each server maintain "its own" increasing counter for
> each
> attribute.  If you mean the attribute version numbers, then there
> ought to
> be a systemwide version number for each attribute.  The job of the
> conflict
> resolution policy should be to ensure systemwide convergence towards
> the
> same image of all items (attributes).  A potential picture is:  
> - When an entry is created all attributes start with version 1
> - If the same entry (DN being the same) is created in multiple places,
> only
> one of the entries (in its entirety) would win based on the enterprise
> CR
> policy (could be time stamp).  So all attributes will start with
> version 1
> on all servers
> - If two servers update the same attribute from version n to version
> n+1
> then again CR policy would have to ensure that only one of the updates
> win
> (again possibly based on timestamps).  So the system would converge to
> version n+1 for this attribute to value associated with the winner
> above.
> 
> can you explain the scalability problem here?
> 
	Yes I would love to but that would take years  - I worked on
multi- nodal ICL 3900 systems in the 80s - 50mb fibre optic inter
connected mainframes  The operating system was about 1000 time more
complex than Unix and did a lot more. For instance, reservation of
system resources where semaphored (locked) and this was broadcasted to
other mainframes over the fiber in microseconds, similarly releases and
deadlocks were dealt with in this manner. Each mainframe could be
switched off and on again on the fly with full seamless recovery. The
resolution rate for testing resource clashes was down in the
miroseconds.

	That level of distributed robustness took a lot of money and a
lot of engineering and glass between each node.


	Now imagine a 10 million entry directory system over a WAN with
asymetric replicas (ie. 10 of the online DSAs replicating to a master
backup) and replicas that are online and being updated and and
transaction rates at 100s per second. If every DSA has a replica or two
or three and an archive  what will actually manage these attribute level
tags/counters - how does one test they work - 100% all times, all
condidtions. Switch a few DSAs off a see what happens. The more compex
the information tagging and transaction mechanisms (particularly the
distributed mechanisms that deal with these), the worse the recovery and
system robustness becomes.

	Attribute tagging - if that is a solution proposed should be an
internal processing issue - not an LDAP feature - simply because other
types of implementations that use X.500 and RDBs as back ends as  their
"LDAP servers" just dont need it - or want it.
	And I shudder to think that every time an attribute is updated,
I would have to broadcast over a the replicated system,  the DN, the
attribute type.value and its tag so that it could be verified and
possibly superceded by a clash from one or more other places. 
	what about time zones, transit delays, system clock resolution.

	Distributed - high performance DSAs seem a lot less effort and
less problematic - 
	I wonder who can supply those :-)

	regards alan
> -Uppili Srinivasan 
> ______________________________________________________________________
> ______ 
> Oracle Corporation |  
> Box 659510         |Phone: (650)506-3039   Internet:
> usriniva@xxxxxxxxxxxxx
>  
> 500 Oracle Pkwy    |Fax:   (650)506-7122  
> Redwood Shores     |X.400: c=us; a=telemail; p=oracle; o=oragate;
> s=usriniva
>  
> CA 94065           |  
> ___________________|__________________________________________________
> ______
>  
>   
>  
> 
>  << File: ATT00115.ATT >>  << Message: Re: Comments on
> ldup-replica-req-00.txt >>