Re: [tcpm] Catalog approach for syn option aggregation draft

[Yoshifumi Nishida <[e-mail]>]

Hi Richard,

I am thinking that we need 1 bit for MSS even though it can carry a single
value. Because if the bit for MSS is 0 can be used to indicate 'this option
carries aggregated values for wscale and sack, but not MSS"
I agree that MSS clamping is a widespread technology, but I think a
question would be if we can find a relatively small set of prominent
values.

Another possibility I thought was exchanging MSS value with TCP options by
using 3rd segments and 4th segments such as the late negotiation scheme
described in the old version of this draft.
This approach isn't very effective when an endpoint wants to send data in
addition to the 3rd segment, however it might not be a big issue as long as
the endpoint follows RFC2414 or RFC6928.
--
Yoshi


On Fri, Jul 7, 2023 at 10:14 AM <[e-mail]> wrote:

> Hi Yoshi,
>
>
> Not sure about MSS really; If you encode only a single value, the mere
> presence of the aggregate option itself could convey this;
>
> However, there are many (semi private) environments, where both much
> larger (MTU900 / MSS 8960) and smaller (L2 overlay topologies at many cloud
> hyperscalers internally fragement at around MSS 1360), as well as a
> plethora of VPN technologies providing a range of MSS in between 1200 and
> 1460...
>
> MSS clamping is also a very widespread technology - so not sure if MSS
> should be made part of this aggreagte option without it also being present
> as separate option.
>
> While I still believe a catalog approach would work for MSS, a more
> diverse sample set, also covering semi-private and private environments
> would certainly need to be looked at, including VPNs, hyperscalers and
> commercial jumbo frame scenarios, as well as both IPv4 and IPv6.
>
> However, if you couple with this the requirment of having support for
> PMTUD/BD, the presence of this option by itself could be treated as
> "infinite" MSS, so using the sender interface MTU as initial MSS, until
> PMTUD finds a more suitable smaller value... (Similar to RFC6691 section
> 5.3)
>
> Richard
>
>
>
> Am 07.07.2023 um 08:40 schrieb Yoshifumi Nishida:
> > Hi folks,
> >
> > During my presentation for syn aggregation draft in the last WG meeting,
> some folks suggested using a catalog approach to compress existing options
> such as MSS, wscale, etc.
> > I am still thinking, but I've put some initial ideas about this approach
> in the updated version of the draft.
> >
> > In a nutshell, the idea is to use entire bits for 'Group 1'. As one
> group can carry 6 bits, we use 4 bits for window scale option, 1 bit for
> SACK-permit and another 1 bit for MSS.
> > As window scale value ranges from 0 to 14, we can accomodate all values
> in 4 bits.
> > SACK-permit carries 1 bit information, so using 1 bit is enough.
> > MSS is a bit tricky as it can carry various values. But, as far as I've
> checked 24M syn packets in CAIDA and WIDE's packet captures, over 40% MSS
> options in SYN packets carries 1460.
> > Hence, the draft uses 1 bit to indicate MSS=1460.
> >
> > Since I'm still wondering if this format is fine or there might be more
> efficient ways, your feedback is highly appreciated.
> > If you're interested, please check the updated draft.
> > Thank you so much!
> > --
> > Yoshi
> >
> >
> >
> > ---------- Forwarded message ---------
> > From: <[e-mail] <mailto:[e-mail]>>
> > Date: Wed, Jul 5, 2023 at 1:24 AM
> > Subject: I-D Action: draft-nishida-tcpm-agg-syn-ext-04.txt
> > To: <[e-mail] <mailto:[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-04.txt
> >     Pages           : 11
> >     Date            : 2023-07-05
> >
> > Abstract:
> >     TCP option space is scarce resource as its maximum 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 can aggregate multiple TCP options in SYN
> >     segments into a single option so that more options can be negotiate
> >     during 3-way handshake.  With its simple design, the approach does
> >     not require fundamental changes in TCP.
> >
> > The IETF datatracker status page for this Internet-Draft is:
> > https://datatracker.ietf.org/doc/draft-nishida-tcpm-agg-syn-ext/ <
> https://datatracker.ietf.org/doc/draft-nishida-tcpm-agg-syn-ext/>
> >
> > There is also an HTML version available at:
> > https://www.ietf.org/archive/id/draft-nishida-tcpm-agg-syn-ext-04.html <
> https://www.ietf.org/archive/id/draft-nishida-tcpm-agg-syn-ext-04.html>
> >
> > A diff from the previous version is available at:
> >
> https://author-tools.ietf.org/iddiff?url2=draft-nishida-tcpm-agg-syn-ext-04
> <
> https://author-tools.ietf.org/iddiff?url2=draft-nishida-tcpm-agg-syn-ext-04
> >
> >
> > Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
> >
> >
> > _______________________________________________
> > I-D-Announce mailing list
> > [e-mail] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/i-d-announce <
> https://www.ietf.org/mailman/listinfo/i-d-announce>
> > Internet-Draft directories: http://www.ietf.org/shadow.html <
> http://www.ietf.org/shadow.html>
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt <
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
> >
> > _______________________________________________
> > tcpm mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tcpm
>