Re: [tcpm] AccECN field order

Vidhi Goel <vidhi_goel@apple.com> Wed, 27 January 2021 03:47 UTC

Return-Path: <vidhi_goel@apple.com>
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 03DE73A11AF; Tue, 26 Jan 2021 19:47:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.37
X-Spam-Level:
X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
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 wJwMFmCsF_JS; Tue, 26 Jan 2021 19:47:18 -0800 (PST)
Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B49AB3A11A9; Tue, 26 Jan 2021 19:47:18 -0800 (PST)
Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 10R3dSNL062874; Tue, 26 Jan 2021 19:47:15 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=qjBWg3OkDWM8nAHL084LWdV7PzaLXOsa+uTKJ9HSwWs=; b=aZkmnV1ipdqLrC8jx2Lwkiwu+RDNnyvm0r6clvcrxmFYI7u4uHfLHWZF7ekq7eET8V1i tw3WH26kMwB8EXsF5MjZHxWb0pb8fgnqIzufh7kkwVMpnaD7Ipwy3fYY79yrly+pnlzz v/Ja+DW7uAtj+9UFMiWD4ouY2/HhbsM3NgEFCZfaoNHnpGh68O8NdVmLQqanjSO+mS+a d+IYw9ncTaniEh/9x0eegr2YNDkWCh4MgXJPbeQsIrEoEXMtyXETtu1PWGlTTeaMDQhC tYbwXB+PEvRoJz4PrOQlIRXxTklLT+DgaIKbRhGPsVm+ZcMm76CRleJVwJHTtsy72Owz Fw==
Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 368knyy4mq-8 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 26 Jan 2021 19:47:15 -0800
Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) with ESMTPS id <0QNK003FWQIOLRE0@rn-mailsvcp-mta-lapp03.rno.apple.com>; Tue, 26 Jan 2021 19:47:12 -0800 (PST)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) id <0QNK00R00QCQAH00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Tue, 26 Jan 2021 19:47:12 -0800 (PST)
X-Va-A:
X-Va-T-CD: fc19b38414bebaf705dacc06d1c6b73e
X-Va-E-CD: c397de0df92081fb67992e6aaa66d9e1
X-Va-R-CD: 887efa9ca7889cb2b94d9304b8ce126f
X-Va-CD: 0
X-Va-ID: 8aeb473c-bd00-45e2-9841-b8eba93a4265
X-V-A:
X-V-T-CD: fc19b38414bebaf705dacc06d1c6b73e
X-V-E-CD: c397de0df92081fb67992e6aaa66d9e1
X-V-R-CD: 887efa9ca7889cb2b94d9304b8ce126f
X-V-CD: 0
X-V-ID: 702849a9-d370-42b7-9078-4e6bfce3552b
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-27_02:2021-01-26, 2021-01-27 signatures=0
Received: from [17.234.45.201] (unknown [17.234.45.201]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) with ESMTPSA id <0QNK00DRCQINC000@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Tue, 26 Jan 2021 19:47:12 -0800 (PST)
Content-type: text/plain; charset="utf-8"
MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Vidhi Goel <vidhi_goel@apple.com>
In-reply-to: <880A9E0C-FBC9-4ADC-A11D-C5D3FDDDCE14@strayalpha.com>
Date: Tue, 26 Jan 2021 19:47:11 -0800
Cc: tcpm IETF list <tcpm@ietf.org>, Martin Duke <martin.h.duke@gmail.com>, Michael Tuexen <tuexen@fh-muenster.de>, "Scheffenegger, Richard" <Richard.Scheffenegger@netapp.com>, Mirja Kuehlewind <ietf@kuehlewind.net>, tcpm-chairs@ietf.org
Content-transfer-encoding: quoted-printable
Message-id: <FC3BA2A2-0052-418E-A4D0-F9DC9FD5C2A2@apple.com>
References: <2A6CB682-8D99-48AE-A053-1685BA480BB3@apple.com> <880A9E0C-FBC9-4ADC-A11D-C5D3FDDDCE14@strayalpha.com>
To: Joe Touch <touch@strayalpha.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-27_02:2021-01-26, 2021-01-27 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/J1p3Mmkh3z5hnMV1-EZWN6yWjVU>
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 03:47:20 -0000

> Please see my note from 12/3/20, which shows how a single codepoints would suffice without increasing length. 

If the TCP option code points is not a scarce resource, then why not just keep it simple with "two different codepoints”? Is there a reason that you think we should use only one code point?

Regarding your suggestion of using 1 bit from the 24-bit counter field, do you mean specify ordering once before the first ECN counter field or specify before every counter field?
For example, if all three counters are present, are you suggesting, a) or b)? To me b) would make more sense but that makes the implementation complex as the fields have different length.

a) Kind | Length | 1-bit ordering | 23-bit EE1B | 1-bit ordering | 23-bit ECEB | 1-bit ordering | 23-bit EE0B
b) Kind | Length | 1-bit ordering | 23-bit EE1B | 24-bit ECEB | 24-bit EE0B
-
Vidhi

> On Jan 26, 2021, at 7:27 PM, Joe Touch <touch@strayalpha.com> wrote:
> 
> 
> 
>> On Jan 26, 2021, at 6:56 PM, Vidhi Goel <vidhi_goel@apple.com> wrote:
>> 
>> 
>>> 
>>> Where is this 1 byte? 
>>> 
>>> I thought we were talking TCP options. For SYNs and SYN/ACKs, the approach above violates RFC 793, which defines new TCP options as having both kind and length - that way, an endpoint can skip over options it doesn’t know.
>>> 
>>> For other segments, it defeats the point of not wanting to issue two codepoints, which is to conserve codepoints. Instead, it would effectively be assigning 64 codepoints to the same role. 
>>> 
>>> Both are not viable ways forward.
>> 
>> Yes, you are right.
>> 
>> Now, that I have re-read the discussion around this topic more, I don’t see the problem with L = 11 or L = 12 (with flag byte) as Acc ECN option length with two different code points.
> 
> Please see my note from 12/3/20, which shows how a single codepoints would suffice without increasing length. 
> 
> Joe