Subject: [dtn] TCPCLv4 feedback

From: Brian Haberman <[email-masked]>
Date: Fri, 23 Mar 2018 06:10:02 -0400

Just following up from my comments at the mic...

1. Version mismatch shutdown - It seems reasonable to add
reason-specific guidance when sending a SHUTDOWN message. For example,
when a version mismatch occurs, I would expect a TCPCL implementation to
keep the TCP connection up and do some form of version negotiation with
the peer. This avoids scenarios where a TCPCL implementation: 1) opens a
TCP connection, 2) sends a CONTACT header, 3) receives a SHUTDOWN, 4)
sends a SHUTDOWN, 5) tears down the TCP connection, and 6) starts the
process all over.

2. There are places in the draft where a TCPCL *SHOULD* perform some
action (e.g., exponential backoff when retrying a TCP connection). Where
possible, it would be helpful to provide some description of
situations/parameters that may impact that directive.

3. If a MSG_REJECT is sent by a node, should there be any impact on the
underlying connection? For example, if a node rejects the same message
some number of times, should it close the connection? The same question
applies to other messages like XFER_REFUSE.

4. While Figure 2 provides an example message flow, I think the
readability of the spec would be improved with the addition of state
transition diagram.

Regards,
Brian

---

From: Victoria Pritchard <[email-masked]>
Date: Fri, 23 Mar 2018 11:29:08 +0000

Replying on list this time - doh!

Hi Brian,

Just a note on point 1.

> sends a SHUTDOWN, 5) tears down the TCP connection, and 6) starts the
I believe that the SHUTDOWN in this case can only happen after both sides
have sent a contact header anyway. In which case, imagine one side sends a
contact header with version=4, and the responder sends a contact header
with version=3. As you said, the responder may immediately follow that with
a SHUTDOWN since the versions don't match. I think the better suggestion
might be that it would wait at this point, for the initiator to respond.
The initiator could send a second contact header with version=3, then the
session can progress according to version 3. Otherwise, the initiator
should be the one to send the SHUTDOWN.

Kind regards,
Vicky.

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