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

[Joerg Ott <[e-mail]>]

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
>