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

["[e-mail]" <[e-mail]>]

Hi, Yoshi,

> On Oct 13, 2021, at 6:51 PM, Yoshifumi Nishida <[e-mail]> wrote:
> 
> Hi Joe,
> 
> On Wed, Oct 13, 2021 at 9:01 AM [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[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.

That works for MPTCP because *it* has decided that some aspects of its protocol are negotiated after the 3WHS. Each option can decide that for itself, but we cannot decide that for the initial exchange of all options (which is what needs to be done to extend the SYN option space).

> If this looks like designing a new protocol, I think mptcp can also be viewed as a new protocol. (you may say so, though..)

It is - after the 3WHS decides “MPTCP enabled”, MPTCP runs its own, possibly lossy and out-of-order processing of its options to coordinate its state. That’s all “inside” MPTCP, though.

> So, I'm not very sure delaying option negotiation looks like a more drastic change than using OOB packets.

It is - MPTCP has decided it is OK to delay negotiation for some of its parameters, but we cannot unilaterally do that for existing options.

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

“Legacy” needs to accommodate both legacy receivers and legacy options.

For legacy receivers, the best we can do is avoid an extra RTT to do the SYN-ACK to confirm the options in the existing SYN space, i.e., there’s no way to extend its option space.

For upgraded receivers, we want to avoid extra RTTs to extend the actual (not available) space in the SYN; SYN-EXT-OPT is the only method currently shown (AFAICT) that has that capability.

(Note: again, I encourage you to separate the multiple RTT delayed option negotiation from the option compression part; they don’t need to be related)

Joe