Subject: CLDAP comments

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 25 Feb 2001 12:03:08 -0800

It seems the one rational for CLDAP is to overcome certain
host operating limitations.  I don't find this a compelling
rational for undertaking this work.  These limitations are
not that of LDAP, but of the host operating system.  There
are OS-specific methods for working around these limitations.

The key rational is to reduce the transport overhead of issuing
small sets of operations upon a server.  I believe CLDAP is
generally only applicable if the size of the set of operations
is near 1 (per session) and the number of response pdu's per
request is near 2 (entry + result).  In other cases, the overhead
of adding basic reliability (client got the complete answer
for the question asked) to UDP is far greater than the overhead
of TCP.

Hence, I believe the approach used in RFC1798 is actually quite
sound for the limited applicability of connection-less LDAP.

In RFC1798 CLDAP, a client either got "all" or "nothing".  That
is, it sent a request and either got back a response (or
duplicates) and got nothing.  Hence, a client could time-out
waiting for the response and reissue if it got "nothing".
Duplicate responses could be ignored.  Simple but effective.

In the I-D, the client waits for result.  Assuming the
client receives at least one result PDU for the request,
upon receipt of this PDU, the client has no mechanism to
determine whether the subset of responses (ignoring duplicates)
is complete or not.

I believe there needs to some mechanism which the client can
use to determine that it has received all responses.  Without
this, the usefulness of the protocol is, IMO, severely limited.

I note that as RFC 1798 is a Proposed Standard and details
a service with default listener on udp/389 and the I-D
suggested protocol is not compatible with RFC 1798, a
different port should be used.

Kurt

---

From: Leif Johansson <[email-masked]>
Date: Tue, 27 Feb 2001 10:49:13 +0100

Hi Kurt,

The example stated in the draft, i.e that of a cip proxy service, is a 
valid one. Operational experience from the GIDS project shows that tcp 
overhead is a problem in the case of one request and multiple responses 
(in this case references are received from the index). A similar situation 
is when a directory server is used as a replacement of a NIS server 
(i.e rfc2307).

Furthermore the work in rfc 1798 contains two essentially independent 
parts, one beeing the udp-transport and the other beeing the combination
of several results into one pdu. In the spirit of LDAPv3 it would seem
like a better idea (imho) to create an extension which regardless of 
transport ships multiple results in a single pdu. There are several
possible solutions to the problem of determining when results have been
received, how many etc etc. In fact many of the comments you made are
already noted in the draft but I believe that it is better to solve them
within the framework of LDAPv3 extensions than to stay with an fundamentally 
different PDU format.

I would also suggest that whatever happens to this draft rfc 1798 be moved 
to historic. It might be interesting to get an ADs input on the last
comment: given the fact that rfc1798 and this draft is not compatible (even
though it is easy for a server to tell them apart) can they, and if so under
what circumstances, share the same assigned port?

	Cheers Leif

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 27 Feb 2001 10:15:27 -0800

>is when a directory server is used as a replacement of a NIS server 

I concur that there are applications of connection-less LDAP (I
believe they are limited).  My concern (which I didn't state very
clearly in my past post) was that the I-D put too much focus on
overcoming operating system limitations and not enough on
the primary rational, reducing transport overhead expense.

>of several results into one pdu.

I think these are quite dependent parts in that the combining
responses into one result PDU was specifically introduce to
effectively deal with the transport characteristics of UDP
without introducing other significant client/server/network
overheads.

By point is that CLDAP (RFC1798) is very simple and
this is good thing.  I agree that the approach has
limitations (such as the significant result size limitations),
but that these limitations only impact a faction of the set
of target applications.  Your index application might be in
that faction.

>In the spirit of LDAPv3 it would seem
>transport ships multiple results in a single pdu.

I see updating CLDAP (RFC1798) to support LDAPv3 features as
a completely different task than providing a UDP mapping to
LDAPv3.  It's my view that the while CLDAP might not met
all applications needs in regards to low-transport over
access to the directory, that CLDAP is a viable solution
for many of these applications.

>There are several

I agree that there are numerous methods for adding reliability
features to protocols running over UDP.  Providing means for
a client to:
        a) detect whether it has the complete result
        b) remove duplicates from the result
        c) reorder the responses into server generated order

is rather straight forward.  Yes, one could use a control
mechanism to provide such.

If we assume such a control was added to your I-D, I am not
sure your retry semantics are sound.  In particular, your suggestion
to reuse message ids (in the face of late arriving PDU from prior
uses) might be problematic.  Without details of your mechanism to
detect whether a retry is needed, it's hard for me to comment.  What
concerns me is that the "complexity" of message id reuse upon
detecting a, b, c on subsequent uses.  It is also not clear how
the retry mechanism would avoid repeated retries due to seemly
repeatable failures.

>what circumstances, share the same assigned port?

Well, if LDAPext is defining "LDAPv3 over UDP" as opposed to
"CLDAPv3", then I would think we should:
        a) reflect this in the charter (by dropping the sentence
           "The group will expand on the work developed for
           LDAPv2 in RFC 1798").
        b) progress an I-D stating that CLDAP is historic, and
        c) push forward on "LDAPv3 over UDP".

However, if LDAPext actually does end up defining CLDAPv3, then
CLDAPv3 should just obsolete RFC 1798.  So, for now, I don't
see an over

---

From: Leif Johansson <[email-masked]>
Date: Wed, 28 Feb 2001 09:26:33 +0100

The "focus" on operating system limitations is just one sencence which
can easily be removed wo impact on the argument.

You are right that the mechanism of combining results in a single PDU
was concieved for the express purpouse of overcoming UDP problems but
I still claim that the following is true:

1. Combining results in a single PDU is be a useful mechanism over
any transport (UDP or TCP). This should be written up as a separate
I-D.

2. Although CLDAP is very simple it is limited in that it does not
allow extensions or controls. In fact I claim that even if the draft 
were to be amended by saying that a "single-pdu-multiple-responses" 
control/extension SHOULD be used in most situations, then the draft 
would _still_ be better than 1798 by allowing further extensions to
be added to LDAP/UDP. I do not propose making this change though.

My feeling is that if LDAP/UDP is to have any chance of success it
needs to be folded into the framework of LDAPv3 even at the cost of
creating an admittedly non-compatible break with RFC1789.

I am not sure that I understand your problems with message id reuse.
Could you perhaps give an example? Please note that I do not claim
that this mechanism is the solution to all problems!

	Cheers Leif