Re: [dtn-interest] Review of draft-irtf-dtnrg-tcp-clayer-04

Elwyn Davies <> Mon, 14 January 2013 18:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5E27321F855A for <>; Mon, 14 Jan 2013 10:58:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.028
X-Spam-Status: No, score=0.028 tagged_above=-999 required=5 tests=[AWL=-0.768, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_74=0.6, MIME_QP_LONG_LINE=1.396, SARE_SUB_RAND_LETTRS4=0.799]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wq943iMX+vBe for <>; Mon, 14 Jan 2013 10:58:26 -0800 (PST)
Received: from ( [IPv6:2001:8b0:0:30::51bb:1e33]) by (Postfix) with ESMTP id EE28321F8566 for <>; Mon, 14 Jan 2013 10:58:24 -0800 (PST)
Received: from ([]) by with esmtp (Exim 4.77) (envelope-from <>) id 1TupEk-0003hG-Px; Mon, 14 Jan 2013 18:58:23 +0000
From: Elwyn Davies <>
To: Simon Perreault <>
In-Reply-To: <>
References: <1358181196.28723.7028.camel@mightyatom> <>
Content-Type: text/plain; charset="ISO-8859-1"
Organization: Folly Consulting
Date: Mon, 14 Jan 2013 18:56:55 +0000
Message-Id: <1358189815.28723.7270.camel@mightyatom>
Mime-Version: 1.0
X-Mailer: Evolution 2.26.3
Content-Transfer-Encoding: quoted-printable
Subject: Re: [dtn-interest] Review of draft-irtf-dtnrg-tcp-clayer-04
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 14 Jan 2013 18:58:27 -0000

On Mon, 2013-01-14 at 18:19 +0100, Simon Perreault wrote:
> Hi Elwyn,
> Le 2013-01-14 17:33, Elwyn Davies a écrit :
> > Issues:
> > s1, Protocol Version:  Arguably, the version of the protocol defined
> > here is actually version 4.  The LENGTH message has been added to at
> > draft version 03 and some implementations (notably DTN2) do not
> > understand the LENGTH message.  Sending LENGTH messages to DTN2 will
> > break it - and DTN2 thinks the version is 3.
> Sending LENGTH to DTN2 would be a bug in the first place because:
>     LENGTH messages MUST NOT be sent unless the corresponding flag bit is
>     set in the contact header.
> DTN2 would not set that flag.
> LENGTH is a backwards-compatible addition. No need to increment the 
> protocol version.
True.. OK I'll settle for Version 3.
> > PS Adding the length message was a good thing!  I'll try and generate a
> > patch for DTN2 to at least accept the message and possibly send it.
> Cool! :)
> > - The specification should discuss whether the endpoints should impute
> > or not that reactive fragmentation should be carried out if a bundle is
> > refused part way through.  It would probably help if the receiver could
> > give a reason with the REFUSE_BUNDLE.  If the reason is that the
> > receiver now has the complete bundle and doesn't need the rest to be
> > sent then the sender can assume the bundle has been transmitted and act
> > accordingly.  If the reason is resource exhaustion at the receiver then
> > reactive bundle fragementation is desirable.  Finally the receiver may
> > have encountered a problem that requires the bundle to be retransmitted
> > in its entirety 
Incidentally I thought of why this might realistically happen: 
(e.g., has accepted a higher priority bundle on another link).
> > - A reason code could be included with the REDUSE_BUNDLE message using
> > one of the currently unused flags to indicate its presence.  The default
> > semantics if the reason code is missing should be defined.
> This is a good idea. However we have to keep backwards-compatibility in 
> mind. Remaining backwards-compatible is a goal of this whole effort.
> I can see two ways forward:
> a) Don't change the draft. Publish this "enhanced refuse" in a separate 
> draft, as an extension.
> b) Add a new message type code. Negotiate its usage in the contact 
> header. Like we did for LENGTH.
> Any other idea?
c) Encode the reason in the flags bits. 3 reasons and another bit left
incase we think of some other reasons?  Bit naughty but not a big issue.

Failing that add a new enhanced refuse message type as per (b). 
> > s4/s6.1:
> >> A node MAY decide to re-attempt to establish the
> >>     connection, perhaps.  If it does so, it MUST NOT overwhelm its target
> >>     with repeated connection attempts.  Therefore, the node MUST retry
> >>     the connection setup only after some delay and it SHOULD use a
> >>     (binary) exponential backoff mechanism to increase this delay in case
> >>     of repeated failures.
> >
> > This text in s4 should refer to s6.1 where an optional reconnection
> > delay can be specified with the shutdown message.  It should probably
> > recommend default initial delay before additional connection attempts if
> > the shutdown message doesn't specify it.
> Any idea what actualy value we should recommend?
> There must be at least 100 IETF protocols with this kind of mechanism 
> built in...
Well, actually there aren't that many it seems.  And the range of values
suggested is quite large 1 second (ORACLE/ODBC DBMS server failover) ,
through 30 seconds to 30 minutes(SMTP delivery). Suggest :

The initial delay SHOULD be at least 1 second but SHOULD be configurable
and will be application and network type dependent.
> > Also there should be some
> > words about what a node which has specified a reconnection delay that is
> > ignored by the receiving node.. ignore it? send a new immediate shutdown
> > maybe with a new, longer delay?

There is a DoS opportunity here in that s6.1 says we have to send the
contact header (and implicitly complete the TCP setup).  OTOH, there is
(to the best of my knowledge) no way to tell OS'es to ignore incoming
SYNs from a particular address for a while.  Probably the best one can
do is to hold off sending the contact header for a while.
> IMHO that is up to the implementation. Any reason why it should be 
> specified?
> > Presumably the default is that the
> > receiving node should apply the exponential backoff starting from the
> > specified reconnection delay.
> Agreed.
> > s9: Do we need IANA registries for:
> > - Protocol version (would want 'specification required' control)
> > - Message types
> > - Shutdown reason codes
> > - (If we add them) Refusal reason codes
> > - Flag definitions
> >
> > Inclined to think we could get away with just protocol version.
> I think we need at least message types as well.
> > Editorial/Nits:
> > s2.1, SDNV section: Should refer to RFC 6256 for more info on SDNVs.
> >
> > s4.2:
> >> The bundle refusal capability may only be used iff both peers
> >>          indicate support for it in their contact header.
> > Should ad: .. and segment acknowledgement has been enabled.
> >
> > s7: The RFC 2119 wording should be moved up to be section 2.
> Thanks for the review! I'll edit the changes shortly.
> > Notes re DTN2 implementation:
> > - Doesn't support BUNDLE_REFUSAL
> > - Doesn't support LENGTH messages and hemce will break if sent LENGTH
> > messages
> > - Never sends a reconnect delay (can accept them but ignores the
> > supplied value)
> Cool, thanks. I guess the draft is still compatible with DTN2 as long as 
> the unsupported features have a corresponding flag in the contact 
> header. REFUSE and LENGTH have such a flag, and the delay is optional 
> and signalled with a flag in the message itself, so we're good.
> Thanks!
> Simon

One additional thing I had meant to say and forgot:
The only mention of the ability to use a single TCP connection for
bidirectional communication (in the sense of sending bundles from A to B
and B to A on a single TCP connection is in a cryptic reference in s3:

>    When acknowledgments are enabled, then for each data segment that is
>    received, the receiving node sends an ACK_SEGMENT code followed by an
>    SDNV containing the cumulative length of the bundle that has been
>    received.  Note that in the case of concurrent bidirectional
>    transmission, then ack segments may be interleaved with data
>    segments.

I would add an explanation of this to s3.. maybe a new subsection:
3.1.  Bidirectional Use of TCP Connection

Since each message type used in the TCPCL protocol in association with
sending a bundle is only sent in a specific direction (DATA_SEGMENT and
LENGTH from bundle sender to receiver, ACK_SEGMENT and REFUSE_BUNDLE
from receiver to sender) with the remaining messages (KEEPALIVE and
SHUTDOWN) being associated with the connection rather than a particular
bundle, a single TCP connection can be used bidirectionally to send
bundles concurrently from either end to the other.

Note that in the case of concurrent bidirectional transmission, ack
segments may be interleaved with data segments.

(and remove this sentence from prior occurrence in s3.)


> dtn-interest mailing list