Re: [multipathtcp] MPTCP implementation feedback for RFC6824bis

[Matthieu Baerts <[e-mail]>]

Hi Alan,

Thank you for your reply.

On Fri, Dec 13, 2019 at 1:38 PM Alan Ford <[e-mail]> wrote:

> Hi Matthieu,
>
> On 13 Dec 2019, at 00:10, Matthieu Baerts <[e-mail]>
> wrote:
>
> Hi Alan,
>
>
> On Thu, Dec 12, 2019 at 10:19 PM Alan Ford <[e-mail]> 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.
>

Even if at some point, we thought about not checking the version in the 3rd
ACK because it was a bit unclear for us, we now do fallback to regular TCP
if the version in the 3rd ACK is not the expected one.
So it seems that at the end, we correctly interpreted the RFC there. If you
feel that no clarification is needed for that, that's fine for us!

Best regards,
Matthieu
-- 
[image: Tessares SA] <http://www.tessares.net> Matthieu Baerts | R&D
Engineer
[e-mail]
Tessares SA | Hybrid Access Solutions
www.tessares.net
1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium

Disclaimer: https://www.tessares.net/mail-disclaimer/