Re: [tsvwg] Deprecating RFC 3168 for future ECN experimentation
daihuichen <daihuichen@huawei.com> Wed, 31 March 2021 03:15 UTC
Return-Path: <daihuichen@huawei.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 EDEB43A1574 for <tsvwg@ietfa.amsl.com>; Tue, 30 Mar 2021 20:15:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 qSIsbEO2xvnF for <tsvwg@ietfa.amsl.com>; Tue, 30 Mar 2021 20:15:34 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 071C93A157C for <tsvwg@ietf.org>; Tue, 30 Mar 2021 20:15:32 -0700 (PDT)
Received: from fraeml706-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4F9B954kBtz683Kw for <tsvwg@ietf.org>; Wed, 31 Mar 2021 11:08:41 +0800 (CST)
Received: from dggeme704-chm.china.huawei.com (10.1.199.100) by fraeml706-chm.china.huawei.com (10.206.15.55) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2106.2; Wed, 31 Mar 2021 05:15:24 +0200
Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme704-chm.china.huawei.com (10.1.199.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2106.2; Wed, 31 Mar 2021 11:15:22 +0800
Received: from dggeme754-chm.china.huawei.com ([10.6.80.77]) by dggeme754-chm.china.huawei.com ([10.6.80.77]) with mapi id 15.01.2106.013; Wed, 31 Mar 2021 11:15:23 +0800
From: daihuichen <daihuichen@huawei.com>
To: Steven Blake <slblake@petri-meat.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: [tsvwg] Deprecating RFC 3168 for future ECN experimentation
Thread-Index: AQHXImHNpOplzDSttk6NxQ3/h/GzJ6qdcOjQ
Date: Wed, 31 Mar 2021 03:15:22 +0000
Message-ID: <5e7e7809cf294769b1184c10c61e707e@huawei.com>
References: <1b673100019174d056c44339d3b1758df058a2aa.camel@petri-meat.com>
In-Reply-To: <1b673100019174d056c44339d3b1758df058a2aa.camel@petri-meat.com>
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.242.228]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/vQdizRny7VMdi7t345qiRAAbes8>
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: Wed, 31 Mar 2021 03:15:37 -0000
Hello, The discussion in this thread, as well as the discussion in the thread of L4S adoption call, seems only consider the Internet scenario. Today, ECN has been widely deployed in data center networks for low-latency transports like RoCE, I think we should also consider the results to data center networks if deprecating RFC 3168. I don’t have a proposal, just a reminder that we cannot leave data center networks out. Regards, /Huichen -----Original Message----- From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Steven Blake Sent: 2021年3月27日 1:02 AM To: tsvwg@ietf.org Subject: [tsvwg] Deprecating RFC 3168 for future ECN experimentation 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
- [tsvwg] Deprecating RFC 3168 for future ECN exper… Steven Blake
- Re: [tsvwg] Deprecating RFC 3168 for future ECN e… Jonathan Morton
- Re: [tsvwg] Deprecating RFC 3168 for future ECN e… Pete Heist
- Re: [tsvwg] Deprecating RFC 3168 for future ECN e… Ingemar Johansson S
- Re: [tsvwg] Deprecating RFC 3168 for future ECN e… Sebastian Moeller
- Re: [tsvwg] Deprecating RFC 3168 for future ECN e… Bless, Roland (TM)
- Re: [tsvwg] Deprecating RFC 3168 for future ECN e… Gorry Fairhurst
- Re: [tsvwg] Deprecating RFC 3168 for future ECN e… Pete Heist
- Re: [tsvwg] Deprecating RFC 3168 for future ECN e… Gorry Fairhurst
- Re: [tsvwg] Deprecating RFC 3168 for future ECN e… Pete Heist
- Re: [tsvwg] Deprecating RFC 3168 for future ECN e… daihuichen
- Re: [tsvwg] Deprecating RFC 3168 for future ECN e… Jonathan Morton
- Re: [tsvwg] Deprecating RFC 3168 for future ECN e… daihuichen
- Re: [tsvwg] Deprecating RFC 3168 for future ECN e… Rodney W. Grimes
- Re: [tsvwg] Deprecating RFC 3168 for future ECN e… daihuichen