Re: I-D ACTION:draft-ietf-ldapext-cldap-00.txt

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 11:53 AM 6/5/00 -0600, Sukanta Ganguly wrote:
>Hi,
>  You folks state that IP fragmentation is not a issue with CLDAP.

It is an issue...  I argue that implementations should avoid
IP fragmentation but must be able to interoperate in the face
of IP fragmentation.

>Where would one have an implementation wherein the reliability
>that we expect from TCP could be taken care of?

Note that IP fragmentation occurs below TCP.  The IP deals with
the fragmentation/reassembly, not TCP.  TCP needs to be able to
retransmit lost whole IP datagrams.  It should, of course, avoid
IP fragmentation where possible.

Likewise, UDP doesn't see fragments.  It sees whole IP datagrams.
If the IP layer cannot reassemble, then the datagram is dropped
and UDP ignores it like it would any other dropped datagram.
CLDAP should avoid causing IP fragmentation and must deal with
lost, duplicated, and/or reordered of UDP datagrams.

>I guess I am having a difficult time understanding as to where would the UDP packet retransmissions in case of losses would be handled? There are many more to the related issue like packet re-ordering etc.

The CLDAP specification must specify the behavior of implementations
in face of lost, duplicated, and/or reordered whole UDP datagrams
irregardless of whether this is to handled at or above
CLDAP.  The current spec needs work here... it's rev 0 afterall.

>  If we do not have this in the Network layer (i.e. layer 3) then either the application needs to handle them, which would be another overhead that the LDAP server needs to handle/manage or the application clearly would not care for it.

Handling of such must be done by both peers, whether at, below, or
above the CLDAP layer.

> I can't imagine the case where in LDAP applications are ignorant to the fact that some of the data they send and receive may not actually come to them.

I can.  Data availability is not a constant.

>  I think there needs to be serious effort in addressing them as the CLDAP server implementors would have a great deal of heart burn implementing them.

s/server/client and server/   It's a two way street.

I do concur that CLDAP specification is a significant undertaking.