Re: [dtn-interest] Fwd: I-D Action:draft-irtf-dtnrg-udp-clayer-00.txt

[Hans Kruse <[e-mail]>]

I can see a series of discussions on the list over the next few  
weeks ...

Two quick notes on principle:

(1) Yes, I think one draft can handle multiple DTN protocols; many of  
the points addressed are aspects of UDP, not
the protocol we are transporting over it.

(2) I think we should be careful here to specify a convergence layer  
only.  That means we certainly need to
make sure that we do not prevent use of things like multicast or  
unidirectional links.  On the other hand, if we
need network information (like an indication of unidirectionality),  
IMHO that should be specified in DTN first as a
part of either the network management infrastructure, or as a  
"requirement for lower protocol layers" as was
done in the LTP spec.

On Nov 20, 2008, at 8:52 AM, Joerg Ott wrote:

> Thanks, Hans, for getting us started on this.
>
> Taking a closer look at 5405 is indeed a very good idea.
>
> Another question is whether LTP should be discussed in this
> draft.  Maybe this is just a separate draft?
>
> In addition to unicast vs. multicast, we should probably
> mention what to do with unidirectional links.  In those
> case (which may be very legitimate) one never gets feedback
> from the peer(s).  It may deserve special consideration
> whether the channel is known to be unidirectional or
> whether there is just no response coming back.
>
> Just some initial thoughts,
> Joerg
>
> Eddy, Wesley M. (GRC-RCN0)[VZ] wrote:
>> It's a good start.  There are a few issues we can probably
>> correct quickly.
>> 1) The introduction should say "Internet Protocol networks"
>>   rather than "Internet Protocol links".
>> 2) Section 2.1, first sentence, about BP and LTP assuming
>>   an erasure channel may be inaccurate.  RFC 5050 does not
>>   mention an erasure channel assumption.
>> 3) Issues with fragmentation and checksums should be
>>   referencing RFC 5405 "Unicast UDP Usage Guidelines ..."
>>   which TSVWG has recently completed.  We should have an
>>   appendix that considers the UDP CLA's conformance to
>>   each guideline from section 5, table 1 of that document.
>>   Particularly, the keep-alive timer in 5405 is relevant
>>   to this doc, where no timer value has been suggested.
>>   Also, the differentiation between bulk and non-bulk
>>   transfers in 5405 is relevant here.  Transfers of
>>   bundles over a certain size might be considered bulk,
>>   while signaling bundles used for routing information
>>   exchange, admin records, etc. should follow the
>>   guidelines for non-bulk transfers IF no overlying
>>   CC mechanism (eg TFRC) is applied to the CLA attachment
>>   between BAs.
>>  4) Requiring UDP checksums breaks the intention that Kevin
>>   and others have described of allowing delivery of errored
>>   data to applications that would desire it rather than
>>   nothing.  Perhaps UDP-Lite should be recommended for
>>   selectively enabling when the BA can somehow detect this
>>   application preference (which we have no means for
>>   conveying currently, however).
>> 5) UDP can be sent to unicast or multicast addresses.  Do
>>   different behaviors for the CLA apply here?  I believe
>>   so.
>> 6) Section 3 goes far beyond the scope of this document by
>>   saying that the TCP CLA or LTP SHOULD be used.  This call
>>   does not belong in the document.  Simply discourage raw
>>   UDP-encapsulated bundles, and leave it at that.  Actually,
>>   the "SHOULD use a full-featured transport" guileline in
>>   5405 can simply be cited here as the reasoning.
>> 7) Transmission of LTP over UDP is only useful for the
>>   reasons of userland implementation, and perhaps the
>>   UDP checksum.  It could actually be run over IP rather
>>   than UDP, and section 4 should discuss why it isn't, or
>>   what the issues are.
>> 8) Nested parenthesis in last paragraph of 2.3 are awkward.
>> _______________________________________________
>> dtn-interest mailing list
>> [e-mail]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Hans Kruse, Professor
J. Warren McClure School of Information and Telecommunication Systems
Adjunct Associate Professor of Electrical Engineering and Computer  
Science
292 Lindley Hall, Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax