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

[Yoshifumi Nishida <[e-mail]>]

Hi Joe,

On Thu, Oct 14, 2021 at 9:14 AM [e-mail] <[e-mail]>
wrote:

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

Yes, I understand your points and I have a different view. I might want to
see some feedback from other folks on this.

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

OK. my proposal recommends incremental deployments as described in Section
5.1 for regacy receivers.

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

Right. if it makes things easier, I can split this proposal into two.
in any case, if we keep inventing new options, I think something like
AGG-SYN option will be needed some day
--
Yoshi