Re: [tcpm] Issue with multiple option code points: Re: Early assignment of IANA TCP option number for AccECN

"Scheffenegger, Richard" <rs.ietf@gmx.at> Tue, 26 July 2022 15:44 UTC

Return-Path: <rs.ietf@gmx.at>
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 72066C13C214; Tue, 26 Jul 2022 08:44:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 pFtiAGsgDfNI; Tue, 26 Jul 2022 08:44:39 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14EF4C15A729; Tue, 26 Jul 2022 08:44:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1658850275; bh=5aT2OItjLKxg7DA8reTVrrHuR8JWaK6sF3XIrQsOhWU=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To; b=Ya2201mNxY8EyItJlJInRt/bUEjbETd9tByihYcQL28HGNTuFLRJDXYtkFUp2q1Wx ng9xZdJiZfCQ7cMa4WBa/09AostYmqc5rHDFvhWBsYtHze6ZpPJskn6u+Z2ut61sSJ XOGlWmEDhfgpxzqORt/m6sF8rxdFdYtIbG7NuN+k=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [31.133.136.141] ([31.133.136.141]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MAfYm-1o9n9W2aNM-00B5wW; Tue, 26 Jul 2022 17:44:34 +0200
Message-ID: <29de252d-5903-3772-3ace-c93253e49677@gmx.at>
Date: Tue, 26 Jul 2022 17:44:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0
To: "touch@strayalpha.com" <touch@strayalpha.com>, tcpm IETF list <tcpm@ietf.org>
Cc: Mirja Kuehlewind <mirja.kuehlewind=40ericsson.com@dmarc.ietf.org>, Michael Tuexen <michael.tuexen@lurchi.franken.de>
References: <5fd201f8-5457-3184-302d-c2f653564647@bobbriscoe.net> <9944A719-2FAF-4138-B1A3-4180454FD030@ericsson.com> <899a549f-fc82-a484-1043-28a151ae138d@bobbriscoe.net> <6032F422-60DE-4AC5-A291-E9A731032FED@ericsson.com> <87bd3248-312b-3d1b-8ba9-d4e3c1cfb1d8@gmx.at> <C4C242D1-B5DD-48A8-BB62-28C524C50F72@lurchi.franken.de> <ade43071-85b1-f29b-87d5-c112f4121cc5@gmx.at> <7eff938c-d123-5bdc-49c0-59eee2451c93@bobbriscoe.net> <ECED71F8-37CD-4D56-88FF-F6A147BAD5BB@lurchi.franken.de> <8de888ad-11c2-c927-d8af-6ff255472b03@bobbriscoe.net> <5E6DD477-791A-49B1-A239-0AACFA302D2A@lurchi.franken.de> <3a56998c-949d-f6d9-a95a-9f3d1fe08d1c@gmx.at> <42335CAC-1FC8-449C-956F-3739EB7C1845@lurchi.franken.de> <BF336802-8F6D-46C1-A6A6-4F04B2C0F78D@strayalpha.com>
From: "Scheffenegger, Richard" <rs.ietf@gmx.at>
In-Reply-To: <BF336802-8F6D-46C1-A6A6-4F04B2C0F78D@strayalpha.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:Pv75OFn+yxe2B3EDuqK+Roty2RYT9sT3D1IBAR07KThVHTcNPC6 cDiaSyLuKbnKnOlWZeNZ9qx/1n6CTh5lqqerrhL8ciTk1kuO4uy0IgoJobK+doZ1Apwf+iV XgfjEnUvDuHr2sf8wzn0E8yNvqFjgTz4avcCvxqQmQKio7kkR5F4abzTCkIemkcPxfIAjuV kLQM7q6GdzOz7nYDOge0Q==
X-UI-Out-Filterresults: notjunk:1;V03:K0:6Uiu1Yuaono=:U40PYnXSl7qCzYjenPhCww E3XCmNg1HGHJFC0eFBqCKdX5XtF3cWOOdGHjlstAU+keh4d0JknWxlKn8uKLpwG+Ugu0sjdmx HrZ+wM9tFQ00lmx8QjMPQ80Fn6mQHsUxvTiE9wBW8zdmJn7Uv2O2xuN16UFJ8w/SWu2Lmdqcc gfbmPajN9IvSLyQzQx+VDX/EkyGOCz5uEtsWhR573YJb/f8VwbSz7BU7qEktFM5kQRMmzwotM NMsVZtjeGahT75wQXbe/BMfRY9nuCmFdOOvDWg55/0BP9bOmBIAKpu9SXfdqCt//MGg1EmJzm wFeiqjZFD1epe41mA6bmJjmJom7CNSRUXK+vmGKx3MmABADOM6NuK1uuxmE/fISuHF8Qb+A8/ TtVG8ZW8341UQCbfgxprN1qoIVTXB9HNNAYMiiw4uOeZJFWh9vZjT+nIRCNwYUUtjfr+h1vN3 mkwTZGBLck3YAre4Hm8U8VGNabbKxexeuO1/2BnFS+57fpoUye5b7x07brundOK43XTdJ9Ez4 fB8iQrOvF6a9ieMCznsp91L53ZoEbHj8PeprJX872hTWHW7r4kuJNy/byzJxrEE6ykpPLclPl MmgZia5vhVa21Mi+9bl/iiaJ5JydRivbEU2RhfJ3fIh+VOcp4eD7pwsWpyvIrrfu+SR/H7NF3 ZdAUtzODhyX4ch3zsdeFvB7kXPsUyKcP0h+wey/uORcI3PJVophJoNDTzCyex93iUUQ0Zu/Mu xqaXnV2OZzn4AoD+spuOOSLTmJrEOBTP7W69gO6S76jl5aFYUaJ1jRXeL0Vpq+YIaKdoRlmjK TgqymKWqZNQz1mXixSSILblT7fwO04e8cv4DKyJtTN29vm7tA5K7eLOhzwKBWdHHhcIBdYC7m JLXq67QlkoVaVdDM3bAUp5hLvbImYcc+CviKVmT5Tb+MmdkzhnYej7qnWrZPYd1DoVlMESP+W /PkbebSjb1AaxZrF+5E1OgHYFuzuIeqD6Y6uRQiUYDi74YkgAgL6qgni7FsYXGALrX2O8EGIR xT5ZVEoR+mOlf4z1oKSk1ujywEyPvcWmYpKoCrSizJUp5u++jaaZ7mZVEl+dBSb1o4hF5UhtF /Lq/TjNWmLiT+ISvCass3dw0mb3ya5X4KxwyaCo3lQ9emKPdVV5C81MVA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/qD6JFB5AqTojihAVQLQd74D-F48>
Subject: Re: [tcpm] Issue with multiple option code points: Re: Early assignment of IANA TCP option number for AccECN
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: Tue, 26 Jul 2022 15:44:43 -0000

Hi Joe,

It was our understanding, that there was an agreement among participants
in that discussion - which later focussed more on the perceived "covert
channel" issue - to go with an easier to implement and maintain
two-option approach.

The suggested other variants
* use the length field, and discard "fill bytes" for anything but
indicate ordering - convert channel issue above)
* use of a single bit from the first (or all) counter fields - special
handling of the wrap around situations for 23-bit and 24-bit wide
counters, making sure that the bit is properly masked out, potentially
issues with offloading into simple streamlined (small) code.

While the TCP option numbers are a scarce resource, the understanding
was this approach was still less wasteful (vs. length encoding) and more
straightforward to implement (vs. flag bit).  Although, tracking optimal
ordering and stuffing of the TCP options (sending only required/changed
counters rather than all counters all the time) is not that straight
forward.

However, a sender receiving the options in the ACK can have streamlined
logic to track this - lending to the possibility of doing this in
offload hardware.

The two-codepoint approach has been in the draft since -13. It was also
discussed in the IETF 109 meeting.

Bob can also provide more of the rationale that made us move from a
single, to two codepoints between -12 and -13.



Am 26.07.2022 um 16:20 schrieb touch@strayalpha.com:
> Hi, all,
>
> Whatever happened to the discussion from 1/27/21 where we all discussed
> a way that a single TCP option code point could suffice?
>
> I do not support any assignment of multiple code points for a single TCP
> option (multiple ExIDs are fine, though).
>
> This is especially true for early code points assignments, for which
> (IMO) the bar ought be higher.
> —
> Dr. Joe Touch, temporal epistemologist
> www.strayalpha.com <http://www.strayalpha.com>
>