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

[Yoshifumi Nishida <[e-mail]>]

Hi Rodney,

I agree handling MSS clamping is a bit tricky. That is one reason only one
value (1460) is used for MSS in the current draft.
If we don't have a good way, I guess the last resort would be if there's a
possibility for MSS clamping, an endpoint must avoid using aggregated
option for MSS. it must use the original option instead.
But, I'm still exploring several options..
--
Yoshi

On Fri, Jul 7, 2023 at 9:19 PM Rodney W. Grimes <[e-mail]>
wrote:

> > Hi Yoshi,
> >
> > Regarding the MSS: Isn?t the MSS for IPv6 only 1440 byte?
> >
> > Just as a thought: Instead of encoding an MSS value, 1 bit could be used
> to convey ?if set to 1, use the maximum MSS for the Ethernet MTU of 1500
> byte??
>
> "for the DEFAULT Ethernet MTU of 1500", this ignores jumbo frames, ignore
> that you might be doing pppOE, or any number of things that lead to a non
> MSS of 1460.  Please be very carefull about trying to encode any value of
> MTU.
>
> >
> > Disclaimer: I haven?t thought about the implications on IPv4/IPv6
> translation techniques. But, anyway, the bigger problem may be the
> installed base of MSS clamping?
>
> And the installed based of pppOE, VLAN tagging or anthing else that fools
> around with the MTU/MSS of a link.
> I can not recall how many times I have had to debug connectivity issues
> that had been caused by assumption of MTU=1500/MSS=1460.
>
>

> >
> > Michael
> >
> > From: tcpm <[e-mail]> On Behalf Of Yoshifumi Nishida
> > Sent: Friday, July 7, 2023 8:40 AM
> > To: [e-mail] Extensions <[e-mail]>
> > Subject: [tcpm] Catalog approach for syn option aggregation draft
> >
> > 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/
> >
> > There is also an HTML version available at:
> > 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
> >
> > 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
> > 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
>
> --
> Rod Grimes
> [e-mail]
>