Re: [tcpm] draft-ietf-tcpm-accurate-ecn-08 inconsistencies?

"Tilmans, Olivier (Nokia - BE/Antwerp)" <olivier.tilmans@nokia-bell-labs.com> Fri, 22 March 2019 10:47 UTC

Return-Path: <olivier.tilmans@nokia-bell-labs.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 0C95F130DE7 for <tcpm@ietfa.amsl.com>; Fri, 22 Mar 2019 03:47:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=nokia.onmicrosoft.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 qJkuC7q_r-3k for <tcpm@ietfa.amsl.com>; Fri, 22 Mar 2019 03:47:41 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on072b.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1e::72b]) (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 9A4721200B3 for <tcpm@ietf.org>; Fri, 22 Mar 2019 03:47:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector2-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LU101cBGj1oCsdn1tDPSsza7Uac6HtRYkSZZK4i05Hw=; b=kKADTror2WLhRs7Cr2v33IvoxCA5+pMJu02NGccv0XDqZdeiJSWik+80aSda5eIHRHrtXMVhufpWEwlFpnOGYoOip7HcHteqUbRYIHOFaQ5KZAHLntCmfGPUDSe9wNmZVJyav/kUnnfb85TyAofOwyZQjdcd6gIn2cAEF47fRHg=
Received: from AM0PR07MB4819.eurprd07.prod.outlook.com (20.178.19.14) by AM0PR07MB6019.eurprd07.prod.outlook.com (20.178.112.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.11; Fri, 22 Mar 2019 10:47:37 +0000
Received: from AM0PR07MB4819.eurprd07.prod.outlook.com ([fe80::59f0:fdb8:2725:c844]) by AM0PR07MB4819.eurprd07.prod.outlook.com ([fe80::59f0:fdb8:2725:c844%4]) with mapi id 15.20.1730.013; Fri, 22 Mar 2019 10:47:37 +0000
From: "Tilmans, Olivier (Nokia - BE/Antwerp)" <olivier.tilmans@nokia-bell-labs.com>
To: Bob Briscoe <ietf@bobbriscoe.net>
CC: tcpm IETF list <tcpm@ietf.org>
Thread-Topic: draft-ietf-tcpm-accurate-ecn-08 inconsistencies?
Thread-Index: AQHU4IrHtT6VMmuBIk2I678VPDmkzqYXeD3w
Date: Fri, 22 Mar 2019 10:47:37 +0000
Message-ID: <AM0PR07MB4819372326EC8F99A7CFFC67E0430@AM0PR07MB4819.eurprd07.prod.outlook.com>
References: <71f6ff55-6b8b-b488-873f-81c0f37dce99@bobbriscoe.net>
In-Reply-To: <71f6ff55-6b8b-b488-873f-81c0f37dce99@bobbriscoe.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=olivier.tilmans@nokia-bell-labs.com;
x-originating-ip: [40.67.249.122]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 72051680-f3ff-467b-639a-08d6aeb3cce0
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM0PR07MB6019;
x-ms-traffictypediagnostic: AM0PR07MB6019:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <AM0PR07MB601934A2F6BA548C972E0DAEE0430@AM0PR07MB6019.eurprd07.prod.outlook.com>
x-forefront-prvs: 09840A4839
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(136003)(39860400002)(396003)(366004)(199004)(189003)(33656002)(8676002)(81156014)(6506007)(14454004)(53546011)(476003)(6116002)(3846002)(76176011)(102836004)(81166006)(486006)(26005)(7736002)(86362001)(99286004)(68736007)(106356001)(6436002)(8936002)(478600001)(7696005)(6916009)(105586002)(71200400001)(71190400001)(74316002)(966005)(5660300002)(316002)(446003)(52536014)(229853002)(66066001)(2906002)(53936002)(97736004)(53376002)(6246003)(256004)(25786009)(6306002)(54896002)(9686003)(55016002)(4326008)(186003)(606006)(236005)(11346002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB6019; H:AM0PR07MB4819.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1;
received-spf: None (protection.outlook.com: nokia-bell-labs.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: rX3UmADO2uwuK8FXbOasjyQyhA7lYgAwqJjxk2A94VVVv3TIqOP/UXdsu4yTvjvmEiGJu/v/tmiFxBbW11igLRsg9w0rvZlsvG71H3VlTvW5TVL9aONydelIvExRxr/+XeSOpQN2rzcZ0qHCzDH37HBOz9eXer1y5jz5NEGxNX7mUpaDltm9fBZw3pw+esVRHg7ag3W3gB1Wg2fVndbB5DUH7GoQOUYxpmTUa/i1PhOtIC58EloGCxttyD20rdXTR8zN+rsHlMmpcmNsWG5xSmN8juLjwdvd51zrKotBYbHYfT1SdwxIJs2o8wMg0Zz1eSCkuOHqnUySY8qPw69Nv6r0VhDq0Kuo1kuTNrFnl2BuvKl2ovcaU9hHdxejGOC1VV7npnGWTQ8pAiLBp0ZyoieksekQUls59Bvy5sKFAbM=
Content-Type: multipart/alternative; boundary="_000_AM0PR07MB4819372326EC8F99A7CFFC67E0430AM0PR07MB4819eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia-bell-labs.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 72051680-f3ff-467b-639a-08d6aeb3cce0
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2019 10:47:37.4917 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6019
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/x3L0d5A2Giwnb2iNPi210GNo6V8>
Subject: Re: [tcpm] draft-ietf-tcpm-accurate-ecn-08 inconsistencies?
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: Fri, 22 Mar 2019 10:47:44 -0000

Bob,

Thanks for looking it up.

The perceived difference I had was due to the notes 2/3 in table 3 in combination with the s.cep column which led me to believe that all values but 0 were acceptable for the final ACK of a statefull opening, whereas the syncookies case was stricter.

The ecn negociation status is embedded in the syn cookies, the 0b001 ACE is thus not needed/used to remember/identify that classic ecn was negociated (at least on Linux).

It should thus be possible to be more specific about what an AccECN server should do when receiving an ACE of 0b001 on the final ACK if it had an AccECN state for the connection/didn't find back the ecn bit in the syncookie: should it fallback to classic ECN? Disable ECN altogether as that is an error state? I doubt this can be safely ignored...
The draft doesn't specify it beyond 'it ought to be impossible'.


Best,
Olivier
________________________________
From: Bob Briscoe <ietf@bobbriscoe.net>
Sent: Friday, March 22, 2019 9:39:25 AM
To: Tilmans, Olivier (Nokia - BE/Antwerp)
Cc: tcpm IETF list
Subject: draft-ietf-tcpm-accurate-ecn-08 inconsistencies?

Olivier,

Thanks for pointing out verbally last night at netdev that the spec states three different sets of valid values for the 'ACE' field on the SYN-ACK and the 3rd ACK of the 3WHS (with stateful or stateless handshake).

I promised I would check whether this was deliberate or an editorial mistake....

==SYN/ACK==
Valid values are 2,3,4 & 6

==3rd ACK==
By my reading, the valid values for the 3rd ACK are 2-7 and the draft is consistent in both stateful and stateless cases.
Please tell me if the text is not clear in some way that I cannot see.

==Ease of Implementation==
You also mentioned that the values chosen required an awkward set of case statements, just to check validity. Yes, there's a gap in the sequence - because value 5 (decimal) in the codepoint space on the SYN/ACK might have already been used (by RFC3540). However, the mapping was chosen to enable a simple algo to match them, and for the same function to be used for both SYN/ACK and ACK, as follows: (values shown in decimal)

IP ECN f/b
        ACE SYN/ACK     ACE 3rd ACK
0
        2
        2

1
        3
        3

2
        4
        4

3
        6
        6


A pseudocode expression for the IP ECN f/b would be:
    bool server;            // pseudocode for "I'm receiving the ACK of my SYN/ACK"
    unsigned ip_ecn_fb, ace;
    ip_ecn_fb = ( (ace>1 ) && (!server || (ace & 0b101)) ) ? ace - ( (ace >= 6) ? 3 : 2) : RETURN_INVALID;

What's so hard about that? ;)




Bob



--
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/