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.
- Re: [dtn-interest] Fwd: I-D Action:draft-irtf-dtn… Hans Kruse
- Re: [dtn-interest] Fwd: I-D Action:draft-irtf-dtn… Joerg Ott
- Re: [dtn-interest] Fwd: I-D Action:draft-irtf-dtn… Eddy, Wesley M. (GRC-RCN0)[VZ]
- [dtn-interest] Fwd: I-D Action:draft-irtf-dtnrg-u… Hans Kruse