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

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

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…

Joe

—
Joe Touch, temporal epistemologist
www.strayalpha.com

> On Oct 13, 2021, at 3:15 AM, Yoshifumi Nishida <[e-mail]> wrote:
> 
> Hi Med,
> FWIW, I wrote https://datatracker.ietf.org/doc/html/draft-nishida-tcpm-agg-syn-ext-00.txt <https://datatracker.ietf.org/doc/html/draft-nishida-tcpm-agg-syn-ext-00.txt> which can extend SYN option space without using OOB packets.
> As SYN option space extension is an important and fundamental feature, I personally prefer to discuss the doc at the WG.
> --
> Yoshi
> 
> On Wed, Oct 13, 2021 at 2:07 AM <[e-mail] <mailto:[e-mail]>> wrote:
> Hi all, 
> 
> I agree with Wes. 
> 
> Solving the SYN case is more problematic (e.g., consider an application relying upon MP_CAPABLE + FAST_OPEN). We managed to solve this specific issue in RFC8803 without requiring SYN-EOS/OOB, but that approach cannot be generalized. Having a tcpm WG document to cover the SYN case + discuss the issues of an OOB mechanism is useful.    
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : tcpm <[e-mail] <mailto:[e-mail]>> De la part de Wesley Eddy
> > Envoyé : mardi 12 octobre 2021 22:07
> > À : [e-mail] <mailto:[e-mail]>; tcpm <[e-mail] <mailto:[e-mail]>>
> > Objet : Re: [tcpm] TCP EDO and SYN-EXT-OPT finalization - request for
> > discussion
> > 
> > On 10/12/2021 3:50 PM, [e-mail] <mailto:[e-mail]> wrote:
> > >
> > > - are there any open issues or pending suggestions to TCP EDO to
> > > prepare it for last call?
> > >
> > I think it's in good shape for a last call.  It's stable and addresses all
> > of the feedback to date, aside from greater implementation and field
> > experience.  At the moment, it seems like QUIC has solved the burning need
> > we had for TCP options space, by attracting all the work that would
> > normally need more options. However, after many years of discussion about
> > how to handle this for TCP, and many candidates, the EDO approach was the
> > one the working group was able to get consensus around, and we really
> > should wrap up and publish it, IMHO.
> > 
> > 
> > > - would the WG like to adopt SYN-EXT-OPT as experimental as well or
> > > would it be preferred (and OK) to submit this as
> > > individual/experimental if not?
> > >
> > Either approach is fine with me, and I prefer either of them rather than
> > not advancing anything.  I would be willing to contribute reviews for
> > either path.
> > 
> > 
> > _______________________________________________
> > tcpm mailing list
> > [e-mail] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> 
> _______________________________________________
> tcpm mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm