Re: [tsvwg] David Black (individual) on safety of L4S for the Internet

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Fri, 15 May 2020 09:59 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
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 10B5A3A0889 for <tsvwg@ietfa.amsl.com>; Fri, 15 May 2020 02:59:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 S-ynbds81qkx for <tsvwg@ietfa.amsl.com>; Fri, 15 May 2020 02:59:27 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id BA0F83A0885 for <tsvwg@ietf.org>; Fri, 15 May 2020 02:59:26 -0700 (PDT)
Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 4E77A1B002B3; Fri, 15 May 2020 10:59:22 +0100 (BST)
To: "Black, David" <David.Black@dell.com>, Bob Briscoe <in@bobbriscoe.net>, "tsvwg@ietf.org" <tsvwg@ietf.org>
References: <MN2PR19MB4045DBC270D70DECE5F2B4AC83A20@MN2PR19MB4045.namprd19.prod.outlook.com> <75435344.181735.1589475836060@mail.yahoo.com> <eb4ff580-0700-764f-df82-ce13344b5743@bobbriscoe.net> <MN2PR19MB4045638F9583301BFEDA9CF083BD0@MN2PR19MB4045.namprd19.prod.outlook.com>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Message-ID: <8a554935-3603-c827-469d-c9e093bf5fa3@erg.abdn.ac.uk>
Date: Fri, 15 May 2020 10:59:21 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <MN2PR19MB4045638F9583301BFEDA9CF083BD0@MN2PR19MB4045.namprd19.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------3A9B7F294AC54DE55582AFFB"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/CoAAUtSeWxr32H3Z1jAM_2-h1is>
Subject: Re: [tsvwg] David Black (individual) on safety of L4S for the Internet
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: Fri, 15 May 2020 09:59:29 -0000

See in-line

On 15/05/2020 01:03, Black, David wrote:
> Bob,
> [still posting as an individual, not as WG chair]
>
>> Firstly an appeal to everyone to stop talking about wiping the ECN field
>> as if it is acceptable. Bleaching ECN is not a safety mechanism, except
>> as a last resort. Treating ECT(1)/as if/  it is Not-ECT is far
>> preferable to wiping it so it/is/  Not-ECT.
> I concur with that appeal ... but ...
>
> ... We've been through an analogous adventure with DSCP bleaching, as RFC 2474 recommends that behavior for DSCPs (treat unknown DSCPs as best effort without changing the DSCP) but the network operators went ahead and bleached DSCPs at network boundaries, as described in Section 1 of RFC 8100 (https://www.rfc-editor.org/rfc/rfc8100.html#section-1).  I strongly suggest reviewing that history towards understanding why things turned out that way.
>
Well, some operators have chosen a model that does that, I can't resist 
self-citing some research that shows this might not be the full story 
..."Exploring DSCP modification pathologies in the Internet" (2018).

https://www.sciencedirect.com/science/article/pii/S0140366417312835

The reasons for field bleaching seem to vary, (and, alas, a significant 
proportion still seems to be due to configured ToS semantics).

Gorry