Re: [multipathtcp] MPTCP implementation feedback for RFC6824bis

[Yoshifumi Nishida <[e-mail]>]

Hi Alan,

On Tue, 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.
>

Thanks. this makes sense to me. But, I am wondering if we want to make the
use of DATA_ACK mandatory in this case.
How about something like: "if B has data to send first, then it MUST use 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) to
provide the reliable delivery of the ACK + MP_CAPABLE."?

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.”
>

Works for me. Thanks!
--
Yoshi