Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Changed to Normative Classic ECN detection Text

"De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com> Sat, 31 October 2020 23:42 UTC

Return-Path: <koen.de_schepper@nokia-bell-labs.com>
X-Original-To: tcpprague@ietfa.amsl.com
Delivered-To: tcpprague@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1B73A0A25; Sat, 31 Oct 2020 16:42:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 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_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 vusvvoaHQ06v; Sat, 31 Oct 2020 16:42:04 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70131.outbound.protection.outlook.com [40.107.7.131]) (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 1F4E03A0A26; Sat, 31 Oct 2020 16:42:03 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HkXiFTWUkx2rTSOkZn3VmnTRgAI9nlJT90TxfUb/DKyro/cy+/LFLAoNVJwhlp5Aq8jh4+/2HME6EeZ0MaSDyOpTio3TC1q6zWS0src4x9Aec0zrU3VfkXrysdyzjwM0dSDWwj9j0Kz9jQsEiY+B9WLO3MO7E275d6B66a2bnu9mO2bADmEnIXzaTkoC1UozpbUYv2g45IObzLi0A78BWPan0kZljCvn4FhhGxhIwRdebF9MB6MpUTMUJsZw2OQyDfB8ojFW7obpIPKZqc+cLOR/Kx9tYOZSJ7AQ5QkvkPMQhWdOHeovAC/Y6up7WeIfICEpoXP5UdUAA6et4ScdLg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bjN8azE1wG4DfVgcI/dmbog2b7Z4EPM+OUxLloHr1Rw=; b=f7MfsWZ5XEtelP0reRKvloYyJlpO24v5IVWS+3Yo+LcUzgJsJ56N//BUvIm3kcF9DPc90p8I8fEsHR8yUvY5ejHBTWUyPnOB6ceSNC021Cq1c5EwFYwpMSoYf/hkAZR9m/n/N8gnX7pWxECNOLs00RcT5byaZfXdVdvLKcwA2cUm+5mvMeU9sg3lsXKansZzltef717DlvfwaQyrjNuP6hnv5quuBLzugEqj3czhMb1U2dJnXZEUl0H9aj5RhWlUQ9lVo/j8w31PNv5pTvlDpa9EF8smHkySgrUX1OB/TTeBASfA2IaQL1xuCJxw+EBVI45cC4Ghmc/hhNKNOIrPjw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia-bell-labs.com; dmarc=pass action=none header.from=nokia-bell-labs.com; dkim=pass header.d=nokia-bell-labs.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bjN8azE1wG4DfVgcI/dmbog2b7Z4EPM+OUxLloHr1Rw=; b=c/K2+sJA6+jdw5QmA21gzz+rc6JTRWbSdickzUkXYluh+PMtdX/OZCPvv+X7ZuORD7X+4OeDV1Wzc34i9+1LKTb/GCdu5qlm2Mnxoxpwi6l43SRBfXXHDSXa2ym+5xvbiP61e6Y6NAA7/8N2fGekEyXk17+pwZxZb24u5Njtthw=
Received: from AM0PR07MB6114.eurprd07.prod.outlook.com (2603:10a6:208:113::33) by AM0PR07MB5218.eurprd07.prod.outlook.com (2603:10a6:208:e8::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.10; Sat, 31 Oct 2020 23:42:00 +0000
Received: from AM0PR07MB6114.eurprd07.prod.outlook.com ([fe80::a9f4:9199:8226:d6c6]) by AM0PR07MB6114.eurprd07.prod.outlook.com ([fe80::a9f4:9199:8226:d6c6%6]) with mapi id 15.20.3541.010; Sat, 31 Oct 2020 23:42:00 +0000
From: "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>
To: Sebastian Moeller <moeller0@gmx.de>, Bob Briscoe <ietf@bobbriscoe.net>
CC: tsvwg IETF list <tsvwg@ietf.org>, iccrg IRTF list <iccrg@irtf.org>, TCP Prague List <tcpPrague@ietf.org>
Thread-Topic: [tsvwg] ecn-l4s-id: Proposed Changed to Normative Classic ECN detection Text
Thread-Index: AQHWr5W301dnUenhS0mZoh+uZ8RoxamyMdvg
Date: Sat, 31 Oct 2020 23:42:00 +0000
Message-ID: <AM0PR07MB6114BE26375DFD7B28D75841B9120@AM0PR07MB6114.eurprd07.prod.outlook.com>
References: <1b71a610-75ea-e1d4-e3ce-f0ae6a4c12f7@bobbriscoe.net> <trinity-63e79f62-2574-4f86-8988-08a4e0cac056-1604156057179@3c-app-gmx-bs36>
In-Reply-To: <trinity-63e79f62-2574-4f86-8988-08a4e0cac056-1604156057179@3c-app-gmx-bs36>
Accept-Language: nl-BE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmx.de; dkim=none (message not signed) header.d=none; gmx.de; dmarc=none action=none header.from=nokia-bell-labs.com;
x-originating-ip: [81.82.56.234]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 31bf1e2f-a25b-4115-be2e-08d87df6900d
x-ms-traffictypediagnostic: AM0PR07MB5218:
x-microsoft-antispam-prvs: <AM0PR07MB5218E169EE5B87D31D33925BB9120@AM0PR07MB5218.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: vc5hwmBIiFFsi0V/FAeuGNGJD+T7/lFCcYZk3BLu1MdKQ0FgXH1l321y7VXwtzaiKhP5C3KF836wNXUW3RcQlpIaP65tzJbcQQN4xx83QRdwSsSF8BAFC0Iuf0ApT1E20xStgqxcCS8NyYogZlW+Z8nT2CrfUD2k2lGNqXEQ90wFZXScyL3uFK6H/GLokYh04tufHxaO2w9Lgl5RGB6/sAKsbs+zDeiLqogLto/Bzao8BdxTsZQfsGNykKKg84nNvQq0MifuvLtAueBccRGMqnSq+qTHrTSki6IXs5kJSZMUMdLNXtTq36Whb/tdGSZ9FId94UdIRm6U3c1PqxUEbPoE1Cfb45/+Jj98dIljBok+1LiAo9HBAD+5sYiPFGG0ubLoHHhQjyPYtqYA+sPUFQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB6114.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(376002)(346002)(396003)(366004)(39860400002)(33656002)(316002)(8936002)(9686003)(110136005)(2906002)(55016002)(9326002)(6506007)(53546011)(71200400001)(7696005)(166002)(26005)(4326008)(186003)(966005)(52536014)(83380400001)(54906003)(5660300002)(66476007)(66556008)(64756008)(86362001)(66446008)(66946007)(8676002)(76116006)(66574015)(478600001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: SK3ML+CP8V0dQBKWWfxCbCN6IJMKQYstMq9376QVgRLMYM7/z7oqZS8yERQfdSEDsngrNbx1m4oilGB+cobyO8pGDv5P3ONv9GGILp4OBtWWZZJJXjsJRCotyJn0nzklnxtU+qnJMOooqfi0Y1SisUNj6POqSlaomgbfa/bBnaIuizEaiOFxbBjouN6eb1rBH3UJQDld/+j5Rln6Y4/RXkduWX0tyxaQkiTUkO29PkD2grMxTwMltMckasYfoKEYKS+2noAoBy05O6JEGu4GuqTtmKb0tXoBMNSCJy1rLllaEL67aficPeFpC8J1EFIdViVs7QVJGJL9bCr+UqIWiSUs3dLWNaFF3xk8VGkRCTtvZ+L4GLIGU0b46Ud+W1fcfmx9J+EZ9GnyAWb4lu+can2wLGKublyxKeOKbNMDmuXTbG5jLlgNImgvID3yutIeUsaUtvFo9uSl/a64aMhYV6gT18czXIO0idXzAdf/C122SvcDf/cJ1/3/xMYzlf+m7aUVAlAY6EQPg2Thz6vgv3LYl2aIfdo/GcvmPZxnTs1BSYdyOrDAbn84qTXSe/eUEP9mKW3fSBXpDv7bVNqASwwOfCL6MTzTkm38YHxwtnPnaY3+mcEoN/z1rpVCJXzhGL5C2qcqMwv73YSAaCVNUA==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_AM0PR07MB6114BE26375DFD7B28D75841B9120AM0PR07MB6114eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia-bell-labs.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR07MB6114.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 31bf1e2f-a25b-4115-be2e-08d87df6900d
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2020 23:42:00.3572 (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-CrossTenant-userprincipalname: ULCnlImUfI1kRTF9saXO/WTmtc1r9P8E29RvPLywgI/T1AwbZd6s/ajrbXqKCc9KjZM2RG/5/W/JGW1zoviAVfwSKYXznJzrBCto68uB9TlkljdK4UMOAmftg6Pfjafz
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5218
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpprague/QnxePmVy5FxGXsL5iUELp3GcqsQ>
Subject: Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Changed to Normative Classic ECN detection Text
X-BeenThere: tcpprague@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." <tcpprague.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpprague/>
List-Post: <mailto:tcpprague@ietf.org>
List-Help: <mailto:tcpprague-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 31 Oct 2020 23:42:07 -0000

Hi Sebastian,

>> I appreciate that team L4S is finally admitting that it over-promised and under-delivered

I think the problem is that you interpret “requirements” as “promises”. Most people understand the potential of L4S and accept that special care needs to be taken to protect Single Q Classic ENC bottlenecks. The draft needs to put the attention to (potential) problems that need to be solved or avoided by interesting parties that want to develop their L4S Prague-compliant CCs. So it is in the best interest for CC developers to push for feasible/realistic requirements. I heard quite some people (including you) being concerned about the feasibility of detecting a Single Queue Classic ECN AQM, and said they would rather apply other mechanisms to avoid issues with these types of bottlenecks (ref operational guidelines that tries to collect all useful ideas that were shared during list discussions). So the changes announced by Bob should reflect this. I understood you are quite OK with the wording? If not, then your suggestions are very welcome.

>> "In the unlikely case of the L4S experiment being declared a failure, this replacement will need to be permanent, and the ECT(1) responsive elements in AQM nodes also needs to be disabled".

L4S will succeed if 1) L4S capable network nodes get deployed (including Classic ECN bottlenecks being upgraded) and 2) CCs are deployed that can meet the TCP Prague requirements (is not disrupting Classic flows and other L4S flows) AND can show great benefits. If one of those or both will not happen (like with Classic ECN deployment) it fails!! So I guess no need to worry about disabling permanently if it never gets deployed 😊.

Thanks and regards,
Koen.

From: Sebastian Moeller <moeller0@gmx.de>
Sent: Saturday, October 31, 2020 3:54 PM
To: Bob Briscoe <ietf@bobbriscoe.net>
Cc: tsvwg IETF list <tsvwg@ietf.org>rg>; iccrg IRTF list <iccrg@irtf.org>rg>; TCP Prague List <tcpPrague@ietf.org>rg>; De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-bell-labs.com>
Subject: Aw: [tsvwg] ecn-l4s-id: Proposed Changed to Normative Classic ECN detection Text

Dear Koen,

since Bob claims that he intends to correspond with my input, I am addressing this response to you, See my comments in-line prefixed [SM].

Tl;dr: I appreciate that team L4S is finally admitting that it over-promised and under-delivered, I am less happy about the solution to this issue by simply reducing the requirments ot match the unsatisfactory state of the L4S implementation. After years of basically adveritizing on these requirements, watering those down at the last minute does not qualify as a good faith effort in my book. It does confirm my negative view on team L4S' acumen and confirms my judgement that L4S "offers too little too late". Unfortunately I do not kid myself that this obvious fact is going to stop the current intenet drafts gaining RFC status without any meanigful changes.


Gesendet: Samstag, 31. Oktober 2020 um 10:54 Uhr
Von: "Bob Briscoe" <ietf@bobbriscoe.net<mailto:ietf@bobbriscoe.net>>
An: "tsvwg IETF list" <tsvwg@ietf.org<mailto:tsvwg@ietf.org>>
Cc: "iccrg IRTF list" <iccrg@irtf.org<mailto:iccrg@irtf.org>>, "TCP Prague List" <tcpPrague@ietf.org<mailto:tcpPrague@ietf.org>>, "De Schepper, Koen (Koen)" <koen.de_schepper@nokia.com<mailto:koen.de_schepper@nokia.com>>
Betreff: [tsvwg] ecn-l4s-id: Proposed Changed to Normative Classic ECN detection Text
Folks,

The co-authors of ECN L4S ID have been reviewing the correctness of the normative 'Prague' requirements.

        [SM] This seems less about correctness and more about whether you managed ot hit those targets with your implementation. Changing those requirements post-hoc might be justified, but pleas do not frame that as a correctness isssue.


    See https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-10#section-4.3
This is the second of 2 emails, about 2 of the requirements that we think ought to be reworded a little.

If you agree with the rationale, but think the new wording still doesn't fully capture the requirement, pls suggest sthg better.
If you disagree with the rationale, pls discuss.

4.3.  Prerequisite Congestion Response

...

CURRENT:



   o  A scalable congestion control MUST react to ECN marking from a

      non-L4S but ECN-capable bottleneck in a way that will coexist with

      a TCP Reno congestion control [RFC5681<https://tools.ietf.org/html/rfc5681>] (see Appendix A.1.4<https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-10#appendix-A.1.4> for

      rationale).



      Note that a scalable congestion control is not expected to change

      to setting ECT(0) while it falls back to coexist with Reno.


PROPOSED:
   o  A scalable congestion control MUST implement monitoring in order
      to detect a likely non-L4S but ECN-capable AQM at the bottleneck.
      On detection of a likely ECN-capable bottleneck it SHOULD be
      capable (dependent on configuration) of automatically adapting its
      congestion response to coexist with TCP Reno congestion controls
      [RFC5681] (see Appendix A.1.4 for rationale and a referenced
      algorithm).

        [SM] This is a significantly watering down, and it seems rather non-logical, IFF an implementation does not want/need to actually react to the result of a detection then performing that detection seems pure busy work. So make both of these MUSTs. Otherwise your requirments pretend to care about existing rfc3168 AQMs but in name only.



      Note that a scalable congestion control is not expected to change
      to setting ECT(0) while it falls back to coexist with Reno.

RATIONALE:
1/ The requirement as currently written says what an omniscient sender MUST do. So there's an implied requirement that a sender MUST be omniscient, which is of course impossible.
2/ The requirement needs to be recast to require a sender to aim to be as knowledgeable as possible. Then, what it does as a result needs to take into account the a priori likelihood of there being a non-L4S bottleneck present.
3/ This includes the possibility that the operator of the host knows that the network it serves has not deployed any single queue classic ECN AQM (e.g. in a CDN case they're doing out of band testing, or they've asked the ISP). So we've included the possibility of fall-back being disabled by configuration.
4/ Nonetheless, as has been pointed out on the list, there is still a possibility that there is a Classic ECN AQM somewhere else on the path (to continue the CDN example, perhaps beyond the ISP in a home network). The 'MUST monitor' requirement still stands to ensure the operator doesn't miss these cases.
5/ Then, if the server operators have disabled fall-back for their deployment, they can reconsider their policy or at least do more focused testing if they are frequently detecting a single-queue Classic ECN AQM.

        [SM] And we are back to engineering/network administration by wishful thinking... Again with a syszem (L4S) that has not yet been proven to actually work over the existing internet with the sole exception of short RTT/low hop count paths (CDN to end-user fast-lanes copme to mind).


Items 3-5 are the "react via management" model that I've talked about on the list, given the unfairness doesn't amount to starvation, and it is possible that the prevalence of the problem is very low.

        [SM] Given that you never offered your own specific defintion of what starvation entails, I fail to see how that claim can b tre in a verifiable fashion?


Finally, after the bullet list of requirements in section 4.3, (which are prerequisites for setting the ECT1 codepoint), we propose to add the following requirement, as suggested on the tsvwg list:

      To participate in the L4S experiment, a scalable congestion control MUST
      be capable of being replaced by a Classic congestion control (by
      application and by administrative control). A Classic congestion control
      will not tag its packets with the ECT(1) codepoint.

        [SM] +1; I would appreciate if we could add a sentence like:

"In the unlikely case of the L4S experiment being declared a failure, this replacement will need to be permanent, and the ECT(1) responsive elements in AQM nodes also needs to be disabled".

I added the unlikely in spite of my own predictions, to account for the fact that the drafts are written on the hypothesis that L4S works as advertized....

Best
        Sebastian


Cheers


Bob


--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/