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

From: Jonghyuk Choi <[email-masked]>
Date: Fri, 6 Jun 2003 09:13:38 -0400

Mark,

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

No, LCUP doesn't. But an implementation needs to do for reasonablely
incremental synchronization.

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

Let me take the LDAP Proxy cache as an example. It's an important
application, even though it may just add another to the examples that 
make LCUP look bad. LDAP Proxy Cache caches LDAP results from LDAP servers
based on client queries. If a query is answerable from the proxy cache,
it returns LDAP result directly without contacting the server. If it's 
not,
it fetches results from the LDAP server and returns them to the client.
A client update protocol can be used to synchronize cached entries with
the server. Clients can request various search criteria to the LDAP Proxy 
Cache
which in turn will send LCUP requests with various search criteria to the 
server.
A good protocol needs be scalable and consider a wide range of the current
and also future applications.

- 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: Mon, 09 Jun 2003 10:23:35 -0400

Jonghyuk Choi wrote:
> it returns LDAP result directly without contacting the server. If it's not,
> the server. Clients can request various search criteria to the LDAP 
> Proxy Cache
> which in turn will send LCUP requests with various search criteria to 
> the server.

Agreed, and the proxy is a good example where flexibility is needed and 
where implementors will do what they do best: figure out a way to 
achieve their performance and scalability goals while living within the 
contraints of an IETF-defined protocol. My real point is that different 
LDAP implementators have different needs, and we need to give 
implementors sufficient flexibility to make appropriate engineering 
tradeoffs. I think draft-ietf-ldup-lcup-05 strikes a very good balance 
amoing a large set of competing needs; you and a Kurt at least disagree.

-- 
Mark Smith
Netscape Directory Product Development
My words are my own, not my employer's.