MIME-Version: 1.0
References: 
 <CAAK044STo8k0F0vVgHUmz3mmb9hROz0LyTvfCRJA1Hmf8Dyv4w@mail.gmail.com>
 <a6e24f3f-980f-4058-9bce-46e371a9b38f@uclouvain.be>
In-Reply-To: <a6e24f3f-980f-4058-9bce-46e371a9b38f@uclouvain.be>
From: Yoshifumi Nishida <nsd.ietf@gmail.com>
Date: Wed, 16 Jul 2025 09:51:00 -0700
Message-ID: 
 <CAAK044S4vL_b=xh3U9GxKW5VFFNbDZ2q4t8LTopnAevOk=6Ekw@mail.gmail.com>
To: Matthieu Baerts <matthieu.baerts@uclouvain.be>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: 4UNWT7KAM4D745VVZ6YEB7EFPQEMAOVQ
CC: "tcpm@ietf.org Extensions" <tcpm@ietf.org>,
 multipathtcp <multipathtcp@ietf.org>,
 Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Precedence: list
Subject: =?utf-8?q?=5Bmultipathtcp=5D_Re=3A_comments_on_draft-baerts-tcpm-mptcpdss-00?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/multipathtcp/ssD3ksuCynmJAAxqFfcUu7rt4ec>

Hi Matt,

Thanks for your reply. I put my comments in lines.

On Tue, Jul 15, 2025 at 2:10=E2=80=AFPM Matthieu Baerts
<matthieu.baerts@uclouvain.be> 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#sectio=
n-3-9
>
> Is this enough for you, or should it be clearer?

OK. I think this is fine. Thanks for the clarification.
--
Yoshi