[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