Re: [tcpm] I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt

[Yoshifumi Nishida <[e-mail]>]

Hi Joe,

On Fri, Feb 12, 2021 at 8:45 PM Joseph Touch <[e-mail]> wrote:

>
>
> On Feb 12, 2021, at 9:52 AM, Yoshifumi Nishida <[e-mail]> wrote:
>
> OK. So, in my understanding, what you're suggesting are the followings.
>
> - Aggregated options would be useful. but, the format can be simple 4
> bytes length option that can accomodate 16 options.
>
>
> Yes,
>
> - The tricks to avoid reflecting options in SYN ACK will not be needed
> because it's the receiver's responsibility.
>
>
> Yes.
>
> - Delayed negotiation might be possible. But, no generic framework is
> needed. Each option should be designed for its own way to support it.
>
>
> Yes.
>
> But, once thing I am wondering is that we can still combine Aggregated
> options and delayed negotiation even with this one.
>
>
> Delayed negotiation is a completely separate and very complicated issue.
> It’s not as simple as “do it later”; in the TWHS, the sequence of messages
> is defined. Elsewhere, messages can come out of order - at which point the
> meaning of options with respect to that order has to be defined. That’s a
> can of worms and completely independent of whether aggregated options are
> supported.
>
> if you are meaning options not appeared in SYN cannot be used in the
> following segments, I think accecn option might be a precedent for this.
>
>
> Accecn may not appear in an option explicitly, but it is communicated
> using SYN flags. That’s very close to what the compressed options achieves.
>
> I.e., the option value itself need not appear in the SYN, but the use of
> that option *is* signaled using the SYN/SYN-ACK, either way.
>
> Again, doing that negotiaton after the TWHS is a separate and more complex
> issue that I believe should be defined for each option (even if you want to
> define it for a separate post-SYN aggregate option); it can’t be
> generalized for existing options.
>

OK. I think I understand your viewpoints. Thanks for the explanation.
However, I still have different views on them.
I've re-read the mptcp specs, but, the design of option negotiation scheme
in the doc looks to me not mptcp-specific and simply aims to exchange
additional info reliably.
Also, I still think it's possible to combine aggregate option and delayed
negotiation scheme. It can be separated, but I don't see issues even if
it's combined.

But, anyway, at this point I don't think I have enough evidence to convince
you.
I will think about this further. Also, if possible, I would like to hear
other people's options.

Thanks,
--
Yoshi