[dtn-interest] Comments on draft-irtf-dtnrg-dgram-clayer-01
Elwyn Davies <elwynd@folly.org.uk> Fri, 08 February 2013 15:02 UTC
Return-Path: <elwynd@folly.org.uk>
X-Original-To: dtn-interest@ietfa.amsl.com
Delivered-To: dtn-interest@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C21121F845E for <dtn-interest@ietfa.amsl.com>; Fri, 8 Feb 2013 07:02:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PW6d3AUjOQuD for <dtn-interest@ietfa.amsl.com>; Fri, 8 Feb 2013 07:02:44 -0800 (PST)
Received: from a.painless.aa.net.uk (a.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e33]) by ietfa.amsl.com (Postfix) with ESMTP id 05B3221F85DA for <dtn-interest@irtf.org>; Fri, 8 Feb 2013 07:02:44 -0800 (PST)
Received: from mightyatom.folly.org.uk ([81.187.254.250]) by a.painless.aa.net.uk with esmtp (Exim 4.77) (envelope-from <elwynd@folly.org.uk>) id 1U3pTu-0008Lz-9O; Fri, 08 Feb 2013 15:03:14 +0000
From: Elwyn Davies <elwynd@folly.org.uk>
To: DTN interest <dtn-interest@irtf.org>
Content-Type: text/plain
Organization: Folly Consulting
Date: Fri, 08 Feb 2013 15:02:56 +0000
Message-Id: <1360335776.4494.551.camel@mightyatom>
Mime-Version: 1.0
X-Mailer: Evolution 2.26.3
Content-Transfer-Encoding: 7bit
Cc: kruse@ohiou.edu, ostermann@eecs.ohiou.edu
Subject: [dtn-interest] Comments on draft-irtf-dtnrg-dgram-clayer-01
X-BeenThere: dtn-interest@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." <dtn-interest.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/dtn-interest>, <mailto:dtn-interest-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/dtn-interest>
List-Post: <mailto:dtn-interest@irtf.org>
List-Help: <mailto:dtn-interest-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/dtn-interest>, <mailto:dtn-interest-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Feb 2013 15:02:45 -0000
Hi, Hans, The changes to the draft look good. I sent in a review of -00 on Jan 14 but the comments don't seem to have been replied to/actioned.. there are at least a couple of editorial nits mentioned below. The comment about s3.4 is about the new text added in -01. Also I subsequently realized that the use of CL in section 3.4 et seq is potentially confusing. Regards, Elwyn Comments on DGRAM convergence layer draft (draft-irtf-dtnrg-dgram-clayer-01): Issues: s2: > TCP, a logical choice, guarantees reliability and provides congestion > control. Congestion control is vital to the continued functioning of > the Internet, particularly for situations where data will be sent at > arbitrarily fast data rates. Because the Bundle Protocol offers > neither congestion control nor reliability, TCP is the RECOMMENDED > choice for its encapsulation. draft-irtf-dtnrg-tcp-clayer > [I-D.irtf-dtnrg-tcp-clayer] defines the method for transporting > bundles over TCP. In the case where bundles are transported directly > in datagrams, the use of DCCP is RECOMMENDED. It strikes me that if we are going to RECOMMEND TCP then this statement belongs in the TCP document rather than here. Actually what we doing is not really RECOMMENDING it but pointing out that you can build a simple congestion-friendly CL over a TCP transport with particular characteristics (reliability, in-order delivery, etc) - but if you have a convergence layer that already has some of the characteristics of TCP then you don't need to (indeed, should absolutely not) use TCP as transport as you will get conflict. I suggest replacing as follows: OLD: TCP, a logical choice, guarantees reliability and provides congestion control. Congestion control is vital to the continued functioning of the Internet, particularly for situations where data will be sent at arbitrarily fast data rates. Because the Bundle Protocol offers neither congestion control nor reliability, TCP is the RECOMMENDED choice for its encapsulation. draft-irtf-dtnrg-tcp-clayer [I-D.irtf-dtnrg-tcp-clayer] defines the method for transporting bundles over TCP. In the case where bundles are transported directly in datagrams, the use of DCCP is RECOMMENDED. LTP, on the other hand, offers its own form of reliability. Particularly for testing purposes, it makes no sense to run LTP over a protocol, like TCP, that offers reliability already. In addition, running LTP over TCP would reduce the flexibility available to users, since LTP offers more control over what data is delivered reliably and what data is delivered best effort, a feature that TCP lacks. As such, it would be better to run LTP over an unreliable protocol. NEW: Congestion control is vital to the continued functioning of the Internet, particularly for situations where data will be sent at arbitrarily fast data rates. The Bundle Protocol delegates provision of reliable delivery and, implicitly, congestion control to the convergence layer used (Section 7.2 of [RFC5050]). In situations where TCP will work effectively in communications between pairs of DTN nodes, use of the TCP convergence layer [I-D.irtf-dtnrg-tcp-clayer] will provide the required reliability and congestion control for transport of bundles and would be the default choice in the Internet. Alternatives such as encapsulating bundles in directly in datagrams and using UDP or the Datagram Congestion Control Protocol (DCCP) are not generally appropriate because they offer limited reliability and, in the case of UDP, no congestion control. LTP, on the other hand, offers its own form of reliability. Particularly for testing purposes, it makes no sense to run LTP over a protocol, like TCP, that offers reliability already. In addition, running LTP over TCP would reduce the flexibility available to users, since LTP offers more control over what data is delivered reliably and what data is delivered eith best efforts, a feature that TCP lacks. As such, it would be better to run LTP over an unreliable protocol. s3.4 > If a connection between two bundle agents is bi-directional, > transmission and processing of keep-alives in the two directions > occurs independently. Using the term 'connection' for a UDP-based communication is inappropriate... it specifically does not have any ongoing relationahip at the UDP layer. Perhaps better: If UDP is being used for communication in both directions between a pair of bundle agents, transmission and processing of keep-alives in the two directions occurs independently. ss3.4 - 3.6 and all sub-sections: The use of the terms Datagram Convergence Layer and CL are probably inapprpriate and potentially confusing because this CL is NOT the same as the Bundle Protocol CL that is being used in the rest of the document. Referring to RFC 5325, the transport used under LTP is called the "local data link layer" and we should be using this term here I think - or alternatively use just "transport" after the first time. Editorial/Nits: s3.1: Probably worth an aside to record that jumbograms are mostly of the pink elephant variety. s3.2, para 1: Should include that the recommendation for TCP or LTP applies to IP based networks only. There are other networks... Bluetooth, AX25, etc. Suggest at least: OLD: In general, the use of the bundle protocol over a datagram CL is discouraged. NEW: In general, the use of the bundle protocol over a datagram CL in IP networks is discouraged. s3.3, last line: s/insure that every LTP segments/ensure that every LTP segment/ ^ x ^ Regards, Elwyn
- [dtn-interest] Comments on draft-irtf-dtnrg-dgram… Elwyn Davies