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

From: Elwyn Davies <[email-masked]>
Date: Mon, 14 Jan 2013 16:33:16 +0000

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)

---

From: Simon Perreault <[email-masked]>
Date: Mon, 14 Jan 2013 18:19:19 +0100

Hi Elwyn,

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

> patch for DTN2 to at least accept the message and possibly send it.

Cool! :)

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

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

Agreed.

> Inclined to think we could get away with just protocol version.

I think we need at least message types as well.

> s7: The RFC 2119 wording should be moved up to be section 2.

Thanks for the review! I'll edit the changes shortly.

> - Never sends a reconnect delay (can accept them but ignores the

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

---

From: Elwyn Davies <[email-masked]>
Date: Mon, 14 Jan 2013 18:56:55 +0000

> LENGTH is a backwards-compatible addition. No need to increment the 
True.. OK I'll settle for Version 3.
> > in its entirety 
Incidentally I thought of why this might realistically happen: 
(e.g., has accepted a higher priority bundle on another link).
> header. Like we did for LENGTH.
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). 
> There must be at least 100 IETF protocols with this kind of mechanism 
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.
> > maybe with a new, longer delay?
Hmm.

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.
> and signalled with a flag in the message itself, so we're good.

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

Regards,
Elwyn

_______________________________________________
> dtn-interest mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/dtn-interest

---

From: Simon Perreault <[email-masked]>
Date: Tue, 15 Jan 2013 10:40:59 +0100

> incase we think of some other reasons?  Bit naughty but not a big issue.

Works for me.

> and will be application and network type dependent.

Works for me.

> do is to hold off sending the contact header for a while.

Well, there is a range of things one can do:

a) Once accept() returns, close() the socket if the remote address is evil.

b) Instead of closing, keep the socket open but delay sending the 
contact header.

c) Send a SHUTDOWN as soon as possible.

d) Send a SHUTDOWN after a delay.

e) Combinations of the above...

I think everything is fine and it is up to the implementation to decide 
exactly what to do. It is especially important that it be considered 
legal to just close a TCP connection without sending a contact header. 
So how about simply adding text saying that a server MAY do this kind of 
thing for security purposes?

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

Agreed. This is important.

Thanks,
Simon

---

From: Elwyn Davies <[email-masked]>
Date: Tue, 15 Jan 2013 10:27:11 +0000

Hi, Simon.
> > incase we think of some other reasons?  Bit naughty but not a big issue.
OK, I'll ping the dtn-users mailing list just to make sure nobody has
serious objections to this plan.
> > and will be application and network type dependent.
OK
> thing for security purposes?
Fair enoungh.  Will have to:
- Modify the last sentence of the following in s6.1:

>    A connection shutdown MAY occur immediately after TCP connection
>    establishment or reception of a contact header (and prior to any
>    further data exchange).  This may, for example, be used to notify
>    that the node is currently not capable of or willing to communicate.
>    However, a node MUST always send the contact header to its peer
>    first.
> 
- Add a comment to the security considerations.

> Agreed. This is important.

Good.

Look forward to new version.

Regards,
Elwyn