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

Simon Perreault <simon.perreault@viagenie.ca> Mon, 14 January 2013 17:18 UTC

Return-Path: <simon.perreault@viagenie.ca>
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 11BE321F87FD for <dtn-interest@ietfa.amsl.com>; Mon, 14 Jan 2013 09:18:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.2
X-Spam-Level:
X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=-0.400, 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 TGteP8tlbnmD for <dtn-interest@ietfa.amsl.com>; Mon, 14 Jan 2013 09:18:33 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD0721F8738 for <dtn-interest@irtf.org>; Mon, 14 Jan 2013 09:18:33 -0800 (PST)
Received: from [127.0.0.1] (unknown [193.49.159.161]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 781EC40397 for <dtn-interest@irtf.org>; Mon, 14 Jan 2013 12:18:32 -0500 (EST)
Message-ID: <50F43E17.2080707@viagenie.ca>
Date: Mon, 14 Jan 2013 18:19:19 +0100
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: dtn-interest@irtf.org
References: <1358181196.28723.7028.camel@mightyatom>
In-Reply-To: <1358181196.28723.7028.camel@mightyatom>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [dtn-interest] Review of draft-irtf-dtnrg-tcp-clayer-04
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: Mon, 14 Jan 2013 17:18:34 -0000

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.

> 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! :)

> s3, REFUSE BUNDLE:
> - 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.
> - 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?

> 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...

> 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?

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