Re: [multipathtcp] MPTCP implementation feedback for RFC6824bis

[Matthieu Baerts <[e-mail]>]

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?

Best regards,
Matthieu


>
> Best regards,
> Alan
>
> On 11 Dec 2019, at 19:28, Christoph Paasch <[e-mail]> wrote:
>
> Hello Alan,
>
> there is one more thing that came up from the implementation experience
> (thanks to Matthieu & Paolo in CC).
>
> It is unclear in the draft (or at least, I didn't find the text ;-) ),
> what to do when the flags & version in the third ACK + MP_CAPABLE are
> inconsistent with what was negotiated in the SYN-SYN/ACK exchange.
>
> It would be good to spell this out and say that if there are any
> inconsistencies, a host should simply fallback to regular TCP.
>
>
> Christoph
>
> On Dec 10, 2019, at 8:09 AM, Alan Ford <[e-mail]> wrote:
>
> Hi Yoshifumi,
>
> On 10 Dec 2019, at 05:30, Yoshifumi Nishida <[e-mail]> wrote:
>
> Hi Alan,
>
> The texts look fine to me, but I have a few questions on them.
>
> On Fri, Dec 6, 2019 at 7:58 AM Alan Ford <[e-mail]> wrote:
>
>> Hi all,
>>
>> Following on from the discussion of implementation feedback with
>> Christoph, I propose the following edits to RFC6824bis - which is currently
>> in AUTH48 - as clarifications.
>>
>> ADs, please can you confirm you consider these edits sufficiently
>> editorial to fit into AUTH48.
>>
>> WG participants, please speak up if you have any concerns.
>>
>>
>> *Edit 1, clarifying reliability of MP_CAPABLE*
>>
>> Change the sentence reading:
>>
>>    The SYN with MP_CAPABLE occupies the first octet of data sequence
>> space, although this does not need to be acknowledged at the connection
>> level until the first data is sent (see Section 3.3).
>>
>> To:
>>
>>    The SYN with MP_CAPABLE occupies the first octet of data sequence
>> space, and this MUST be acknowledged at the connection level at or before
>> the time the first data is sent or received (see Section 3.3).
>>
>
> What implementations should do when they receive the first data before
> MP_CAPABLE is acked?
> They should terminate the connection or discard the data?
>
>
> By asking this question you have made me realise that this text is in fact
> incompatible with the case when A (the initiator) is also the first sender
> of data.
>
> Given the problem is only with B sending data first, let us forget this
> change, and revert to Christoph’s original problem text, and use only the
> below change:
>
> Change the sentence reading:
>>
>>    If B has data to send first, then the reliable delivery of the ACK +
>> MP_CAPABLE can be inferred by the receipt of this data with an MPTCP Data
>> Sequence Signal (DSS) option (Section 3.3).
>>
>> To:
>>
>>    If B has data to send first, then the reliable delivery of the ACK +
>> MP_CAPABLE is ensured by the receipt of this data with an MPTCP Data
>> Sequence Signal (DSS) option (Section 3.3) containing a DATA_ACK for the
>> MP_CAPABLE (which is the first octet of the data sequence space).
>>
>
> This will resolve the ambiguity in the case of B sending first.
>
> In my personal opinion either one of these edits would be sufficient for
>> making the point, however clearly this has caused some confusion amongst
>> the implementor community so making both these changes should make it
>> absolutely clear as to the expected behaviour here.
>>
>>
>> *Edit 2, mapping constraint*
>>
>> Change the sentence reading:
>>
>>    A Data Sequence Mapping does not need to be included in every
>> MPTCP packet, as long as the subflow sequence space in that packet
>> is covered by a mapping known at the receiver.
>>
>> To:
>>
>>    A Data Sequence Mapping MUST appear on a TCP segment which is covered
>> by the mapping. It does not need to be included in every MPTCP packet, as
>> long as the subflow sequence space in that packet is covered by a mapping
>> known at the receiver.
>>
>>
> What implementations should do when a Data Sequence Mapping doesn't cover
> the TCP segment that carries this option?
>
>
> There are a number of cases where the MUST does not have a consequence; it
> should be obvious from the text for similar failures that it can close it
> with a RST.
>
> BTW, This is not a strong opinion, but I may prefer a text like: "A Data
> Sequence Mapping MUST provide the mapping for the segment that carries this
> option.”
>
>
> OK how about: "A Data Sequence Mapping MUST provide the mapping which
> includes the segment that carries this option.”
>
> Regards,
> Alan
>
>
>
>
>

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