[multipathtcp] Re: comments on draft-baerts-tcpm-mptcpdss-00

[Matthieu Baerts <[e-mail]>]

Hi Yoshi,

Thank you for your reply! Please see my comments below:

On 16/07/2025 18:51, Yoshifumi Nishida wrote:
> On Tue, Jul 15, 2025 at 2:10 PM Matthieu Baerts
> <[e-mail]> wrote:
>> On 15/07/2025 05:55, Yoshifumi Nishida wrote:
>>> Hi Matt, Olivier,
>>>
>>> Thanks for providing an interesting draft.
>>
>> Thank you for your review!
>>
>>> I think the idea of the draft is straightforward and makes sense to me.
>>> I think the draft needs to clarify the following points for
>>> further improvements.
>>>
>>> 1: It seems to me that using 'D' flag in MP_CAPABLE for this proposal
>>> doesn't exactly match the description of RFC8864. Because, in my
>>> understanding, flags D through H are used for crypto algorithm
>>> negotiations.
>>
>> Good point. Our understanding is that flag bits "D" through "G" are
>> "reserved" for future uses. RFC8684 seems to suggest [1] they might be
>> used for crypto algorithm negotiation, but we don't think the intension
>> was to limit these reserved flags only to that:
>>
>>> The remaining bits, labeled "D" through "H", are used for crypto
>>> algorithm negotiation. In this specification, only the rightmost bit,
>>> labeled "H", is assigned.
>>
>> [1] https://datatracker.ietf.org/doc/html/rfc8684#section-3.1-20.8
>>
>> Do you think the draft should mention this interpretation? Or should we
>> have this clarification in RFC8684 directly?
> 
> My personal preference is to clarify this point in the doc. Also, I
> think we might want to specify to update 8684 in the draft.
> But, I think we can discuss this point later and check what people prefer.

Good idea, we can discuss that at my presentation on Wednesday.

>>> 2: I'm not very sure how responders can fall back to normal MPTCP when
>>> they don't support this feature. When they cannot support any requested
>>> features in MP_CAPABLE, will they fall back to regular TCP rather than
>>> normal MPTCP by sending SYN ACK without MP_CAPABLE options?
>>
>> Compared to RFC8684, the only difference in the SYN + MP_CAPABLE is the
>> 'D' flag. The rest, including the Data-Level Length (16 bits) and the
>> checksum (16 bits, optional), are not modified. For the SYN -- for TCP
>> FastOpen for example -- we don't think there is a need to have a DLL
>> larger than 16 bits which would break the possibility of a fallback to
>> RFC8684 without this extension. Keeping the DLL on 16 bits in the
>> MP_CAPABLE seems safer.
>>
>> The draft tries to explain that at the end [2]:
>>
>>> Even when the TBD Flag is set to 1, the MP_CAPABLE options continue to
>>> use a 16-bit Data-Level Length like before, to allow fallback if the
>>> receiver doesn't support a 32-bit Data-Level Length.
>> [2]
>> https://www.ietf.org/archive/id/draft-baerts-tcpm-mptcpdss-00.html#section-3-9
>>
>> Is this enough for you, or should it be clearer?
> 
> OK. I think this is fine. Thanks for the clarification.

Great, thank you!

Cheers,
Matt