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
- [dtn-interest] Review of draft-irtf-dtnrg-tcp-cla… Elwyn Davies
- Re: [dtn-interest] Review of draft-irtf-dtnrg-tcp… Simon Perreault
- Re: [dtn-interest] Review of draft-irtf-dtnrg-tcp… Elwyn Davies
- Re: [dtn-interest] Review of draft-irtf-dtnrg-tcp… Simon Perreault
- Re: [dtn-interest] Review of draft-irtf-dtnrg-tcp… Elwyn Davies