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

Sebastian Moeller <> Thu, 25 March 2021 13:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F3CB3A20F0 for <>; Thu, 25 Mar 2021 06:21:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.648
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bnT-UKe48O5Q for <>; Thu, 25 Mar 2021 06:20:59 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 480AE3A20E0 for <>; Thu, 25 Mar 2021 06:20:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1616678411; bh=3PVyR77Tfxw0iBJW+h5ws1axOYxBJV2v2NbRCw3hpHI=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=cXJ72zT9hT08jEpTD0Ok+LsDw2GlwYYYkMR2UUHx0WZsjXbBBBbU0heBDbBKBmhix BVA7J5J8kSjEeE92HBARg/RNOgoQIwpVPvc5b4SoXH+VDsGVxwrMfHCt9A0Ny8MNai ytwbN+fVB9zKeeTpU7MqDEn62OrFYg0gZkPePMNo=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by (mrgmx104 []) with ESMTPSA (Nemesis) id 1MhU9j-1luv2e20hv-00ef8h; Thu, 25 Mar 2021 14:20:11 +0100
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Sebastian Moeller <>
In-Reply-To: <>
Date: Thu, 25 Mar 2021 14:20:09 +0100
Cc: Bob Briscoe <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <>
To: Ingemar Johansson S <>
X-Mailer: Apple Mail (2.3445.104.17)
X-Provags-ID: V03:K1:FlAYXswmhtLqlUTVONavptsw8jnmLKLoC5wpJSszGWP5oFp/LN0 Oo5eKBuBUhXJZIQTE3e0T4NId9tY91zV6e2yqNKWfVRWZ1XC7w1jrxVs/67G/RToI4xa0Xd 4ryBjbe2kQQ73ZVH3tFhtaxukqT9V2b3yN5VeSlXhhgbN5O2lYj3vMB2S5Zg+MSlemU+yvk /5OS1w7XoM3ULOfclnIJw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:nvjGeAAxSG4=:oyxONGQ418TAv+K1e4R8jD l28SGpJT1FiC+HeainJYkWmfaGsqoEcSMx3SP5fPCCOKlPKcwFukhHhlPPEc9TJLDfwsFSNzB os1PFC2AaCEGnsXNvMUif3kWfhB2O2ivT5xydzOUe8JtFmlHQ4NhzzyvEi+PuOG2AXXF/uE0I qvKCzzHCf3VD2qI0o85Z/wjhfh24UhPAD5JzZE2mfDUej4qLLhKDcpgUD45HyHZZ4a3CJVLo0 0TLMkHt+yvp3ABvqt/y4GcLv24nPGfA1C9Om4f1hb1cgVjYlvSYwJlbLgxMGI0hIVHEEh8tkI C9HaxCNqRyc3pe3VmImQgm5i0Oy/r8XqlUQOmgfEjgSMXHEd9vCf1M14xLfFQqjH46ueSOqRO EBKt7EFW+4UJHooOcNfLyiS4Q4x6AmAjDDYYusbNNKJ8ZYtAefN2QONIG/y/6QsiydJwxA16D +Ywy34tLO3ia35neVDLaoZoo//O+fczOEPHr6+COhXUuyW/pJODYw9WCiTjwnX5PwP0iBj2oN i7I9RwMCszJQyo6/yL+dmFaYc3q2cQ6NB6YukxNgokNSyzZgfCU2g272MQUSD5Z9ne/GlKK5i P7XK/f8pXrRyC7rHqMN7BxlTUKMEtRHemcK7rHvw3ardnlFnL01YVxYs8YLBxDAz6OJxppkiI LBIHq1SPCwKri+48aRdkrZ4/OW3FaMiwWJWyZBf0G7FOyWeornDspiMIs+HLgL6hVmp4tFasY n775WNzfx+DxO5N6Wjl0szDyWC4BX3WQ+HafJSLh5QMBaD1aBW1BanU9EdkxUN1ZRTFy+ciOX AOsgjDR6oE97ev18OQGRoC2Jsc5FDJvYfAW3uiza4nW3QTWjo3RmTn2fdNJ+/NoRwou1xj9uu Cssnn6Nj2fVLbYNXS4LmCwJzx2odxYa8GYnRbjlk+RF8D7eHJqNacFntcEIQjliTi0d3JZDx5 VQMy5Yvoi2kcE9Wdhw9xCmGrIFvibEPwwVPyEnBNX3+DDmr2lb19em7RHWzWZG4yMCU3c5SIG MTUFYbq6IftTL5uA3a8mLBuirMDNXuvLrFDgqvxXHAjVB4Q58k1Sy5Q7BR/ZsZ7UWVEFm3/Ha flay/0gFChYZmicz1pay1/kIp7Y5fvjHvX3iKptdp8wCniNoXMljChtdw+aS65NWbQKF+v/xQ bt6mtr5p41rziLs1HSFfPwX5l9z8qI2/2qWGNaiqbn3Nobw+skP6WfA1+zcwCQp6/djDc=
Archived-At: <>
Subject: Re: [tsvwg] Adoption call for draft-white-tsvwg-l4sops - to conclude 24th March 2021
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Mar 2021 13:21:04 -0000

Hi Ingemar,

> On Mar 25, 2021, at 14:08, Ingemar Johansson S <> wrote:
> Hi
> One reflection around all this is that it really does not matter how many
> warning signs you put, information may still not reach the intended
> audience. 

	[SM] While potentially true, not really an actionable position to take... We can expect that parties interested in participating n the L4S experiment actually read the relevant L4S RFCs, but if we require others to also change their behavior/configurations/expectations we should take active steps to reach these parties, even if we can not guarantee to reach them all. In short we need to make a good faith effort. At least that is what common sense tells me, is there any relevant RFC instructing us to do otherwise?

> I guess there must be an abundance of cases with other IETF work that does
> not reach the audience, sometimes with suboptimal performance as a result.

	[SM] We are actively contemplating of releasing protocols into the wide internet that run roughshod over rfc3168 and the expected sharing-between-flows properties of deployed AQM. Are you really advocating that we just do what pleases our whims right now, just because doing so is more convenient to us? I am puzzled, truly puzzled.

> And I don't find it too productive to dump a lot of informational text in
> RFC8311 around what can possibly go wrong, especially as it is not fully
> clear how serious these problems really are.

	[SM] Fair enough, that is why I proposed to direct readers of rfc3168 to the L4S ops ID and leaving out the redirection via rfc8311. The point is, if we are going to encourage/permit end-points to behave in a way that violates the assumptions made by operators of rfc3168 AQMs the onus is on us to at least inform them about the fact, and what remedies we came up with.

> Only way forward I see is to
> move on with the L4S experiment and document possible issues as they come.
> The L4S ops draft provide good initial input here and it will likely be
> complemented with more best current practice.

	[SM] Expect my, "I am running roughshod over L4S" ID any time soon, if all I need to do is to document issues... @chairs is this the official position of this WG and of the wider IETF, how to handle such conflicts of interest? I would be amazed if it would be...

Best Regards

P.S.: I really tried to keep this focussed on how best to get the relevant information into the hands of potentially affected AQM operators; yet it turned again into a side-show about differences in opinion on how safe and sound engineering should be performed. 

> /Ingemar
>> -----Original Message-----
>> From: Sebastian Moeller <>
>> Sent: den 25 mars 2021 12:45
>> To: Ingemar Johansson S <>
>> Cc: Bob Briscoe <>;
>> Subject: Re: [tsvwg] Adoption call for draft-white-tsvwg-l4sops - to
> conclude
>> 24th March 2021
>> Hi Ingemar,
>> thanks for responding.
>>> On Mar 25, 2021, at 12:35, Ingemar Johansson S
>> <> wrote:
>>> Sebastian..
>>> Isn't the updated by RFC8311 sufficient in RFC3168 ?. It refers to L4S
>>> work, namely the L4S ID which targets experimental standards status.
>> 	[SM] IMHO not really, rfc8311 has no big warning signs, that those
>> experimental standards are allowed/expected to carry negative side-effects
>> for rfc3168-compliant AQMs and operators of rfc3168 AQM need to employ
>> specific steps to ensure safety/functionality of their AQM to accommodate
>> such experimental standards traffic.
>> 	I am not trying to start a discussion about whether doing that at
> all is
>> a good idea, but how to make sure that information reaches the parties
> that
>> would need to follow those instructions. IMHO the link to rfc8311 does not
>> convey enough urgency for rfc3168 deployers to go digging deeper, but I
>> might be just naive here, not being/working for an operator.
>>> Also, to me it sounds odd to add an
>>> Updated by : [L4S Ops - Informational RFC] to a proposed standard ? ,
>> 	[SM] Same sentiment, that why I asked. The information though
>> seems important. If rfc3168 deployers need to do something extra to
>> guarantee their safety and functionality, because of changes somewhere
>> else, I believe the party responsible for those changes (aka this WG)
> should
>> make sure that even casual reads of rfc3168 know about the additional
> steps
>> we expect them to take.
>> Best Regards
>> 	Sebastian
>>> In any case it is the first time in RFC3168's history that it happens,
>>> unless I missed something.
>>> /Ingemar
>>>> -----Original Message-----
>>>> From: tsvwg <> On Behalf Of Sebastian Moeller
>>>> Sent: den 25 mars 2021 10:40
>>>> To: Bob Briscoe <>
>>>> Cc:
>>>> Subject: Re: [tsvwg] Adoption call for draft-white-tsvwg-l4sops - to
>>> conclude
>>>> 24th March 2021
>>>> Hi Bob,
>>>>> On Mar 25, 2021, at 10:26, Bob Briscoe <> 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)?
>>>> 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
>>>> 86d2114eab2f-53274140f9ce9692&q=1&e=8a9723d1-2c84-4bf6-b7d7-
>>>> b62af3457d9a&