Subject: RE: High update rates and network delay

From: "John McGarvey" <[email-masked]>
Date: Mon, 5 Mar 2001 17:00:31 -0500

Yes, fair enough. Let me try again.  How about:

"The Consumer may support multiple concurrent replication sessions with
more than one Supplier for the same Replication Context, but if so, the
Consumer must ensure that the sets of updates received from each concurrent
Supplier session are disjoint. Two sets of updates are disjoint if the
corresponding sets of CSNs are also disjoint."

I have suggested a particular way to ensure that the sets of updates
received are indeed disjoint, which is by having the consumer send
different, nonoverlapping parts of the consumer's update vector to each
supplier with which it is in session.  Several changes to section 10.1 of
the architecture document would be necessary to allow the implementation of
such an approach.

-- John McGarvey

"Ryan Moats" <[email-masked]> on 03/05/2001 03:53:33 PM

To:   John McGarvey/Raleigh/IBM@IBMUS, <[email-masked]>
cc:
Subject:  RE: High update rates and network delay

Well first, I think that the phrase "same set of changes" needs
to be defined precisely.

The rest of the discussion is more germane to setting up replication
agreements and implementation and so I think is independent of the
wording of the requirement.

Ryan

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of John McGarvey
Sent: Monday, March 05, 2001 1:37 PM
To: [email-masked]
Subject: High update rates and network delay

The current LDAP replication architecture draft states:

(Section 10) " ... The Consumer must not support multiple concurrent
replication sessions with more than one Supplier for the  same Replication
Context."

I suggest that this requirement may lead to suboptimal transmission of
updates.  Consider the following case: servers A, B, C on one network,
servers D, E, F on another, and the two networks connnected by a slow
network link L.

(A B C) <------- L ---------> (D E F)

"Slow" may mean limited bandwidth or high latency or both.  Assume all of
these servers hold the same replication context and that it is writable on
each of the servers.  To make efficient use of the network connection,
changes originating at any server should only traverse L once.  One way to
configure bandwidth efficient replication is as follows.

- Replicas B and C supply updates to, and consume updates from, A.
- Replicas A, E and F supply updates to, and consume updates from, D.

(Additional backup replication agreements may be added in case A or D are
down.)

Given this setup, suppose we want to support high rates of update with
continual replication.  In conformance with the current draft, A could
consume updates from B, C, and D via sequential sessions.  But while A is a
consumer in session with B or C, it can not receive updates over L, so the
constrained resource goes unused for that period.  Similarly, when D is a
consumer in session with E or F, it can not receive updates over L.  This
is suboptimal and significantly lowers the maximum update rate that the
configuration can support.  I have chosen a simple example, but the more
complicated the topology, the more the update rate is affected.

I suggest the following alternative.  For this alternative, the requirement
from section 10 would have to be loosened to say

" ... The Consumer must not support multiple concurrent replication
sessions with more than one Supplier for the  same set of updates."

Here is the configuration:

- Replica B supplies updates to A but only those that originate at B.  It
consumes updates from A that originate at A, C, D, E, or F.
- Replica C supplies updates to A but only those that originate at C.  It
consumes updates from A that originate at A, B, D, E, or F.
- Replica A supplies updates to D that originate at A, B, or C.  It
consumes updates from D that originate at D, E, or F.

and so on.  The picture looks like:

B <---> A <----L----> D <---> E
        ^             ^
        |             |
        |             |
        v             v
        C             F

(Additional backup replication agreements may also be added for
availability.)  This construction is similar to the "spanning tree" created
by ethernet bridges, in that an update originating at a given server
reaches a destination via a single optimized path.  We can permit A act as
a consumer for simultaneous replication sessions from B, C, and D, because
the updates transmitted within each session are disjoint.  How can A
request updates from D that originate on D, E, and F, but not on B or C?
One way is for A to transmit only part of its update vector when it begins
a session as a consumer of updates from D.  It would send the part
corresponding to D, E, and F, but not the part corresponding to A, B, or C.

-- John McGarvey