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

"Eddy, Wesley M. (GRC-RCN0)[VZ]" <Wesley.M.Eddy@nasa.gov> Wed, 19 November 2008 23:26 UTC

Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id mAJNQvtt004355 for <dtn-interest@mailman.dtnrg.org>; Wed, 19 Nov 2008 15:26:58 -0800
Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id C24202D80CD; Wed, 19 Nov 2008 17:06:59 -0600 (CST)
Received: from ndjsxgw04.ndc.nasa.gov (ndjsxgw04.ndc.nasa.gov [129.166.32.112]) by ndjsppt03.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id mAJN6wlf000487; Wed, 19 Nov 2008 17:06:58 -0600
Received: from NDJSEVS25A.ndc.nasa.gov ([129.166.32.124]) by ndjsxgw04.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Nov 2008 17:06:59 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 19 Nov 2008 17:07:04 -0600
Message-ID: <B5A5E01F9387F4409E67604C0257C71E7A3981@NDJSEVS25A.ndc.nasa.gov>
In-Reply-To: <B7AB292F-1702-49CA-8ECD-2412B5DA2405@ohiou.edu>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [dtn-interest] Fwd: I-D Action:draft-irtf-dtnrg-udp-clayer-00.txt
Thread-Index: AclKkzo7DlRTUtYeR7GsdMbUeMd3UgABQaZg
References: <20081119213002.0017E3A6895@core3.amsl.com> <B7AB292F-1702-49CA-8ECD-2412B5DA2405@ohiou.edu>
From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <Wesley.M.Eddy@nasa.gov>
To: Hans Kruse <kruse@ohiou.edu>, Delay Tolerant Networking Interest List <dtn-interest@mailman.dtnrg.org>
X-OriginalArrivalTime: 19 Nov 2008 23:06:59.0816 (UTC) FILETIME=[86C42E80:01C94A9B]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id mAJNQvtt004355
Subject: Re: [dtn-interest] Fwd: I-D Action:draft-irtf-dtnrg-udp-clayer-00.txt
X-BeenThere: dtn-interest@maillists.intel-research.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Delay Tolerant Networking Interest List <dtn-interest.maillists.intel-research.net>
List-Unsubscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-interest>, <mailto:dtn-interest-request@maillists.intel-research.net?subject=unsubscribe>
List-Archive: <http://maillists.intel-research.net/pipermail/dtn-interest>
List-Post: <mailto:dtn-interest@maillists.intel-research.net>
List-Help: <mailto:dtn-interest-request@maillists.intel-research.net?subject=help>
List-Subscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-interest>, <mailto:dtn-interest-request@maillists.intel-research.net?subject=subscribe>
X-List-Received-Date: Wed, 19 Nov 2008 23:26:58 -0000

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.