Re: [tsvwg] L4S drafts: Next Steps

Gorry Fairhurst <> Sat, 20 March 2021 15:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 34B323A24BE for <>; Sat, 20 Mar 2021 08:14:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eKkNbxG4o5-k for <>; Sat, 20 Mar 2021 08:14:05 -0700 (PDT)
Received: from ( [IPv6:2001:630:42:150::2]) by (Postfix) with ESMTP id BC4F23A24BD for <>; Sat, 20 Mar 2021 08:14:05 -0700 (PDT)
Received: from GF-MBP-2.lan ( []) by (Postfix) with ESMTPSA id DF3891B003B1; Sat, 20 Mar 2021 15:13:58 +0000 (GMT)
To: "Livingood, Jason" <>, Jonathan Morton <>
Cc: "" <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Gorry Fairhurst <>
Message-ID: <>
Date: Sat, 20 Mar 2021 15:13:58 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.8.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
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 15:14:07 -0000

On 20/03/2021 15: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). 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. 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


Thanks for writing this so clearly!

This sounds like what I was expecting. The labs tests have been useful, 
but the next proposed steps are the deployment experiment, which as far 
as I can see what has driven the development of these drafts in the 
working group.