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

[Yoshifumi Nishida <[e-mail]>]

Hi Med,
FWIW, I wrote
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]> 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]> De la part de Wesley Eddy
> > Envoyé : mardi 12 octobre 2021 22:07
> > À : [e-mail]; tcpm <[e-mail]>
> > Objet : Re: [tcpm] TCP EDO and SYN-EXT-OPT finalization - request for
> > discussion
> >
> > On 10/12/2021 3:50 PM, [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]
> > 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]
> https://www.ietf.org/mailman/listinfo/tcpm
>