[dtn] TCPCL version negotiation

[Brian Sipos <[e-mail]>]

All,
This is a thread to discuss version negotiation in TCPCL. Currently the contact header has a 5-octet preamble which is a 4-octet "magic" byte string and a 1-octet version number.
In TCPCLv3 the contact header (CH) exchange was assumed to be simultaneous (no required ordering) and there was a "Version mismatch" termination reason for any disagreement.

The requirements in TCPCLv4 have been tightened to require the active entity (initiator of the TCP connection) to send a CH first and the passive entity (listener for TCP connection) to send its CH in response. There is still a single "Version mismatch" termination reason, but there is the possibility for the passive CH to adapt to the received version if it is supported.

There is a possibility for an active entity to send a version which is either too-low for the passive to support or too-high, but no way for the passive peer to indicate the distinction. So an active entity can send a CH with version N, see a "version mismatch" and try N-1, N-2, and so on until the client fails to achieve any CL session. The reason for failure may be that the passive entity only supports version N+1 but the active entity wastes N TCP connections to discover this.

Does it make sense to split termination reason codes for too-low and too-high (assuming that future TCPCL will have the same CH preamble structure)?
This would allow an active entity to shortcut the negotiation if it receives a "Version too-low" termination because there would be no reason to attempt any more. But as Rick mentioned at the IETF, this assumes that a v5 or later TCPCL entity would bother to implement a trivial v4 CH detection and termination.