Re: [tcpm] Comments on draft-kang-tcpm-subtype-capability-exchange-00

[Martin Duke <[e-mail]>]

After hearing the talk, I'm unclear on the use case this is addressing. I
see two possibilities:

1) Current v0 and v1 implementations don't support all the specified
subtypes, and there ought to be a way of negotiating this explicitly. I
haven't surveyed MPTCP implementations so I don't know if this is the case.

2) There should be a way for endpoints to negotiate use of new subtypes
without having to roll out a new version.

I don't think adoption is dependent on the answer here, but I would like to
understand the problem it is trying to solve.

On Thu, Mar 11, 2021 at 2:22 PM Martin Duke <[e-mail]> wrote:

> I can't speak to the problems subtype mismatches are causing, if any, but
> I do like the idea of negotiation extension of new subtypes without having
> to roll whole new MPTCP versions.
>
> I wonder if we could save some bits by assuming that 0x0-0x7 will be
> supported by all MPTCP implementations and omitting them from this field.
>
> The location of the OptionSupported field probably has to change along
> with other details of Figure 2. If I understand correctly, OptionSupported
> has to begin with the 5th byte, as this first goes out with the SYN where
> the entire (original) option is 4 bytes. Which means, we're relying on the
> length field to indicate this is not like other MP-CAPABLE options. I'm not
> sure this interoperability model is fully thought out.
>