Re: [tsvwg] L4S drafts: Next Steps

Sebastian Moeller <> Sat, 20 March 2021 16:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 32FBE3A25CE; Sat, 20 Mar 2021 09:22:10 -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 cArCpRaSgsD5; Sat, 20 Mar 2021 09:22:09 -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 7FF263A25D3; Sat, 20 Mar 2021 09:22:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1616257320; bh=mI42Jn//+ztjggJ9fJFIt+TST137Lb/fFW0ioqrdIk0=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=Pgc0X4PxqU3JvVOE0AaNzUvKMU6qdIp2LyBr9X0ZiNg4L2YU1Vbf5pc4Qws/7zEFf Mn7vH/5bC0GZLYdH1ZQ1lavVlNAbFyhjluL8HYXDd/Y+/f2ZuXegMcEhOLFTJt+4bB v5XGtaOyEzOgSIxhHGMtwKmOdyVAyPV3vbvdX78E=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by (mrgmx104 []) with ESMTPSA (Nemesis) id 1MaJ81-1l9gH43zRF-00WAsm; Sat, 20 Mar 2021 17:22:00 +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: Sat, 20 Mar 2021 17:21:57 +0100
Cc: Jonathan Morton <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: "Livingood, Jason" <>
X-Mailer: Apple Mail (2.3445.104.17)
X-Provags-ID: V03:K1:mwckWEkVHRcUDyNv8NSzMoar5A4PKDO2wmOrit6OCDvwsiUKOhD fAu3t2QxTn0QdhU9xpGh9awsPI2NZrD0D+DHhsJDHgfLJPXN0kBH/gWF0f7jS0t9EPUQ88w 6/MSA6Vm4AXmv1Y5Nc8OvtqffiIyFpHICxNr02vns/FkTs1swVAkZsU5RrZUcLZi/zzxl0C 4aTfxOZ6HCrQYpP6D+Wig==
X-UI-Out-Filterresults: notjunk:1;V03:K0:wvtV4bztk2Y=:M9FilL6Tgh2hs3zgCAuJ9t CHF6/XDCebCRVKujEehm22E9FtnmJqEDsTTqA8/bCyOjp4nf9jAcNXJ1frw6Nwce4xCoE9F5w Ol6c9zPeyTBTc4kjlLjCvClsX8VLWZ7ZUNCp9Hr4SKvumNXiLLo1nBpDDWI35ei7Ci0cqnexT 7K+v+H6V7lmO6NywZsnlqPq8i1gLwJk2DK7nHFC5B3Pcq4Ut8a2548WtomrODmfB6NP790/4j k9ezKPDSivprr8X+QCzjiA2Lpc5lFMpEjEq1QkVmGmXM/AwtQCd6hevOWs0HuI7FL1NdqlApR bFF1ZcZdh54i9URRr9CQmZW1qfm95r99i+gF7rXLe8XMrnMDL9n7y9rJmTgEMyYIzhkANb7Nq 9NX45pI9tGNWR8tAakzDGI8a+IMF1YjEJs9elCisHl7nDY6v96xPP8cVOnZdHzjFozKKwrnS0 Myyw6KFOKJJkahGcMg0K+oUIh4nov/5EWXfuZd0sipWi9rrAA1UZr+nSvyGQYGeTFwkwFU2Hr CJeO/4bRnj310ms56Floo8naLZkVYosuxvlp/rrXxHnwI8IxksUaYACewmAUqfugqhq3RhuZK mFhzu24pgd5RLD7MPa+Iq+8xYoiXiHwS68xYva10IY2mHVTVpopjBC1SkoJ+UfosdlzUyPIcd XSUFZDRsWSudghZQCRZ/n8SbW5RWW0xc1zxzWnOTJkZf2mFd69814ktWIknY8HacV5GqxkdS0 sfdShAXYciaEFIDwEKIUkzSnJQjWTwtLRCyFpCD0fZeTpuqEumaZoFJbT4l0aHgnVWydZ6bSF 54ifC1ai+szbDlNOu9+gEVoCHKekOLPL2jDPUVPVCOZIHXao7xXYlX2vxSFhRVbw8v3JsEqbO msVLwcpa/3ib6swNyFPg==
Archived-At: <>
Subject: Re: [tsvwg] L4S drafts: Next Steps
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: Sat, 20 Mar 2021 16:22:10 -0000

Hi Jason,

> On Mar 20, 2021, at 16:08, Livingood, Jason <> wrote:
>> The lab studies have shown
> IMO the challenge with lab studies is that there are a lot of variables that are artificial and/or the test environment or test traffic does not fully reflect reality (production).

	[SM] Nobody hindered team L4S to actually vary those parameters.

> 10 or 15 years ago I would have been very focused on extensive QA testing and an elaborate lab test environment. These days its more how to do controlled testing directly in the production network, with a controlled/minimized blast radius in case of problems, easy/quick rollback, rapid code/config iteration.

	[SM] Controlled testing over real networks is actually possible already, without the IETF's blessing, as long as one makes sure the potential fall-out is restricted to voluntarily participating nodes. To claim there is nothing between tests in the lab and "release the kraken" onto the whole internet, does not strike my as aterribly nuanced nor realistic position?

>> far from a promising system that might be ready for a field trial, one that shows worrying failure modes that primarily affect innocent bystanders.
>> What we're asking for is a system that at least behaves reasonably under lab conditions, chosen to represent realistic challenge scenarios likely to occur in the real world.  Only then can we have any confidence that L4S will not cause problems anywhere and everywhere that it is deployed.
> Only one way to find out - test it in a real production experiment with appropriate risk controls.

	[SM] Like a guarding DSCP that makes sure the fall-out is restricted mainly to willingly cooperaring parties? Such common-sense safeguard have been summarily rejected by team L4S... In other words there will be no risk controls, let alone appropriate ones. I come to this conclusion as extrapolation of L4S lab test trajectory. Why do you assume the approach towards safety and functionality engineering is going to change?

> The status quo seems to suggest years more debate without (IMO) sufficient data.

	[SM] So all I need t do to get an incomplete draft to RFC status is to drag my feet? Surely that can not be your serious position?

> An alternative is a controlled production experiment, appropriately risk-managed, between willing participants.

	[SM] +1, but that is not what is under discussion here. We are talking about "release the kraken" based on theoretical considerations, that L4S will work and there will be no incentive to exploit its known failure modes. Engineering by "hope and prayers"...

> I see no downside to allowing that to occur via experimental RFC. We're setting the bar at the proposed standard or standard level, which I think is incorrect. I would say instead enable the experiment to accelerate the learning & improvement & drive data-driven decisions.

	[SM] Again, for a "a controlled production experiment" no buy in of the IETF is required, it never has. So why pretend otherwise?


P.S.: I missed the last meeting, so if team L4S actually presented data that answers all my questions, I am willing to eat my hat, so did they?

> Jason