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

From: "[email-masked]" <[email-masked]>
Date: Tue, 12 Oct 2021 12:50:12 -0700

Hi, all,

I’d like to see what we can do to get TCP EDO out the door as well as SYN-EXT-OPT:
https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-tcp-edo <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-tcp-edo>
https://datatracker.ietf.org/doc/html/draft-touch-tcpm-tcp-syn-ext-opt <https://datatracker.ietf.org/doc/html/draft-touch-tcpm-tcp-syn-ext-opt>

The latter would be experimental and both are not recommended for widespread deployment or default use. They both do, IMO, document the key issues in extending the TCP option space for both post-SYN and SYN segments, so they should still be useful to complete.

I would like to ask the WG:

- are there any open issues or pending suggestions to TCP EDO to prepare it for last call?

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

Comments on either doc or the above questions welcome.

Thanks, all,
Joe

—
Joe Touch, temporal epistemologist
www.strayalpha.com

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 12 Oct 2021 16:07:19 -0400

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

---

From: <[email-masked]>
Date: Wed, 13 Oct 2021 09:07:25 +0000

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 <[email-masked]> De la part de Wesley Eddy
> Envoyé : mardi 12 octobre 2021 22:07
> À : [email-masked]; tcpm <[email-masked]>
> Objet : Re: [tcpm] TCP EDO and SYN-EXT-OPT finalization - request for
> discussion
> 
> 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.
> 
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> 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.

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 13 Oct 2021 03:15:36 -0700

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 <[email-masked]> 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
>
> all
> need
> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: <[email-masked]>
Date: Wed, 13 Oct 2021 10:59:21 +0000

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 <[email-masked]>
Envoyé : mercredi 13 octobre 2021 12:16
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
Cc : Wesley Eddy <[email-masked]>; [email-masked]; tcpm <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

I agree with Wes.

Cheers,
Med

> De : tcpm <[email-masked]<mailto:[email-masked]>> De la part de Wesley Eddy
> À : [email-masked]<mailto:[email-masked]>; tcpm <[email-masked]<mailto:[email-masked]>>
> On 10/12/2021 3:50 PM, [email-masked]<mailto:[email-masked]> wrote:
> >
> [email-masked]<mailto:[email-masked]>

_______________________________________________
tcpm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tcpm

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 13 Oct 2021 09:01:05 -0700

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

—

> On Oct 13, 2021, at 3:15 AM, Yoshifumi Nishida <[email-masked]> 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.
> On Wed, Oct 13, 2021 at 2:07 AM <[email-masked] <mailto:[email-masked]>> wrote:
> Hi all, 
> 
> I agree with Wes. 
> 
> > De : tcpm <[email-masked] <mailto:[email-masked]>> De la part de Wesley Eddy
> > À : [email-masked] <mailto:[email-masked]>; tcpm <[email-masked] <mailto:[email-masked]>>
> > On 10/12/2021 3:50 PM, [email-masked] <mailto:[email-masked]> wrote:
> > >
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 13 Oct 2021 18:50:48 -0700

Hi Med,
Thanks for the link. Yes, I think there are some common things in both
drafts.
I will definitely note or discuss it in the next version. Please allow some
time to think about this a bit more.
--
Yoshi

On Wed, Oct 13, 2021 at 3:59 AM <[email-masked]> wrote:

> 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 <[email-masked]>
> *Envoyé :* mercredi 13 octobre 2021 12:16
> *À :* BOUCADAIR Mohamed INNOV/NET <[email-masked]>
> *Cc :* Wesley Eddy <[email-masked]>; [email-masked]; tcpm <
> [email-masked]>
> *Objet :* Re: [tcpm] TCP EDO and SYN-EXT-OPT finalization - request for
> discussion
>
>
>
> Hi Med,
>
> FWIW, I wrote

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 13 Oct 2021 18:51:12 -0700

Hi Joe,

On Wed, Oct 13, 2021 at 9:01 AM [email-masked] <[email-masked]>
wrote:

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

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.
If this looks like designing a new protocol, I think mptcp can also be
viewed as a new protocol. (you may say so, though..)
So, I'm not very sure delaying option negotiation looks like a more drastic
change than using OOB packets.

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

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 14 Oct 2021 09:14:36 -0700

Hi, Yoshi,

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

---

From: Yoshifumi Nishida <[email-masked]>
Date: Fri, 15 Oct 2021 15:48:18 -0700

Hi Joe,

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

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

> 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