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

[Elwyn Davies <[e-mail]>]

A few comments on the TCP convergence layer draft:

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.

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

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.  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? Presumably the default is that the
receiving node should apply the exponential backoff starting from the
specified reconnection delay.

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.

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.

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)

Regards
Elwyn Davies
(Sorry its a bit late)