Re: [tsvwg] Deprecating RFC 3168 for future ECN experimentation

Ingemar Johansson S <ingemar.s.johansson@ericsson.com> Sun, 28 March 2021 18:36 UTC

Return-Path: <ingemar.s.johansson@ericsson.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D01A3A232F for <tsvwg@ietfa.amsl.com>; Sun, 28 Mar 2021 11:36:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.822
X-Spam-Level:
X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_DOTEDU=0.28] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 h_lgH-7kszYR for <tsvwg@ietfa.amsl.com>; Sun, 28 Mar 2021 11:36:19 -0700 (PDT)
Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2084.outbound.protection.outlook.com [40.107.20.84]) (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 E51183A2330 for <tsvwg@ietf.org>; Sun, 28 Mar 2021 11:36:18 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PPuvtg9roA5qN1hRjWaMyOf5mSpCxNci8x0Xtl86hJsjGjYKki4z766LMIPUJNp4KWb+Ze3rWmfOo6ekbhtfakdq9i8+moVRX0AQ7e2677q9+6Ix08Dg5bCp8ZMiJdZr78ZU9H5o0BZGNELQzdvYf3BJZ/a0V97Cwxtck2oSF46Zl32e751RpVpG5PSpszVJyX5qshPSaIOZpNTZkYsm9gEtYTSzVgUwZoUPBJafN7jVvORxEXXBlzYT9V/1gtdHLUEZyF0Ot0P9/Pl5CVcGh/JBFFdUFq7hDphuI/5oHh9dDoVAfKIoiC+0BezUmDJ6ou88QSK++c4wSyP9wivDsA==
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=L6Ds4jYjzp6avmZBp/6drUZVFZd6a2ESAgdruW+LhBw=; b=XPw+jM2zrwDglht9K7L/WyIggbZYNFVwyxNGKmDK8+hsJE2uE/aSxSVodtzQdM9zEOepogPazzgr1SjIor0bkzxKckwPX5omge0ywS/MEjZ7rZ3VPfnB+Hsfcan73uDOjOX7gIETkgkP67qYdIMhargNetF0z3PfSt1R4fCMuaHX0B67m6uOm/TkqkUy3ulUV7Kdg3tQlsWQOJhJ9HNdCw24ol4eL+SsJ8nBrbZFjdheQ8ZCZVgsDYdm6cp9mOsbFehe/UnNRhe9KV9THwpWPS2F3XMQYVzaC5GyeuudgYg5gpSaUNQ6qC4jotnogPs/UZvZShatDd8EcpAtIPaJOg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=L6Ds4jYjzp6avmZBp/6drUZVFZd6a2ESAgdruW+LhBw=; b=qGs3lU02siX3ojrFmflEhiAAjmwSjNnYo7KS65k73sCXnUW95BYZ9VlZ2GCxKTUiQVyXltnMg1GZk1uUKAVbBgBTZ2AwlTRfycGMFTtJjrUM5acDw7deZtykD4GLJHDI8LYzK2n2TZ9nRcCJpXIxIXRn5B8WrfCUVKOpazor3KE=
Received: from HE1PR0701MB2299.eurprd07.prod.outlook.com (2603:10a6:3:6c::8) by HE1PR0701MB2956.eurprd07.prod.outlook.com (2603:10a6:3:4c::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.14; Sun, 28 Mar 2021 18:36:12 +0000
Received: from HE1PR0701MB2299.eurprd07.prod.outlook.com ([fe80::78cb:103b:9ddd:1850]) by HE1PR0701MB2299.eurprd07.prod.outlook.com ([fe80::78cb:103b:9ddd:1850%7]) with mapi id 15.20.3999.021; Sun, 28 Mar 2021 18:36:12 +0000
From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
To: Pete Heist <pete@heistp.net>, Steven Blake <slblake@petri-meat.com>
CC: "tsvwg@ietf.org" <tsvwg@ietf.org>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Thread-Topic: [tsvwg] Deprecating RFC 3168 for future ECN experimentation
Thread-Index: AQHXImHDrRM4qN4R8UmRE3tpl236/aqX6boAgAHPCnA=
Date: Sun, 28 Mar 2021 18:36:11 +0000
Message-ID: <HE1PR0701MB2299F9216029B33499B97E74C27F9@HE1PR0701MB2299.eurprd07.prod.outlook.com>
References: <1b673100019174d056c44339d3b1758df058a2aa.camel@petri-meat.com> <fc0e7ffe6cb66896000be498bf2be8ca1abd3fd7.camel@heistp.net>
In-Reply-To: <fc0e7ffe6cb66896000be498bf2be8ca1abd3fd7.camel@heistp.net>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: heistp.net; dkim=none (message not signed) header.d=none;heistp.net; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [83.227.122.88]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 389203a7-0dce-491d-fc86-08d8f2185ca2
x-ms-traffictypediagnostic: HE1PR0701MB2956:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <HE1PR0701MB2956FD0C6B165678882392F1C27F9@HE1PR0701MB2956.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: BJbM721kWTkuRvhbGNZu5Iho4qrfaCF0pBI5B4E2QWaTcWRlHPU3HEYHYfieXO4IWtATWKlrRIalIb2tTJzLvu/8QTyxEdLybSI48TZgl/VS+E8vceI6qtxEosCrUWd/otxiOWaHsBbKLFAkuDBTP/PP9t45v4KfMKbdrZFO8zifKyASCmyihsS5BBWth3IXgEtPEil/W5p8SblAF4RT8f3d9E5UpCCHFNGVJMyPF/4Su6fpFlBrm61UYY9AVY+snFDu//JNCmDt3RvbpoFsSNmh5P3gFES7XWBv+hD2OAFKPfcNFLRUZ7EQKjaaksuXBirc81Yhm68qqA2eQwIX2GG2DiTB8rd1oFOmO5mxseNjIewqhlotx0jfReMfMRXr+j/sv4jWiWnLVXMfifpmRUwo4ZXK/puqS3Irt0QJkKyZeltlEGGuUF+W1givuQEYSB2q4Ddyqm3SDH+0xeBi0Elhr/bwVvkn3n8HdaB3n8nqB1NwXnzoLNWDQtucnNh2aGahw+Y6lRmtxVsWMSXfbOIWkHb7T4irSwSNPChHWr6rPm8H/Uol/oqwzJnyAbe8EUZDIhmeT3aSPhdzZHguh1SBZVnTZWw9bxYWxQJGUpsubgD5nHrKuWjVR14ydmDIh22OGHvP/xGaKh2AWPNIM0IMu5dxfVwAFtzXuygNO8BVX5EqhAZDKQgOyHqrI/brfpGbducpKNrvw+0zzsyY9Twrurk/kAxrtVYR6OFUMhwyp3r7v/u9bOd1qrw/bCle8PlqDxCYmUk7YisMhPxjHQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB2299.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(346002)(39860400002)(136003)(396003)(366004)(66476007)(66946007)(64756008)(8936002)(66446008)(66616009)(8676002)(55016002)(5660300002)(38100700001)(66556008)(76116006)(966005)(83380400001)(316002)(9686003)(52536014)(478600001)(33656002)(26005)(2906002)(54906003)(110136005)(7696005)(4326008)(107886003)(6506007)(53546011)(71200400001)(186003)(66574015)(86362001)(99936003)(562404015); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: m92w9jfgLhqi7wml/al2smupiIn2KtEpLpMeF+wO9Pqx/5NkOqDhxL5ad02p3hEsclIwzSr9vtz8/cWopzLv0/Jl2uGOotxy+i22Dk2FDJsj5+2WalFcyJgrWVkbcT6K2IFs8V2DAJODQDq3Hb8fFa93BdYf9HcaLfXZXLpBDHxEDRdtK/ee1bXOevom1DyDabX2TGcMRSEu/VfkP7HCVVlAD/RzpP3aNTnVjq+1cCL8o6U/7w3gkaAgI9kc89lZfBzpOCwi+VGzBflzPirr2A9jLukcf8YoHhOu2uF7lnpOvK3khs5+7mPdMCcw/a9qr3X7Jo9zbxagm5sqJnIR6SaviL2S32VcQv6ijTp2epjz/ump+TaQz2rV7Bvt8aluAYb76CDoQJMTo8ZqWA/rgFS+ukleuSRhRm0AJBf4oIOMtsSM38fF6l7Ei7W0UQJuB+oN9wR1GX7a/Xf0S719FHSYeHz876aL6vxfkndaNjbOwLpZcgHqxdiSAuoL3NW9Ftzknre8YGXCD15uo4T7PAM9MDKGZcRT1Il3g1wvD8pxq+22h6u3qsLR0X9Wdz5tVjULTmzI04uQw0aDJYgkV8fBTHOtEI/eHenykHhStpVMuYhqt0YIJVe3HJB836cyMhniWgqJdxKoKNWJpM/9WEkknUTv0VKJvlRVewo0AzqHUNBIzP6RRQDxda/n9FPcHt1ZqYV/BZyDyMv9LWC1heZkFY1CN4zCzggy/An/xXELiq3nxpmZyYGeDPOHZb1t2+nq6MR0tgc4mCqmXPUonbNk5ZAGsFNBG6AuNqBjpI8FJNdCcRYZBjXEbkd0DCEnosh/9kt2HUY8aGMUCMiBv8Ww0NDkAYCj3eigDxtAsrxyfIP++Jy0zL5O4aYDj74laT6H2DYy8jLIhdxa1b6lF3g4Av4HuKREWG4LUkgmzdgjyUp8lx604roK6hGdA7esAEI5d15kbDBvRl/mQea2GJSsxDNs9TT6T1a2zKmaYJhlp0uCGUtn/mdM3EZELrtdVfF1GBdKvRVHovUztmR3QZimAyaRBb48HFR+hyeb24p6f6u8gJE7hRELYZiM+tneOql5C/EA1vnMoef788xhJM79G5zpajdgo6i3LBuq0KjeBLTNCwx9LpSsnF/3gMuvCh/dypJBgPS3ukmt3ecTbzFkTN40GaWVQlJAzKdtrKI5uDIej4JiwlFOvctzspQ71vhDoYp1nL5Ezix/8WGobgz4ZQllTeFj11k4e3OdpTXVBcvWR+Ic96pCPIU9x4vzZRXq7nYTm8ruUfONQIRPAd2x/7G3CWgvb56GI9k4vKPhrdn7/fyaQZgqbyOOShm9
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0519_01D72411.FC5C2460"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB2299.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 389203a7-0dce-491d-fc86-08d8f2185ca2
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2021 18:36:11.7988 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: T1AQnSN4w4voZzzruaIu8h44Sa7FMm4tPr0+V8UtHvV/V5+NU1zlwkKcqiR82yxz50H32dtE+lvvZFwVACEocyx71vZMniO0Fh33l+mbMv+Ki1Vf59+dOT/TDwM/ts++
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2956
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/qHCQgRq5RXp-fh0jVQ6VQfUkZ3k>
Subject: Re: [tsvwg] Deprecating RFC 3168 for future ECN experimentation
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 28 Mar 2021 18:36:24 -0000

Hi
I am not sure about the purpose of this discussion but it is free speech.

I any case it could be worth stating (for the general audience) that the 
charter of the WG is still as given by
https://tools.ietf.org/wg/tsvwg/charters
In particular
  Oct 2021 - Submit "Low Latency, Low Loss, Scalable Throughput (L4S) Internet 
Service: Architecture"
     as an Informational RFC
  Oct 2021 - Submit "DualQ Coupled AQM for Low Latency, Low Loss and Scalable 
Throughput" as an Experimental RFC
  Oct 2021 - Submit "Identifying Modified Explicit Congestion Notification 
(ECN) Semantics for Ultra-Low Queuing Delay"
     as an Experimental RFC

The ideas below have likely been floated before, after all they are not rocket 
science. In particular the accelerate/decelerate was recently presented in a 
Stanford or MIT paper (not sure which) and I am pretty sure that it was 
discussed even before that.
There are reasons to why we are at the present proposed solution.

/Ingemar

> -----Original Message-----
> From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of Pete Heist
> Sent: den 27 mars 2021 15:41
> To: Steven Blake <slblake@petri-meat.com>
> Cc: tsvwg@ietf.org
> Subject: Re: [tsvwg] Deprecating RFC 3168 for future ECN experimentation
>
> I agree overall. If we want to introduce a proposal that's incompatible with
> RFC3168, we should first make it historic.
>
> Before we do that though, we should make sure that the current CE is not
> actually useful. Figure 5 in this paper suggests some benefit to two bits of
> signal as opposed to one:
> http://buffer-workshop.stanford.edu/papers/paper34.pdf
>
> A second signal provides a harder backoff without packet loss, for example
> during capacity changes or flow introductions. It wouldn't be ideal to
> deprecate RFC3168, only to find out that another bit of signal in line with 
> CE,
> along with ABE in RFC8511, or something similarly deployable with today's
> equipment, is still useful.
>
> It's also my position that we can't ignore existing RFC3168 bottlenecks, not
> just for safety but also for performance. The recent ISP study we did
> suggested RFC3168 AQMs may be present on ~10% of Internet paths there.
> Prior to that we heard 5% elsewhere. Whatever the number is exactly, these
> AQMs do exist and mark in response to both
> ECT(0) and ECT(1). If you introduce traffic that backs off much less in
> response to CE, the AQMs may operate sub-optimally, since they weren't
> designed with that kind of traffic in mind
> (https://protect2.fireeye.com/v1/url?k=d314eb2b-8c8fd268-d314abb0-
> 861fcb972bfc-578ed7f13c74c412&q=1&e=ebe2f7ed-6fe3-4c6b-8b9d-
> 07170e08ad77&u=https%3A%2F%2Fgithub.com%2Fheistp%2Fl4s-
> tests%2F%23intra-flow-latency-spikes).
>
> On Fri, 2021-03-26 at 13:01 -0400, Steven Blake wrote:
> > A lot (not all) of the recent arguments revolve around the assumption
> > by some that RFC 3168 ECN deployment barely exists in the Internet,
> > and the few networks where it does can be safely ignored, or cleaned
> > out, or be expected to take proactive measures to protect themselves,
> > which may in practice require them to lobby their router vendors to
> > spin patch releases to enable (some of) the mitigation measures
> > detailed in
> > -l4ops-02 Sec. 5.
> >
> > If that is the WG consensus, then I *strongly urge* the WG to do the
> > following:
> >
> > 1. Push to move RFC 3168 ECN to Historic
> >
> > 2. Adopt the following "New ECN" signals for future ECN
> > experimentation:
> >
> > - Not-ECT
> > - ECT
> > - CE-a
> > - CE-b
> >
> > This second step would allow for two sets of experiments. The
> > semantics of CE-a and CE-b for the first set of experiments would be as
> follows:
> >
> > - CE-a: "Decelerate"
> > - CE-b: "Decelerate harder" (multiplicative decrease)
> >
> > The exact behavior elicited by the "Decelerate" signal would be the
> > subject of investigation. Since we are certain that any remaining RFC
> > 3168 deployments can be safely ignored, then ECT/CE-a/CE-b can be used
> > as unambiguous signals to steer packets into a low-latency queue, if
> > desired.
> >
> > The semantics of CE-a and CE-b for the second set of experiments would
> > be as follows:
> >
> > - CE-a: "Decelerate"
> > - CE-b: "Accelerate"
> >
> > An aggressive fraction (100%?) of CE-b marked packets traversing a
> > queue not in "Accelerate" state would be re-marked to either CE-a or
> > ECT. Any packet discard (or detection of high delay variation?) must
> > disable the transport's "Accelerate" mechanism for some interval and
> > should cause the transport to revert to "TCP-friendly" behavior for
> > some (different?) interval. The exact behaviors of "Accelerate" and
> > "Decelerate" signals would be the subject of investigation. Again,
> > since we are certain that any remaining RFC 3168 deployments can be
> > safely ignored, then ECT/CE-a/CE-b can be used as unambiguous signals
> > to steer packets into a low-latency queue.
> >
> > The differences between these two sets of experiments hinge on whether
> > there is more utility in an "Accelerate" signal coupled with a
> > "Decelerate" signal, or with two separate levels of "Decelerate"
> > signals. Since it is WG consensus that the RFC 3168 ECN experiment
> > failed after two decades, we probably only get one more chance to get
> > this right, so careful and exhaustive experimentation which explores
> > the design space is in order.
> >
> > Obviously, both sets of experiments cannot be run simultaneously on
> > intersecting parts of the Internet. I leave the options for safely
> > isolating these experiments as an exercise for the reader. Since we
> > are certain that any remaining RFC 3168 ECN deployments can be safely
> > ignored, I suggest choosing bit assignments for the four signals that
> > induce maximum pain in the obstinate minority that might still deploy
> > RFC 3168 ECN.
> >
> > Now, *if it is not WG consensus* that any existing RFC 3168 ECN
> > deployments can be safely ignored, then I *strongly urge* the WG *to
> > not adopt* experimental proposals that place burden and/or risk on
> > networks that have deployed it.
> >
> >
> > TL;DR: Either RFC 3168 ECN exists in the Internet, or it doesn't.
> > Decide, and act appropriately.
> >
> >
> > Regards,
> >
> > // Steve
> >
> >
> >
>