Subject: Re: Is this really an LCUP show stopper?

From: Jonghyuk Choi <[email-masked]>
Date: Wed, 4 Jun 2003 09:22:05 -0400

Ted,

>                To me, you seem to be arguing below that the
>approach (client pull, optimized by some server state) is invalid,
>when my reading both of the draft and this text would be that this
>approach allows a wide  range of variation in the balance between
>optimizing wire traffic by increasing server state and optimizing
>server scale by allowing for profligate returns.  While I certainly
>respect your sense of the difficulty of implementation this might
>pose to existing clients and servers, I'm not sure how this makes
>this invalid.  It is an engineering balance between two costs,
>and the protocol allows the balance to shift both ways.

Because even a single omission of delete / modify in history can make
it impossible to recreate the previous sync result the cookie of a sync
request refers to, it looks more like a matter of how long the full
history information is maintained rather than how complete the history
information is. That is, as to the completeness of history, it is a binary
decision, not a wide range of variations. How long the full history is
maintained for sync purpose would give a tradeoff. But it still requires
maintaining full history in order to benefit even a small from the 
tradeoff.
It in fact assumes an implementation option and gives tradeoffs only 
within that option.

>                is a good, short precis of your points.  I do see an 
engineering
>disagreement here on how to balance increases in state for
>deployed servers vs. the value it presents.  I don't see a show stopper,
>though, as the draft acknowledges the possibility that maintaining state
>will not be appropriate for all cases and provides other mechanisms for
>them.  That those are sub-optimal from a consumption perspective
>is not exactly surprising, given the basic design.

The concern here is that other mechanisms (full reload / sending excessive
entries) would be the norm for most cases.

Jong

------------------------
Jong Hyuk Choi
IBM Thomas J. Watson Research Center - Enterprise Linux Group
P. O. Box 218, Yorktown Heights, NY 10598
email: [email-masked]
(phone) 914-945-3979    (fax) 914-945-4425   TL: 862-3979

---

From: [email-masked] (Mark C Smith)
Date: Thu, 05 Jun 2003 09:59:02 -0400

First, a logistical comment: Rich Megginson is currently enjoying a long 
awaited sabbatical and is probably not reading email right now. I am 
sure he would have a lot to say if he was available, but I think he will 
be out for the next month or so.

Jonghyuk Choi wrote:
> information is.

LCUP does not require that the server be able to "recreate the previous 
sync result." It requires that the server be able to, based on the 
cookie supplied by the client, generate a set of Sync Update messages 
that allow the client to synchronize with the server. This is a subtle 
difference, but important in some scenarios.

> That is, as to the completeness of history, it is a binary

If a server implementor wants to minimize the Sync Update message sent 
to clients and minimize the frequency of full resyncs and support all 
possible sync scenarios, then yes, quite a bit of state information must 
be maintained. But there are some tricks implementors can use to reduce 
the amount of state storage needed. For example, in most environments 
the search criteria used by all of the LCUP clients will involve a very 
small subset of the attribute types and values contained in the DIT. If 
my server only needs to support LCUP requests that use the search filter 
(objectClass=person) then I can reduce the amount of "extra" state 
storage down to a reasonably small amount. It will always be possible to 
come up with examples that make LCUP look bad from one perspective or 
another (wire traffic vs. server implementation burden), but I suspect 
the same is true of most synchronization protocols.

> entries) would be the norm for most cases.

Perhaps your common use cases are different than the ones I have in 
mind. Or maybe you and Kurt are right. But I think we are mainly arguing 
about the validity of the engineering tradeoffs that were made in 
drafting and achieving consensus around draft-ietf-ldup-lcup-05.txt. 
Certainly this is a useful discussion; I hope more people will join in soon.

-Mark Smith
  Netscape