On 13 Dec 2019, at 00:10, Matthieu Baerts <matthieu.baerts@tessares.net> wrote:

Hi Alan,

On Thu, Dec 12, 2019 at 10:19 PM Alan Ford <alan.ford@gmail.com> wrote:
Hi Christoph (and Matthieu & Pablo),

WRT checksums, we do say:

For example,
if the initiator sets A=0 in the SYN but the responder sets A=1 in
the SYN/ACK, checksums MUST be used in both directions, and the
initiator will set A=1 in the ACK.

If A=1 is received by a host that does not
want to use checksums, it MUST fall back to regular TCP by ignoring
the MP_CAPABLE option as if it was invalid.

Which would seem to cover all these eventualities. The “C” bit is purely an indicator, and the crypto negotiation is clearly specified too.

Thank you for your answer, that's clearer for the A bit.
Our concern was mainly about the version. How should we react if, as a server supporting only v1, we have this sequence:

SYN (MP_CAPABLE: v2) →
← SYN+ACK (MP_CAPABLE: v1)
ACK (MP_CAPABLE v2) →

In other words, the server told the client that the maximum version it supports is v1. But in the ACK+MP_CAPABLE, the client sends v2 again.

According to the RFC, the negotiation is done in the SYN and SYN+ACK. How do we react if the following ACK is sending a version (e.g. v2) which is not the expected one (e.g. v1)?

For the moment in our implementation, we fallback to regular TCP.
It means that future versions of MPTCP have to set the proper version in the 3rd ACK -- the negotiated one -- and not a copy of what has been sent in the SYN.

Should we add a clarification for that?

I see your point but I don’t feel we need any clarification here. The exchange as you rightly point out is done on the SYN/SYN+ACK. So when the server sends the SYN+ACK with v1, that is the decision that has been made. Sending an ACK with v2 is not a valid response. So if the server receives this, it treats it as any other invalid option and ignores it, so it treats it as if the ACK does not have an MP_CAPABLE, and thus it will fall back to regular TCP.