Re: [tcpm] TCP EDO and SYN-EXT-OPT finalization - request for discussion

[Yoshifumi Nishida <[e-mail]>]

Hi Joe,

On Wed, Oct 13, 2021 at 9:01 AM [e-mail] <[e-mail]>
wrote:

> Hi, Yoshi,
>
> Although I noticed that post, there are two issues that make it not really
> comparable to SYN-EXT:
>
> - SYN-EXT extends the space available to all options, whereas AGG-SYN
> compresses existing options
> a single option of larger than 40 bytes can be supported in the former but
> not the latter
>
> - SYN-EXT is compatible with connections to legacy receivers; AGG-SYN does
> not appear to be
> a SYN-EXT endpoint can put the options it expects/needs in the SYN with a
> 2-byte SYN-EXT option overhead
> by compressing existing options, AGG-SYN effectively redesigns TCP such
> that legacy receivers would require an additional round-trip to recover
>
> One you have anything like the AGG-SYN option in a SYN, you’ve effectively
> redesigned TCP and can do anything you want, as the doc suggests - add
> additional RTTs for coordinate, etc. But that comes at the expense of
> legacy receivers and middle boxes, which can no longer rely on tracking the
> existing 3-way handshake.
>
> Once you’ve taken that step, you might as well just use a new transport
> code point and design a new protocol…
>

While I understand your points, I would like to mention that the method
proposed in the draft is basically the same as what mptcp already does.
If this looks like designing a new protocol, I think mptcp can also be
viewed as a new protocol. (you may say so, though..)
So, I'm not very sure delaying option negotiation looks like a more drastic
change than using OOB packets.

Also, I am not sure which one is more legacy receiver friendly as both
approach send a new option kind in the first SYN and the feature is
disabled if the option is ignored.
--
Yoshi