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

[[e-mail]]

Hi Yoshi,

Am 29.03.2023 um 12:50 schrieb Yoshifumi Nishida:
> Hi Richard,
>
> Thanks for the comments.
>
> On Mon, Mar 27, 2023 at 1:34 AM <[e-mail] <mailto:[e-mail]>>
> wrote:
>
>     Hi Yoshi,
>
>     I just wanted to record my comment on list too:
>
>     For the aggregated option I would like to also see some of the commonly
>     used parameters (e.g. MSS, Window Scale) to be rolled into this.
>     Ideally, in some not-too-distant future, all Hosts should be supporting
>     this aggregated option, and retaining the additional space for those
>     parameters and their tcp option encoding appears to be excessive.
>
>     Especially as not the full range is used (window scale may receive a
>     final boost to use 0..15 instead of 0..14 currently, thus a 4-bit field
>     suffices; timestamp in the SYN could be abbreviated (no ECR field
>     needed, as the proposal for granularity signalling never got much
>     traction); MSS could be compressed to few commonly encountered values
>     (e.g. 1200, 1300, 1460, 8960, 65535 (lo0), or some variant of an
>     exponential encoding).
>
>
> I see. I haven't thought about it, but it may make sense. One idea might
> be to allocate GID for MSS or GID for window scale
> If we need more GIDs, we can extend it to 3 bits.

I believe it was Andrew who also suggested having something like a
catalog of common settings - e.g. MSS 1460 or 8960, as well as WScale 8,
referenced by one codepoint. If that codepoint lives in a dedicated GID,
or is simply a subset of bits from a GID, would need more exploration
(as would be the set of commonly used SYN options).

Furthermore, I would suggest if this catalog of parameters approach is
choosen, only a very limited number should be defined - and the "full"
TCP option taking precedence over the catalog entry.

Best regards,
    Richard

>
>     Martin's suggestion of adding in this early stage various competing
>     proposals into the same draft, and working out the pro/cons over time
>     also sounds appealing.
>
>     Finally, there are (currently) more exotic options, which are heavy
>     consumers of SYN tcp option space (MPTCP, TFO, MD5 / AO - with those two
>     really having a limited applicability domain currently). A quick rundown
>     of them all, and their requirements on the SYN and SYN,ACK space may be
>     valuable to have in the draft for discussion purposes (avoid having to
>     chase them when reading the draft).
>
>
> Yes, I've thought about similar things. The tricky things are:
> * MPTCP already pushes out some parameters to 3rd and 4th segments
> * TFO and AO should carry large data in SYN otherwise their features
> will be impaired.
> I think I can add some discussions for them in the next version.
>
> BTW, I wasn't aware that user timeout doesn't use SYN, but i think it's
> because it doesn't require negotiation and it's a hint for the peer.
> In my understanding , we cannot reliably negotiate features without
> using SYN. If needed, I can add some texts for discussions.
>
> --
> Yoshi