Re: [tcpm] AccECN field order

Lars Eggert <lars@eggert.org> Wed, 27 January 2021 07:45 UTC

Return-Path: <lars@eggert.org>
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 96EB53A1496; Tue, 26 Jan 2021 23:45:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHwMGLFSSsL1; Tue, 26 Jan 2021 23:44:58 -0800 (PST)
Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4FAC3A14A1; Tue, 26 Jan 2021 23:44:58 -0800 (PST)
Received: from [IPv6:2a00:ac00:4000:400:346c:dde7:2098:873d] (unknown [IPv6:2a00:ac00:4000:400:346c:dde7:2098:873d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 03952600073; Wed, 27 Jan 2021 09:44:45 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1611733486; bh=ZJs0c09vCvYgWh77Y1Uh9xqwM/K2ltwDc1ToXZlXqHE=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=weJDtmyJSWDMUmOX3l2RaUFOviIorU1+pF/L0+8HMhIh+q0UJYKV2/UG0sRE8GzwW wJh9YPuaCCaMYPyxoYx9j2kjENb3Y42gC99h66TEXpeACEwZglDDo2CAc1VwUtxBUr 76s2v2KCW0EJ7f9SAu6nRFs9z0fmi9T5LHAqsNZ8=
From: Lars Eggert <lars@eggert.org>
Message-Id: <4AABAED3-4F64-47C6-9243-6864652765D0@eggert.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_90CF6FE8-C83C-45EC-8926-19E7322A11FA"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\))
Date: Wed, 27 Jan 2021 09:44:45 +0200
In-Reply-To: <8B6B13CD-94B5-4C0B-8771-F008C390A661@strayalpha.com>
Cc: Vidhi Goel <vidhi_goel=40apple.com@dmarc.ietf.org>, Michael Tuexen <tuexen@fh-muenster.de>, "Scheffenegger, Richard" <Richard.Scheffenegger@netapp.com>, tcpm IETF list <tcpm@ietf.org>, Mirja Kühlewind <ietf@kuehlewind.net>, tcpm-chairs@ietf.org
To: Joe Touch <touch@strayalpha.com>
References: <2A6CB682-8D99-48AE-A053-1685BA480BB3@apple.com> <880A9E0C-FBC9-4ADC-A11D-C5D3FDDDCE14@strayalpha.com> <FC3BA2A2-0052-418E-A4D0-F9DC9FD5C2A2@apple.com> <8B6B13CD-94B5-4C0B-8771-F008C390A661@strayalpha.com>
X-Mailer: Apple Mail (2.3654.40.0.2.32)
X-MailScanner-ID: 03952600073.A09F8
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/CVJjwCrEv2VbS3t9948cu-SzgZU>
Subject: Re: [tcpm] AccECN field order
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 27 Jan 2021 07:45:01 -0000

On 2021-1-27, at 6:21, Joseph Touch <touch@strayalpha.com> wrote:
> On Jan 26, 2021, at 7:47 PM, Vidhi Goel <vidhi_goel=40apple.com@dmarc.ietf.org> wrote:
>> 
>> If the TCP option code points is not a scarce resource,
> 
> They are. Very much so.

https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-parameters-1 shows ~200 out of 256 that are still reserved, i.e., available. So we aren't in any danger of running out in our lifetimes, esp. given the limitations in the SYNs.

That said, there might be other arguments for why a single option number is better/cleaner/nicer, but I don't buy the scarcity one.

Lars