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

[Yoshifumi Nishida <[e-mail]>]

Hi Neal,
Thanks for the comments.

On Fri, Jul 7, 2023 at 5:32 AM Neal Cardwell <[e-mail]> wrote:

> 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?
>

The focus of the draft is not only controlled environments but also public
internet.
One possible way to include aggregated options with existing options as
you've mentioned although this is a bit redundant.
But, endpoints can cache this info. So, redundant sending won't always
happen.
In addition, I think we can do redundant sending in SYN/ACK and then the
client caches the info if it supports the aggregated formats. In this way,
at least we don't have to do redundant sending in SYN.
I will try to describe something like this in the next version as one
possibility.


> (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?
>

sorry. I forgot to update this part from the previous version. Yes, in the
current format, the length will be 3-6.
Thanks for pointing it out.

(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.
>

I am thinking about several points for MSS clamping.
1: if we use a catalog approach for clamped MSS, which values can be
efficient
2: If an endpoint uses aggregated option for MSS and clamping happens in
the middle boxes which don't understand aggregated options, the MSS info
might be messed up.
If there're some thoughts on them or other points to be considered, please
let me know.

Thanks,
--
Yoshi

>
>
> 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
>>
>