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

"Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net> Sat, 08 July 2023 04:20 UTC

Return-Path: <ietf@gndrsh.dnsmgr.net>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2956C1519B8 for <tcpm@ietfa.amsl.com>; Fri, 7 Jul 2023 21:20:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.895
X-Spam-Level:
X-Spam-Status: No, score=-6.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noQi3Lv7IvPw for <tcpm@ietfa.amsl.com>; Fri, 7 Jul 2023 21:19:58 -0700 (PDT)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CAA1C1519B5 for <tcpm@ietf.org>; Fri, 7 Jul 2023 21:19:57 -0700 (PDT)
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 3684Jpxx021290; Fri, 7 Jul 2023 21:19:51 -0700 (PDT) (envelope-from ietf@gndrsh.dnsmgr.net)
Received: (from ietf@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 3684JoQV021289; Fri, 7 Jul 2023 21:19:50 -0700 (PDT) (envelope-from ietf)
From: "Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net>
Message-Id: <202307080419.3684JoQV021289@gndrsh.dnsmgr.net>
In-Reply-To: <18b4eb50c5024e0a99bacecea8e0c0f3@hs-esslingen.de>
To: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
Date: Fri, 07 Jul 2023 21:19:50 -0700
CC: Yoshifumi Nishida <nsd.ietf@gmail.com>, "tcpm@ietf.org Extensions" <tcpm@ietf.org>
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/YNYy-E17IeVEg89McE_oxcqjgR8>
Subject: Re: [tcpm] Catalog approach for syn option aggregation draft
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Jul 2023 04:20:02 -0000

> 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 <tcpm-bounces@ietf.org> On Behalf Of Yoshifumi Nishida
> Sent: Friday, July 7, 2023 8:40 AM
> To: tcpm@ietf.org Extensions <tcpm@ietf.org>
> 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: <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>>
> Date: Wed, Jul 5, 2023 at 1:24?AM
> Subject: I-D Action: draft-nishida-tcpm-agg-syn-ext-04.txt
> To: <i-d-announce@ietf.org<mailto:i-d-announce@ietf.org>>
> 
> 
> 
> 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
> I-D-Announce@ietf.org<mailto:I-D-Announce@ietf.org>
> 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
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

-- 
Rod Grimes                                                 rgrimes@freebsd.org