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

[[e-mail]]

Re-,

Thanks for the pointer.

I like the aggregation option spirit. It is advanced compared to a design proposal we had in
https://datatracker.ietf.org/doc/html/draft-boucadair-tcpm-capability-option-01. Please note that in draft-boucadair-tcpm-capability-option, we had a specific applicability scope for which we don’t have the negotiation issue that may be applicable to draft-nishida-tcpm-agg-syn-ext. No?

Cheers,
Med

De : Yoshifumi Nishida <[e-mail]>
Envoyé : mercredi 13 octobre 2021 12:16
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : Wesley Eddy <[e-mail]>; [e-mail]; tcpm <[e-mail]>
Objet : Re: [tcpm] TCP EDO and SYN-EXT-OPT finalization - request for discussion

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

_________________________________________________________________________________________________________________________

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

_________________________________________________________________________________________________________________________

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.