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

[Matthieu Baerts <[e-mail]>]

Hi Yoshi,

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?


> 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?

Cheers,
Matt