Re: [tsvwg] L4S drafts: Next Steps

Sebastian Moeller <> Mon, 22 March 2021 08:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F09733A0B9B; Mon, 22 Mar 2021 01:54:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.252
X-Spam-Status: No, score=0.252 tagged_above=-999 required=5 tests=[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 chZ1jLM02ZxD; Mon, 22 Mar 2021 01:54:27 -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 3D97A3A0B91; Mon, 22 Mar 2021 01:54:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1616403261; bh=lwvk4N0uIHESe2fxxuwR9icjnRrZBHQhJqunaIpWTtA=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=gPkAvh55AgeG0lWuakpDdeLX1YFTV7JQP2Em44GAx3o7The9DWye/VwsrQeBDU5qL 1T87VcCgkk/bycYVNe7nPfzE3/Mpc8TEju7B2ooLRamcOv3ocxU7lWn8zgw2FP9BTw gBhF/F/DzUBkCFMQ4JhK7R8GvQMF6ekpEr0xvAOY=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by (mrgmx005 []) with ESMTPSA (Nemesis) id 1Mw9UE-1lh2EL29ye-00s8vG; Mon, 22 Mar 2021 09:54:21 +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: Mon, 22 Mar 2021 09:54:19 +0100
Cc: "Livingood, Jason" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Pete Heist <>
X-Mailer: Apple Mail (2.3445.104.17)
X-Provags-ID: V03:K1:InXo/MhefkNb9MKSC7gO3VwgRz3p/1C87G39pvmcj3N/It5Gt/S QSJAeFTMamAGRL2J8f6rtbxJyf0UpRLzAruZVNg8aQFVOOvfZHE7qCVnL+ke4xdJwQ4niQj rG9cT0qDreaxT+0aBz8ksRxGNnjsjuAWRtN8Bk4OjaAhPzcyukCdOcmqldJmU6xYNA/b7Sn i/A0ivShRGwf6AQyYr7pQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:P9e0HTK1dY4=:zFq0mJsx6qDgk5xoj9VSuA 3CyH1mWc0D6a4o1OXeJlqKls/dBMuTNSkv8CbHsIx4UXgZsAOM7Xj/mps84j6T2Eeeoch65jn kaB26Li977f0GKMwGbVd86/Wx6eWjwUIpv5a5vdiOX6pzYufvnjwHigUhd78rXIZdsyS7u7OM sff5Mo7yrpxUo9nJzTD716zLmcSjQwSr8/6/jDU4F45tUdhN7DuLBoXJZbMlHZF1UGfYHUlSs PFnYsUEwrHF+LO9/NLyLi3WloQduFHYu5x44jNb4ONysnWPYDlMkFWVlIFw0595ojwqmTBmup 2UQqBAaSwAOazgNlzKudXAPN9M1iW49tt0BRs4nthYmLuU4VRkoBQATbv2yfoU1KYaqdtduQ9 Bo26nsXOaKDDoIhf3cmrHJoWOB1XekCl+yo6+HChh3LpflA5aTp/FU8rSgTNLbXMS9euY3lm5 1Cgfov6AgB73CYc5Rm2rNHwLFxIp8loYNfJHc09sHJzZxP2z7HdfqoaG2fJP2uMohv27K+qmd Khsp8+UhzBSamDQoJg/gT9b4Goz8tJ55YaEErXEPD8q+klFbtvfZNFhLlNSxT0gj5PKqHVhe9 IMJVxpTAZcTUoIoXNykbtX8LbXRufjYterSn201xmXY7aumge3D95g7dfWfWmAT/eloiS9OCp sUbiQQa5cE7sP6UlRsb3KHMRXNNZVKneMl1Uf2vemrShIEQ7r6j7POyUUtmzhDXrENn8OsHsz zT/A2048pSHVoMt2DxIdVIiy3sXjYWCCXMYhD7wNIbNJaYJtrnNHHP3+T6YQUbeGsdfL3Lo6m 7I96yoMV7tkHhCRLiX76mtBqKgUzedP8QpPALbV1GOZH/ofTB8ox8XJXYjtAWBxuGx8AzwiUd jllg2PQuIZV22Fp6R+eA==
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: Mon, 22 Mar 2021 08:54:32 -0000

Hi Pete, hi List,

speaking of operational issues one could/should employ to make a potential L4S "experiment" safer. I think adding a section about how to guard an L4S experiment with an additional DSCP seems like a good addition to the ops draft. Yes, I understand that the main L4S drafts do not want to go there, but I see no reason why team L4S' reluctance to add this to the main internet drafts should stop the informational ops draft to describe such an approach well enough to give practitioners a pointer how to implement such a guarded deployment quickly.
	This is in addition to the section about what implementers are supposed to do at the end of the experiment for which I proposed/volunteered text already (but have heard exactly nothing back).

Best Regards

> On Mar 22, 2021, at 09:03, Pete Heist <> wrote:
> Hi Jason, one comment below...
> On Sat, 2021-03-20 at 15:08 +0000, 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). 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.
>>> 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.
> Along these lines, there is nothing stopping anyone from using DSCP (as
> an appropriate risk control within participating ASs), to perform
> experiments to reproduce issues that can be demonstrated in the lab.
> Here are a few:
> It would be nice if someone took the time to set up some production
> gear with fq_codel built into it, like routers and/or WiFi access
> points, and test various kinds of real-world traffic, through tunnels
> and not. One could combine traffic to L4S servers within the
> experimental network, along with conventional traffic to anywhere on
> the Internet. That seems like a useful step before starting an
> Internet-wide experiment. Perhaps even better would be to fix what
> safety issues are known so that they can't occur in the first place.
> Regards,
> Pete
>> The status quo seems to suggest years more debate without (IMO)
>> sufficient data. An alternative is a controlled production experiment,
>> appropriately risk-managed, between willing participants. 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.
>> Jason