Re: [tsvwg] New Version Notification for draft-heist-tsvwg-ecn-deployment-observations-02.txt

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Tue, 09 March 2021 16:41 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 9F82B3A1364 for <tsvwg@ietfa.amsl.com>; Tue, 9 Mar 2021 08:41:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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 nbFLzSTkMhCr for <tsvwg@ietfa.amsl.com>; Tue, 9 Mar 2021 08:41:28 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7C63B3A135F for <tsvwg@ietf.org>; Tue, 9 Mar 2021 08:41:28 -0800 (PST)
Received: from GF-MBP-2.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 3B92D1B001B6; Tue, 9 Mar 2021 16:41:24 +0000 (GMT)
To: "alex.burr@ealdwulf.org.uk" <alex.burr@ealdwulf.org.uk>, Jonathan Morton <chromatix99@gmail.com>
Cc: tsvwg IETF list <tsvwg@ietf.org>
References: <161519742798.12373.8424747645620734074@ietfa.amsl.com> <4cc306ea278dab68741b0c27713bfb7c84522e11.camel@heistp.net> <72467bfe9a38edee74c4ab8e12ec350e23315ec9.camel@heistp.net> <ce2c8397-1bb9-8634-7822-88b9ba6d3b22@bobbriscoe.net> <0F3DBF89-9DA3-401C-9793-5F0F2C72ED5E@gmx.de> <22CD0890-346C-4A43-AE20-DCED78E99FEA@gmail.com> <HE1PR0701MB22993B8CE19FD0F077917AADC2929@HE1PR0701MB2299.eurprd07.prod.outlook.com> <414FE1AC-50BD-4929-9731-B5EBDD4A820A@gmail.com> <264638c5-f579-2b0a-cd10-f9995f738d1e@erg.abdn.ac.uk> <374EDDB9-118C-4387-9C44-2B5C471C49A1@gmail.com> <9310b37c-8b82-1ce4-446d-a494c81e0602@erg.abdn.ac.uk> <1653123300.623993.1615307583540@mail.yahoo.com>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Message-ID: <fbe8db1a-a860-f9be-e7f8-d85407834ae8@erg.abdn.ac.uk>
Date: Tue, 9 Mar 2021 16:41:23 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <1653123300.623993.1615307583540@mail.yahoo.com>
Content-Type: multipart/alternative; boundary="------------EF1A0B027217FF595EA7CAB4"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/v_JzSMD2BAssg4Gp6bAgxFJwPyw>
Subject: Re: [tsvwg] New Version Notification for draft-heist-tsvwg-ecn-deployment-observations-02.txt
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: Tue, 09 Mar 2021 16:41:31 -0000

On 09/03/2021 16:33, alex.burr@ealdwulf.org.uk wrote:
> Gorry, Jonathan, tsvwg
>
> See below  [AB]
>
> On Tuesday, March 9, 2021, 4:18:23 PM GMT, Gorry Fairhurst 
> <gorry@erg.abdn.ac.uk> wrote:
>
>
> On 09/03/2021 15:44, Jonathan Morton wrote:
> >> On 9 Mar, 2021, at 5:42 pm, Gorry Fairhurst <gorry@erg.abdn.ac.uk 
> <mailto:gorry@erg.abdn.ac.uk>> wrote:
> >>
> >> I understand that to say: if a router wishes to be compatable with 
> L4S, this is one way to do this. The recommendation(s) could be 
> stronger, if the community thinks this is what is needed.
> > As I tried to point out in my talk, the problem is that a great many 
> people are already running RFC-3168 compliant AQMs with no knowledge 
> of L4S and, therefore, no "wish to be compatible" with a new spec that 
> explicitly violates the spec they built against.
> >
> > Myself included.
> >
> >  - Jonathan Morton
>
> This is pecisely why we have a standards process to make this change.
> When the work on L4S was first brought to the IETF, I know many people
> weighed the prospects of replacing the RFC3168 behavior.
>
> When the L4S specs are published, this will indeed be a disruptive
> change for some, and people deploying and implementing do need to
> consider this. The place to describe this might be in
> draft-white-tsvwg-l4sops within the tsvwg, if this is adopted (this
> adoption call is on-going currently on the tsvwg list).
>
> [AB] Not sure it's a problem, but rfc8311 (sec 4.2) says variation of 
> marking behavior between ECT(0) and ECT(1) must be specified in an 
> experimental RFC. The ops call just made for draft-white-tsvwg-l4sops 
> is to be an informational RFC.
>
> With hindsight, I'm not sure why rfc8311 (which is standards track) 
> didn't deprecate marking ECT(1) the same way it deprecated endpoints 
> using it, outside experiments.
>
>
> Alex
>
Thanks Alex,

I noted that.

Let's see if there is WG consensus to support the OPS draft for L4S.

If you think we need RFC 2119 language to express the intention of the 
draft, then we'll certainly take this into consideration after the WG 
adopts the ID. we'll figure out the standards status for this document - 
this is largely a Chairs role to steer the documentation/recommendations 
to the appropiate specs, but one where we do appreciate input!

Gorry