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

[Simon Perreault <[e-mail]>]

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