Re: [tcpm] AccECN field order

Vidhi Goel <vidhi_goel@apple.com> Wed, 27 January 2021 02:56 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 0A3453A1114; Tue, 26 Jan 2021 18:56:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.35
X-Spam-Level:
X-Spam-Status: No, score=-2.35 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 Dg1_-N5AXTUu; Tue, 26 Jan 2021 18:56:32 -0800 (PST)
Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (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 D72ED3A1113; Tue, 26 Jan 2021 18:56:31 -0800 (PST)
Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.42/8.16.0.42) with SMTP id 10R2sBcL060163; Tue, 26 Jan 2021 18:56:28 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=YgQIu/E3EcE3w/ynQBHajHjc42WJAiKEs6ViLfrOb2Y=; b=BDhZHsgPcYFpGG+evvCVAi6sr69a2qZltYUpVVbNo/okNFSTrIQZevbm0hbECLrZlaU8 Dkcw7NX7FTgGOkLoqJNVncZNxMrX2yJps35qsuSMuor01070DkzlvVvTKsO2XjLJKTsM J2XPmCKfyivfqOsf262VTMUGppFa1vtzNEpTR59FBaj071p0kXG98QoVS9n3kwGHDBEw 3ourBmnYNZCr/rVcKGTQ6QpECy9beqR1mvo7VW4d/vRTkclNoujM5UMDCpjDmkzTnrQr qwQ72vPdWBmaH+ZmQJ5Lt5ojvGp5Pfz/gKBMdNcHDT31FtXuceFViKgmjt+cIo5mev54 +g==
Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 368hbwsj5r-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 26 Jan 2021 18:56:28 -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 <0QNK00BU1O63XN60@rn-mailsvcp-mta-lapp03.rno.apple.com>; Tue, 26 Jan 2021 18:56:27 -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 <0QNK00Z00O3CF900@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Tue, 26 Jan 2021 18:56:27 -0800 (PST)
X-Va-A:
X-Va-T-CD: c279b06c8353ce446b254c634a752559
X-Va-E-CD: c397de0df92081fb67992e6aaa66d9e1
X-Va-R-CD: 887efa9ca7889cb2b94d9304b8ce126f
X-Va-CD: 0
X-Va-ID: 3ce20935-c1ae-49ae-9dc5-2418e41db965
X-V-A:
X-V-T-CD: c279b06c8353ce446b254c634a752559
X-V-E-CD: c397de0df92081fb67992e6aaa66d9e1
X-V-R-CD: 887efa9ca7889cb2b94d9304b8ce126f
X-V-CD: 0
X-V-ID: 2da22301-67f2-4c94-9f9d-0928f42725bd
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-26_11:2021-01-26, 2021-01-26 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 <0QNK00505O625R00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Tue, 26 Jan 2021 18:56:27 -0800 (PST)
From: Vidhi Goel <vidhi_goel@apple.com>
Message-id: <2A6CB682-8D99-48AE-A053-1685BA480BB3@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_FA6ADFFF-E4E6-408E-B843-2AFB9169548A"
MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Tue, 26 Jan 2021 18:56:26 -0800
In-reply-to: <4E860829-07EA-43DF-A12F-11A6A98EB96A@strayalpha.com>
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" <tcpm-chairs@ietf.org>
To: Joseph Touch <touch@strayalpha.com>
References: <42eee5b7-fc0d-9576-c2ab-128706611a96@bobbriscoe.net> <bca1931d-b99e-447d-2ccc-8f13969df7f4@bobbriscoe.net> <CAAK044S8rVVRHjkHBxCfGDD6tOTRJvnsVOt3eGf0z95N0o=mDQ@mail.gmail.com> <CAAK044QRYKmk9GbPn1N-TxAr5E7TDr87mV3UJJuY2FNNKyd_Jw@mail.gmail.com> <279fb3d5-0000-f704-d88f-08ab0fa9e83a@bobbriscoe.net> <CAAK044TtbFWjb-msj3rA6vE+ZB99O1qAwhUFwzD2+rehzX9a7Q@mail.gmail.com> <9bdf71e9-4af0-f5ee-f2f7-e63349956500@bobbriscoe.net> <b3ae297684b04461be4e5ef5bbe3c83a@hs-esslingen.de> <f881b3e1-20e7-8533-1003-d22a69929f62@bobbriscoe.net> <30781ea61a794131beafe9997ed9221a@hs-esslingen.de> <1c927b36-7228-91f3-4d58-6f3545c88a57@bobbriscoe.net> <5c3c4661887c43529b35bd5f47d10c2b@hs-esslingen.de> <CADVnQynjc=fhTR_T29xP4r=945GtRJ8oBkRHCvpHraxb_a1ZCA@mail.gmail.com> <B7ED67D5-B5BE-4D42-8A48-06B9DD987749@kuehlewind.net> <SN4PR0601MB37286EB6FAA56C9E5293638086FC0@SN4PR0601MB3728.namprd06.prod.outlook.com> <CAM4esxSysznm=ZNQLVhgV-f2AYpqY2mMeC5e5-TZRWw_VDQ2wg@mail.gmail.com> <AF048EE8-F0E8-4EC0-B164-829FDE797E69@strayalpha.com> <82D2BE19-7033-4D0E-87BA-0B4E3481AC84@apple.com> <4E860829-07EA-43DF-A12F-11A6A98EB96A@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-26_11:2021-01-26, 2021-01-26 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/jav9TOP498K3DmmBmrXUnUJGVkg>
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 02:56:36 -0000

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

-
Vidhi

> On Jan 26, 2021, at 2:18 PM, Joseph Touch <touch@strayalpha.com> wrote:
> 
> 
> 
>> On Jan 24, 2021, at 10:41 PM, Vidhi Goel <vidhi_goel@apple.com <mailto:vidhi_goel@apple.com>> wrote:
>> 
>> I apologize for the late response.
>> 
>> I support the "Two options” but with a suggestion which can help to eliminate the extra 1 byte.
>> 
>> How about using 1 Byte (instead of 2) for both Kind (3 bits = 7 Kinds) and Length (5 bits = 31 Bytes) combined? 
> 
> 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.
> 
>> 1. Kind field - With limited space for ECN code points in IP header, I don’t foresee that we would be able to have many different “kinds”.  
>> 2. Length field - TCP option length is limited to 40 bytes and with common options like timestamp, SACK etc, I think 31 bytes for ACK ECN option should be more than what we can fit in.
> 
> FWIW, we do have a standards-track update to extend that option length arbitrarily in non-SYN segments (draft-ietf-tcpm-tcp-edo), once we have implementations at least.
> 
> Joe