Re: [tcpm] I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt

[Yoshifumi Nishida <[e-mail]>]

Hi Joe,

Thanks for reading the draft. I put my comments in lines.

On Wed, Feb 3, 2021 at 4:46 PM Joseph Touch <[e-mail]> wrote:

> Hi, Yoshi,
>
> On Feb 2, 2021, at 11:12 PM, Yoshifumi Nishida <[e-mail]> wrote:
>
> Hi folks,
>
> I prepared a draft for SYN option space extensions.
> I know this is a difficult issue in TCP and has been discussed for a long
> time.
> But, I'm thinking that it might be a good time to discuss it again.
>
>
> The proposal has two parts, which are (AFAICT) separable:
> A. Aggregated options
> B. Adding more option space in the 3rd packet of a 3WHS
>

Right. both can be used supplementarily.


> (A) is fine, although the most significant issue is legacy interaction.
>
> (B) is no longer extending the SYN; it’s actually just post-SYN activation
> of new options.
>

In my view, all options are negotiated during SYN exchange. There's no post
SYN activation.
They are just additional information for the features already negotiated
during SYN exchanges.


> Key ideas of the draft are the followings.
> 1: drastic changes in TCP's spec will not be required
>     (it does not require updating TCP header format nor using multiple SYN
> packets or additional SYN-like packets)
>
>
> Post-SYN activation of new options is quite a drastic change.
>
> Nevermind the question of what happens to data in the SYN, which normally
> MUST be passed to the application at the receiver after the final ACK is
> received, but here MUST NOT. And the data that might go in the other
> direction in the 3rd message with the ACK.
>
> Basically, you’re proposing to change the 3WHS to a 5WHS, which is a lot
> more significant and complex than described here (there are a lot of
> failure modes not addressed, for one).
>

RIght. To be precise, the draft supports 3WHS, 4WHS and 5WHS. It can be
varied depending on how much extra option space is needed.
MPTCP adopts 4WHS for its negotiation. In my view, the draft just extends
the idea.
Hence, I am thinking the degree of the complexity would be more or less the
same. At least, I don't think it will be too complex to implement.

2: utilize the option negotiation schemes in mptcp for generic purposes.
> so, I think it can be considered middlebox friendly.
>
>
> MPTCP is negotiating variants of an option that is already active
> (AFAICT); that’s not the same as activating new options.
>

My understanding for MPTCP is similar and I think this draft does the same
things. (from my point of view)
 If you see significant differences between them, could you elaborate a bit?

> 3: it has some limitations (e.g it can only extend around 30-40 bytes for
> SYN option space). But, if it's combined with EDO, we can use more option
> space.
>     (depends on how EDO draft will progress, though)
>
>
> If you have EDO, then just negotiate it and activate options after the
> connection is established. But that’s not the problem at hand - the problem
> is activation of options in the SYN. AFAICT, this does not do that.
>

I think the negotiation scheme for EDO is simple. it needs to send 1 bit
information to indicate the activation of the feature.
This can be done during SYN exchange. So, I thought it's fine to use this
feature in the 3rd segment. Or, are there any risks?

Thanks for the lots of detailed comments.
--
Yoshi



>
> Please let me know if you have any questions or comments or suggestions.
>
> Thank you so much!
> --
> Yoshi
>
>
> ---------- Forwarded message ---------
> From: <[e-mail]>
> Date: Tue, Feb 2, 2021 at 10:45 PM
> Subject: I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt
> To: <[e-mail]>
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>         Title           : Aggregated Option for SYN Option Space Extension
>         Author          : Yoshifumi Nishida
>         Filename        : draft-nishida-tcpm-agg-syn-ext-00.txt
>         Pages           : 14
>         Date            : 2021-02-02
>
> Abstract:
>    TCP option space is scarce resource as its max length is limited to
>    40 bytes.  This limitation becomes more significant in SYN segments
>    as all options used in a connection should be exchanged during SYN
>    negotiations.  This document proposes a new SYN option negotiation
>    scheme that provide a feature to compress TCP options in SYN segments
>    and provide more option space.  The proposed scheme does not update
>    the format of TCP header nor transmit any additional SYN or SYN-like
>    segments so that it has lower risks for middlebox interventions.  In
>    addition, by combining another proposal for option space extension,
>    it is possible to provide further option space.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-nishida-tcpm-agg-syn-ext/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-nishida-tcpm-agg-syn-ext-00
> https://datatracker.ietf.org/doc/html/draft-nishida-tcpm-agg-syn-ext-00
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>
>
>