Re: [tsvwg] Adoption call for draft-white-tsvwg-l4sops - to conclude 24th March 2021

Sebastian Moeller <moeller0@gmx.de> Fri, 26 March 2021 09:25 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 EE7F23A193F for <tsvwg@ietfa.amsl.com>; Fri, 26 Mar 2021 02:25:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.646
X-Spam-Level:
X-Spam-Status: No, score=-1.646 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_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 0YxFQKVzbCH1 for <tsvwg@ietfa.amsl.com>; Fri, 26 Mar 2021 02:25:27 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 0C2023A193B for <tsvwg@ietf.org>; Fri, 26 Mar 2021 02:25:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1616750637; bh=CZjQA49qBHygZzhoh0fs1BxU3lzPbYGq3gIJeRGrcmI=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=kqhk/qEgZx9G1wPbKPPOB8shX+F865f33rN5feFeyuEkUVFFWTOcD61NhW6Q/Mhdz sdGjo6hgdxLxYI/vo66l6oABeGT3En+npjdVAyoByrEiQVKiv51xAfMUVG8hSltVr9 dKkQv0qxBwpK6G/SN62rqu8wOBfPeyW69c8KRIM0=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.250.106] ([134.76.241.253]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MeCtZ-1lxxmd3MHf-00bHDW; Fri, 26 Mar 2021 10:23:56 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <d2b3b31e-58e5-1b00-bb84-f65d94c05059@bobbriscoe.net>
Date: Fri, 26 Mar 2021 10:23:55 +0100
Cc: Steven Blake <slblake@petri-meat.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <16B722F5-61D1-4D8C-A6BA-81C820A17856@gmx.de>
References: <e9da704b-7705-baf9-a82c-39d4fe4e7ef1@erg.abdn.ac.uk> <98c8af7ffd471d6c353006c92c7deb3c28441557.camel@petri-meat.com> <0958b1c7-f4d2-ac7c-c127-b6fefef8f554@bobbriscoe.net> <18b86be43d62ea0a7dc55c760a50818dc68234ef.camel@petri-meat.com> <296c7a3b-15fc-5a30-efc0-cdc27a176db3@bobbriscoe.net> <B5AA611B-93CB-49FE-A57B-8293B4E15650@gmx.de> <d2b3b31e-58e5-1b00-bb84-f65d94c05059@bobbriscoe.net>
To: Bob Briscoe <ietf@bobbriscoe.net>
X-Mailer: Apple Mail (2.3445.104.17)
X-Provags-ID: V03:K1:xq6JszxrBVrUeDglNrHyrTUNYPNqiQRS9SwCFIo08qJH9GB3S7R JjvPoSYRAxXrdmPaSDhoXN++7a/nOHno6L5G/1yuMeI35UHsy3Hu8TKkGTfiAJ0R5TVpye5 wMdtBC+69adP+SXt4vIfWhKEUPMRruWMFJuZc6BqEe7CVBVMivV7H7LB9NWGyNE49c04eCq D+ugj0m/EuZrY5zwA4iPw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:P9yMrDZKYcE=:V9qPW47l4+eFw6JJ8VY/0u ttXDLfB/rbjV9Cl8M+YutTj0KXjlUgZuhNgQFa1Ah/0KOm4TSNIsjED8pHcu9WrbIBZlmarz7 2nm+B48l/HOunFWA9NZn0maEU7OZuUEFncY88jOp4+ywOVn8pdP3nZgDtM4Bq836a1TWcO8sr AMBqQEbJOyJVc1MlkiezEfnOoprALcGgvKjoV474oO9w4OflZh18PwCNApG+gkQABJbl64v24 1a8fiT1IpCJGhwl8HlhWAMWlis2vZ9bnZv4zn63Zy6qnU1/GMi/xwzd5/n/5iifsxkj7xX5a0 NOLJvYJLIYoqdro/ka5Adw+YkuzUV/n7P37l7tQBsesjkxg5pcuFebr6iJZ7zJ9yzeGpcg/Im kD4AEbJWyn8j5npKdIVvQxKcrQJfJIbDCWD/1OTRylSn3nwEJ35HcDMt5lxgr6oOgidJgNBzR VHA/62olBo6WB+rwI557blNMzdZCz2LX5mB1BYwrgtis5P6/bOqPiJrX/EVt/oAFAC04p7+XD /Vv375dDfROlkr6T7tj2zMYfNrsxvYaERSj4DRB6K8mokWlYrdLtRapMRO1m1Wz2i5j4xWpNk m6Mv6lF09pGK1cDDAcRuwelRexYpZ9Uc+x1TbzPTdsii/rbQHWpqgPk/PQA2LLaOEWRM7lFSD 5g4OC1qIzZjB1Ig6Jep3vHTy+ztDIegbmbOSLulXJH8lj8ZPpWPASb3eWu72eNySHZac0+TdO vEoi3N0FI95N2HqZmLqKSbmzdWctzIfXMSCy0YRpbUmpZMh+VIhlMrrvTA8iJvcmc/pbSQkmu uChB7AupLZOcI9skEIO7L9wT9KbcP3kkqtY8SYeoLT1p9KG0246+b/w/T6FV9QeUwx/RzHS1/ e5YTAzNtKBDVjdTdI+jByXYfkAtRx31bNeezojtMajx2VwLzT8sh+fKwS1FvYOH3BpKV9A+RV +hXVBqRCLGgL4CGB13DgfCFPfmMtczIYm/eaHuqElilCB1lpik8YE+Ai2+FJnL5e6H68qKVXX GujZxRD1L66QLmZCZO+WblVUPdY7ioabOCnIWVhI4AXe6GPGb8lZYUp4wPg49ujBMEDONrnEl LyQNLnBdn1GznU2ATM15zw5AkQWA+ZpvO2dQQ7SNxsaCW6NS5QmL9yHiSY74tbvBzu92NC8vs 2z36x5JBoxLkTuTl1Apyhv3cYTzGbIUzgPg+tLDO7HM4WhD1vfBPHXRI4UszaCNFIgOVY=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/JUP4qzB9DAq6NpelG9BI3-Iiljc>
Subject: Re: [tsvwg] Adoption call for draft-white-tsvwg-l4sops - to conclude 24th March 2021
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, 26 Mar 2021 09:25:32 -0000

Hi Bob,

did not see this yesterday, so my belated response, prefixed [SM2]



> On Mar 25, 2021, at 13:19, Bob Briscoe <ietf@bobbriscoe.net> wrote:
> 
> Sebastian,
> 
> On 25/03/2021 09:40, Sebastian Moeller wrote:
>> Hi Bob,
>> 
>> 
>>> On Mar 25, 2021, at 10:26, Bob Briscoe <ietf@bobbriscoe.net> wrote:
>>> 
>>> Steven,
>>> 
>>> On 24/03/2021 23:12, Steven Blake wrote:
>>>> On Wed, 2021-03-24 at 22:50 +0000, Bob Briscoe wrote:
>>>>> Steven,
>>>>> 
>>>>> 
>>>>> On 23/03/2021 00:56, Steven Blake wrote:
>>>>>> Sec. 4 (Operator of a Network) of the draft presumes that deployed
>>>>>> equipment is capable to classifying packets specifically on ECT(1).
>>>>>> Have the authors confirmed that this feature is available on
>>>>>> commonly
>>>>>> deployed operator gear (e.g., IOS-XR, JUNOS)?
>>>>> [BB]
>>>>> (Aside: I think you're reading an old (-01) draft. That section has
>>>>> been
>>>>> Sec. 5. since draft-02 on 22 Feb 2021.
>>>>> See my response to the initial adoption call about the probable cause
>>>>> of
>>>>> this confusion - suspected problems with the IETF tools servers.
>>>>> )
>>>> Oops! You're right. s/Sec. 4/Sec. 5.
>>>> 
>>>> 
>>>>> To your point, I checked the manuals of one or two OSs of common
>>>>> makes
>>>>> of router before I proposed the WRED technique for addition to the
>>>>> draft. And I discussed the hardware capabilities with people within
>>>>> one
>>>>> or two router vendors. In the cases I checked, the CLI limits the
>>>>> flexibility that the admin has to define classifiers as general bit
>>>>> patterns. However the hardware underneath does have that flexibility.
>>>>> So
>>>>> this would require a CLI update for the routers I checked. The Linux
>>>>> classifier architecture does provide sufficient flexibility for such
>>>>> a
>>>>> classifier.
>>>>> 
>>>>> I also suggested the ECT(1) tunnel bypass technique, but I didn't
>>>>> exhaustively check the manuals of all the different types of tunnel
>>>>> (there are dozens).
>>>>> 
>>>>> I think this list of techniques is most useful for router
>>>>> developers,
>>>>> who can then find the easiest and most efficient one for their
>>>>> particular kit; whether they have to update the CLI, or whether they
>>>>> can
>>>>> find a way for their users to configure their unmodified systems in
>>>>> the
>>>>> field.
>>>> So operators that *don't wish to participate in L4S experiments* may
>>>> need to update *their* deployed software? Ask your favorite router
>>>> vendor how many customer-specific releases they are maintaining because
>>>> customers don't want to move forward once they get a working validated
>>>> release.
>>> [BB] There is a common belief that, if any RFC3168 FIFO AQMs exist, they will be rare. But Jake and Jonathan raised the concern that it still needs to be possible to deploy RFC3168 routers from now onwards. In that case, operators that *don't wish to participate* would be updating their config, and l4sops then gives router developers ideas for how they might be able to prevent an existing implementation of RFC3168 from acting on ECT(1), given an ECN implementation is likely to be hard-coded against the ECN codepoints.
>> 
>> 	[SM] This asks the question, how would an operator that is about to enable an rfc3168 AQM know that he better read and follow the L4S-ops ID/RFC? Are we expecting all operators to read and follow all RFCs meticulously all the time?
>> 	IMHO an operator intending on employing an rfc3168 AQM might read RFC3168 and RFCs referenced from there (which is IMHO already less likely), while an operator interested in L4S might read all of the L4S IDs/RFCs. But here we would need the rfc3168 deploying operators to read and follow an L4S ID/RFC...
>> 	I guess adding an updated by to rfc3168 pointing to the L4S-ops RFC might offer a solution, but can/should a informational RFC update a PS document (honest question, I am just not sure about whether our process permits that)?
> 
> [BB] An EXP can only update a PS in exceptional circumstances - called a downref.

	[SM2] Thanks I appreciate this process related information a lot. I am not hung up on the exact placement of a reference, as long as the intended audience will stumble upon it without having to do much reasearch, because that reasearch is not guaranteed to be invested.


> The only clue will be that RFC8311 updates RFC3168 to say that ECT(1) is available for experiments,

	[SM2] That is too subtle a clue for anybody wanting to deploy rfc3168 AQMs in their domain, I think...


> and then the IANA assignment for ECT(1) should eventually point to ecn-l4s-id (and RFC8311 already references ecn-l4s-id). There has been talk of a further update to RFC3168 (or RFC8311) to formally deprecate RFC3168 AQMs marking ECT(1) packets.

	[SM2] Which might only happen after the L4S experiment concludes successfully I would say; but the remedies/work-arounds of the L4S-ops draft seem to be important even while the experiment proceeds (unless we can make sure that the L4S experiment is inherently safe, e.g. by using a guard DSCP, in that case it suffices if networks actively participating in the L4S experiment read and heed the L4S-ops draft.). I do have my doubts about the effectiveness of requiring non-participating parties to change their ways, but if we as a WG beliefe this to be the way, I just want to make sure that connecting the relevant parties with the L4S-ops draft is as explicit and visible as possible (while still respecting IEF process). What I want to avoid is a situation like Douglas Adams described:

"“But the plans were on display…”
“On display? I eventually had to go down to the cellar to find them.”
“That’s the display department.”
“With a flashlight.”
“Ah, well, the lights had probably gone.”
“So had the stairs.”
“But look, you found the notice, didn’t you?”
“Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.”"


> 
> 
> I think you're imagining that the world should be easy to follow for companies that don't put effort into following the world.

	[SM2] No, I envision a world where IFF rules and regulations get changed, a realistic effort is made to inform potentially affected parties of those changes. And here we already stipulate that someone is looking at rfc3168 already, so doing their due dilligence, IMHO.


> In practice, companies pay staff or consultants to brief them on what's going on in standards. And there are plenty of people in any networking company who will follow what's going on sufficiently to have an idea where to look. 

	[SM2] If that works great! But as I said, when made decisions regarding the default use of ECN in sqm-scripts (affecting all SQM users not actively changing the defaults), I did not go on an extended RFC reading session before (I had read rfc3168 before, but simply assumed ECN to be deployable as is). Yes, that was my sub-optimal action, not one of a bigger layer, but I think this still anecdotally illustrates how important it is to make these things as visible as possible.


> Nonetheless, you are right to be concerned, because many companies do a very poor job of tracking RFC updates, not helped by all the outdated tutorials on the web. That's why s**t happens.

	[SM2] Realistically, changing an existing RFC post-hoc, forces an outreach effort on the party changing the RFC, not because that is fair or just, but simply because they are the only ones that really know...


> 
> For instance, try an image search for "IPv4 header" and nearly every highly ranked image still show the ToS field. Even the Wikipedia page about the IPv6 header still says it has a traffic class field, despite RFC3260 being 19 years old.

	[SM] Good example. It supports my point above that outreach is necessary, as a change in an RFC != change in behavior of deployed instances based on that RFC...


> 
> Nonetheless, your own efforts to create controversy around L4S have greatly helped to raise its profile in this respect :)

	[SM2] I would not call it "creat[ing] controversy", but rather "emphasizing short-comings and pointing out where improvements seem advised".

Regards
	Sebastian


> 
> 
> Bob
> 
>> 
>> Best Regards
>> 	Sebastian
>> 
>> P.S.: This is basically the same issue I have with the only mildly related NQB ID: in both contexts, we seem to expect parties genuinely not interested in the topic of the ID to act in a specific way to accommodate either the NQB or the L4S IDs/RFCs. And in both cases arguably bad things happen if those parties do not follow the recommendations.
>> 
>> 
>>> 
>>> 
>>> Bob
>>> 
>>>> 
>>>> Regards,
>>>> 
>>>> // Steve
>>>> 
>>>> 
>>>> 
>>>> 
>>> -- 
>>> ________________________________________________________________
>>> Bob Briscoe                               http://bobbriscoe.net/
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
>