Subject: [multipathtcp] Re: comments on draft-baerts-tcpm-mptcpdss-00
From: Yoshifumi Nishida <[email-masked]>
To: Matthieu Baerts <[email-masked]>
Cc: "[email-masked] Extensions" <[email-masked]>, multipathtcp <[email-masked]>, Olivier Bonaventure <[email-masked]>
Date: Wed, 16 Jul 2025 09:51:00 -0700
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>

Hi Matt,

Thanks for your reply. I put my comments in lines.

On Tue, Jul 15, 2025 at 2:10 PM Matthieu Baerts
<[email-masked]> wrote:
>
> 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?

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.

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