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

Sebastian Moeller <moeller0@gmx.de> Sun, 28 March 2021 20:14 UTC

Return-Path: <moeller0@gmx.de>
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 1692C3A254D; Sun, 28 Mar 2021 13:14:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level:
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 7AjOXCSbFRVP; Sun, 28 Mar 2021 13:14:40 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 F055C3A2548; Sun, 28 Mar 2021 13:14:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1616962434; bh=4zvMg+6gxhzJ8f/BDh7gSMJhuP/2SnGPubROMh3/0I8=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=KdEVpA1tGPnCbJuNO3F7PYIqNFRl9d38qnVnSqYIJlQz2fdUD7TembXOTDVfBeZrT cr+sfo5zF6gyZeBKfxCDMsqVdiuAN3ykp/F0rKWX0sKjfXw7806bvpkZgUMZ/c9no5 6q32McB+0VdYrX2hHxEB3PrsFn75D87CfqsgkXoE=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.42.229] ([77.10.97.225]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MOiHf-1lHUbd03gd-00QAbh; Sun, 28 Mar 2021 22:13:54 +0200
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <HE1PR0701MB2299F9216029B33499B97E74C27F9@HE1PR0701MB2299.eurprd07.prod.outlook.com>
Date: Sun, 28 Mar 2021 22:13:52 +0200
Cc: Pete Heist <pete@heistp.net>, Steven Blake <slblake@petri-meat.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <28D23828-479E-43A1-9578-B44434866580@gmx.de>
References: <1b673100019174d056c44339d3b1758df058a2aa.camel@petri-meat.com> <fc0e7ffe6cb66896000be498bf2be8ca1abd3fd7.camel@heistp.net> <HE1PR0701MB2299F9216029B33499B97E74C27F9@HE1PR0701MB2299.eurprd07.prod.outlook.com>
To: Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3445.104.17)
X-Provags-ID: V03:K1:GUIQVhN263dhNgfXdNiWSIGpE4Dgh1KwX2tnmKHSfXljinWUCV5 XfOAe2a7LI1dp5/lDTin7xRTjv/AUU10rgb6rHv3yfYFFRTA542fy/e6WRFVUNnUGxKg5Wk F8qdKN+jsjwTwi5aAWxTQONWmTkfCZl5kKBC0qKTvnqUHGPlMFl04kPl81PH7bzutP+LYP3 wYQ57gGdxoy8bGroqgQew==
X-UI-Out-Filterresults: notjunk:1;V03:K0:WFuxhL1+gls=:8u9vLzhDVSpDfnYTcFFlOY OSkGw58clQOu7+DIfLqJUHFoi0JwQeRiXAITNkYPba6aU8Z9rYsIetSaQh5plFLgiPbFHi1Uo /EqxZXKzP3qxgtuSYBo4jpB23jmYLk1LYCxN7FeR+LUe6yqeJmZDwJdhT4DjM5xa4H9fYrCuf 5xNCXQ2U6/L5Iep859HaEF6UKTnwEkwG2EEUHAhaqbQO4QyhWTkGRI+Eio4mTPGk+F7xdkR4R +/yaNz3LZoYOnoSYyLfh32iEBWJhTTxXz0bnjFnr4eoBtCqWgPWqq13fkzIdzovCQO9+gQZZ0 XX5rly1l1NOdjaaYlIgkAvtNwZqef5Wf6ltbPJCcmLGgcJyihk46+6d6skQt0ldtjbHqQPyOS Z4ZEUuc5AIozIaZwjO7et2eGEfTXr6CrxPLVsRJ+WDnnugHoPUDyenn8vHzg45GZ7ULJ40hQZ pGMPFyAGslcm5IlSELSfycb9oZpU8nOUqyaIsd4ob02h34UE+mY8nciST4YvUoid8byiVZtaC B7r1fhhMFbkIVn8sE0Dkc6OoMaE+X9pv7cifrlJbPRSrBrQLtauIZ5c0gvsv70vdeREcvZ4Zl mlrHWsBJ91ob+gfrtz9Niqmav9PYCbmmaf7J9vCLgXbRZGlgjaGE80b5+LZEHVlvqEMc+U7GN SCLuck59Tw/dT/ejh7oTZ4hNN6WRYz0yFdwpQXmMyUSh3QkgeSb1xo01aOMDaX+pveqFOC/1Y xwmHPhGV7tHOEkjcfYPp3BG1uYOh1wb/BKNO8huOxgqypAfpRg6t4AoDUMjjbQPBxiy0MbWaN xWT3P+zF2tN+e+Xaub//DJGrqqT+nLOZrCK4JdLdOQRzd1JYRuaLdP8GoKNFkarQIo0gLZDvU i4uqMDcmM/fldv/1zD6qjpEWPMvE3zR2aI6ibXwlh3I/28rp8eYN4CuiheYfYficDi5ZJ0Yi3 caIE6/2TFyh0OicvIPfSkNnyYtw9Vur9CYn9kaKVV7VcNsVUF9RgELD1QpApahDA//FZ2wDYj BB8d4w1YK2URvbg4ABwQglWXZsUnOI3XmZmlJ90Ol1rKV/bFyGHfM4Nbe0j0/EyY0kA5s5cMx P4bngHDSre/ZTDG6kWmEcSoZGaYqG3KEga7aTxEaFWHuIqT1tRnbjVRVwc82PSK19vPO9Ng7Z axxbXUYF2CNa1m/uvSrwv5WtrmXeB10CyKHrDjS1xTD9ChBHi/OQd68JwcYE0dbFSPWLmCi7L 33ryb0+s3cUfV3xOajlzM7aRXfIOG7ofZh36GiMVl3eTMFvHepgCV0nujHjY7VLiwXkkisqsO UPxjMPmK
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/0ziA48qohoCKRy2HNHlYF8-C8QM>
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 20:14:45 -0000

Dear All,

Ingemar helpfully directed my to our charter. Where I find among other's:

"(C) Maintenance of IP Differentiated Services (DiffServ) mechanisms,
    which involves mostly advisory documents on the use of DiffServ in
    specific application scenarios. Other work items related to DiffServ
    require Area Director approval."


Based on this, I would say, mandating a guard DSCP for the duration of the L4S experiment (and after depending on the experiments evaluation?) seems to be fully within this WG charter, at worst after talking to the respective AD. 

Best Regards
	Sebastian



> On Mar 28, 2021, at 20:36, Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org> wrote:
> 
> 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