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

[Neal Cardwell <[e-mail]>]

Hi Yoshi,

Thanks for posting this draft. I had a couple quick questions:

(1) Would it be possible to extend the draft text to describe the proposed
deployment model for this option? It's not clear to me how/why/when this
new option would be deployed to convey support of the existing wscale,
SACK, and MSS options.  If a SYN sender does not know whether the remote
side supports this new aggregated option (the likely case for the public
Internet), then to ensure it can convey support for wscale, SACK, and MSS
the SYN sender must send both the original wscale, SACK, and MSS option,
*plus* the new aggregated option. So no space is saved on the SYN; rather,
extra space is consumed.  So is the idea that this option would only be
used in controlled environments (datacenter, enterprise, embedded) where
the sender could administratively "know" that the remote side supports this
new aggregated option? Or is the idea that we really only need to save
space on the SYN+ACK, by which point the passive side will "know" that the
active side supports the new option?

(2) Section 3.1, "Option Format",  mentions that the length byte holds a
value between 3 and 5. But it seems that there can be up to four groups. So
presumably the option as a whole can be as large as 4 bytes for group data,
plus a 1-byte kind, plus a 1-byte length, for a total of 6 bytes?

(3) I share the concern about supporting MSS values that make sense for
IPv6+Ethernet, and the concern about the installed base of MSS clamping.

Sorry if I am missing something obvious in any of these cases. :-)

best regards,
neal



On Fri, Jul 7, 2023 at 4:07 AM Yoshifumi Nishida <[e-mail]> wrote:

> Hi Michael,
>
> Yes, the pcap files I've used don't have much v6 traffic, so I only
> collected 1.4M syn packets for IPv6. But, the most dominant value for MSS
> is 1440 (more than 60%)
> So, I think your suggestion makes sense to me.
> Thank you so much!
> --
> Yoshi
>
> On Fri, Jul 7, 2023 at 12:41 AM Scharf, Michael <
> [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”?
>>
>>
>>
>> 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…
>>
>>
>>
>> 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]>
>> Date: Wed, Jul 5, 2023 at 1:24 AM
>> Subject: I-D Action: draft-nishida-tcpm-agg-syn-ext-04.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-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]
>> 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
>