Re: [tsvwg] path forward on L4S issue #16

Sebastian Moeller <> Tue, 09 June 2020 19:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F23363A0D5A for <>; Tue, 9 Jun 2020 12:42:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Status: No, score=-1.649 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_H2=-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 iSywvUwjkz9H for <>; Tue, 9 Jun 2020 12:41: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 12E523A0F5B for <>; Tue, 9 Jun 2020 12:41:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1591731688; bh=isvPhV6XKcwmZfSb418IlSaGarSJ1GjZiF9MEtaCcWw=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=GI4nLIPWtgpDXY/2VENfbZTgKzhj9UQDGjOgUXLbxwIJXQ3/LHnLVmPX9+UWdCf6g VK+ryG9rwN59S6s3Xtyrp/5FZmqkB5dZucnlGvYZ25h8jQBdTRMdlnGdS8zUrXWjho S+P37UdksYQgFVhaJnVHzLdTl+S2k6bOt030diLU=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by (mrgmx105 []) with ESMTPSA (Nemesis) id 1MaJ3t-1jU4qr1ruP-00WCsc; Tue, 09 Jun 2020 21:41:28 +0200
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
From: Sebastian Moeller <>
In-Reply-To: <>
Date: Tue, 9 Jun 2020 21:41:27 +0200
Cc: Jonathan Morton <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <>
To: Ingemar Johansson S <>
X-Mailer: Apple Mail (2.3445.104.14)
X-Provags-ID: V03:K1:kHPLAieHVb1UWuWpmFEoynC8JUXgjLo5W7pixnKyJflO3isC1cd MrvLTvgzKuXRyh4XzJJFfW8IUbeNw/bbkKIoDR8BzQAiuDqeoxpglEsuFV9i+QWTwG6uep7 UDS/EjIzDWMa2ygV7vzG+h05/4j02axuXVIE+bLzyAHg6CPLedqg3vOu1xBRGrAdpayG2zf Toj3wye6+KIbuBY/6pm9w==
X-UI-Out-Filterresults: notjunk:1;V03:K0:nZj4vIe9AmA=:TnO8li8jABRZTt4fOMRuGF uXYWpjS38iJatw5jrAbSYFGxtev1F/rUwfc2XGpOAW4v/lP+ZugigUFmvGN76psNcgbq9Miw9 eRIYK0lk48asiO/kQH8KUXmfx1yqC5dUEqjyoOoEZn3gHpk+psZcf/BpJapqkZhbTPGPR+uLL DuGpJq5iOcO4avIJeBkmc2EGOAffHm4TFv3TlRR2eMWvvy1HFKceLF7wEx/lLg+msDFVYdnHQ 7fOWVbboAjCogkuOO/6Cwoa+ZO0oCDgXpVinPtBkChB7ErKQBs+BUur69zdEZWj6IDEHV2RRn RAOFe+rm6TOS1N4lcqqPR1A716NtMWfNuwtUxksu/78QCYMJQWnfkRLj5NLecDF+w1Y9onl58 8gz7XeqI3W7oULL2LQD5VUO4rll7qVpeeW3enP/0xzNTYOrwObWwSGnI0iy7QkaXR1JzC/nyT 6Tjk7JnXijPvm09DzMwNtShOqWbp4Bn8PTPqeFdkEekfb030YPi+ZJjRcExeLS59j3jLDHJpM xxxSWYSTFhcEoTUQioHStqmWqFVOxT9z0KTL7Ps4gMkrgDtNICNWjrPWDXcEgJTbiVrherEax V0z7Ap9e1HxSfktM2CASx9pomLjbK7EYGJxImxRlGTrK5PSQuR7pVflrhQh+SdQwhwtrTJo6y y6OIzjwRT/fOvMRZUqt3vkoQDKVropj4hVfGvwxxu40mHyGpcFF0ADbEePuQZOXtEwlOSfKO5 SvbyDYpPUrjzADWQa0PZr5wO5LSuS9w3QrRPiLZfVFVBTSdLc7VkCAO2jIxo3qMqKQNsmsH4g b5z5TtSixlHKuM9gbciegRJ508eyDBLQ7qrfXeX0/LmV/i8caFZb0D9PHcNilvGr6uuQPVBAS yoeh3S01udKbS/5WIl+F0VFK143W9h3/R+xUZ/a+GGq8qoFyL/9hLfJuw+rmjRIA/unASHpbp zJ1NiVuFjcx1j90Jo0+KAiefNEqXq9sup+PicJWcyCQxotm13/wtvIo0q/rjUxexPQrh28hKX fldeDNMZQZjKP3EXNNuEFi6TOwws24FinaERCddmUb5IFSKuDJEkxQZ7o2tx0mj6BYqU3GIfQ /kFe/CLerSTm1jchWBlTYjHx7bqIcPmiL+uSnIHTWwzbZekzFWOrSJEgqeeaCCJcTelGXG9mx pDUE2XgZ71OxigknUiZTP2DPWrE8wr5ezKpXLby7YoIzS4V72A+O1i3F84OsIX1bY8iQs=
Archived-At: <>
Subject: Re: [tsvwg] path forward on L4S issue #16
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: Tue, 09 Jun 2020 19:42:01 -0000

Hi Ingemar,

> On Jun 9, 2020, at 20:58, Ingemar Johansson S <> wrote:
> Hi
> Just for my understanding, do you seek evidence that L4S can be safely
> deployed before the experiment actually starts or is the collection of
> evidence a part of the experiment?

	[SM] That depends on what you mean with experiment. Yes, I want to see that data BEFORE L4S is awarded IETF RFC status above informational... As far as I understood Gory, the intended experiment for granting L4S experimental RFCs (first) is how to roll-out L4S safely. IMHO describing the intended behaviour for the few scenarios I outlined and then demonstrating that the actual implementation meets those goals, should be an uncontentious "conditio sine qua non", but as this whole process demonstrates this does not seem to be the consensus position.

> To take 3GPP networks as an example. I don't expect that initial experiments
> will run across the entire internet. And as this experiment carries on I see
> a likelihood that RFC3168 ECN capable AQM where they may be will/can be
> upgraded to support L4S as well ? Meanwhile one will learn things from the
> experiments and will be able to refine congestion control algorithms. Does
> it sound all too unrealistic?

	[SM] No, that sounds fine, but you do not need IETF approval for such localized experiments to begin with, it is really the "across the entire internet" part in the L4S RFCs that makes it IMHO a prerequisite to demonsatrate sufficient safety before roll-out. I note that none of the conditions I outline could not be easily tested in a more or less private experiment still spanning the width of the internet, just set-up three test nodes, say, one in Frankfurt, one in Atlanta and one in Tokyo each with an L4S AQM and go wild with testing traffic between them, no RFC required for that. 
	But here we are, working hard to get IETF approval for L4S even before it is clear that L4S can actually deliver its promises under normal internet conditions. 

> This boils down to the two questions that I had in another thread.
> 1) How widely are  RFC3168 ECN capable AQMs deployed _and_ enabled ?
> 2) If they are deployed _and_ enabled, can/will they be updated ?

	[SM] Just looking at the IPv4/6 "transition" the answer to the second question is, "yes" and "with glacial speed". I can understand the desire for the existing internet to follow one's own idea of optimality, but realistically the existing internet has a lot of momentum and and thing that requires a flag day, pretty much is doomed (unless as clearly beneficial to everybody as the introduction of congestion handling, but L4S' gains are rather modest in comparison).

 Best Regards

> /Ingemar
>> -----Original Message-----
>> From: Sebastian Moeller <>
>> Sent: den 9 juni 2020 18:25
>> To: Jonathan Morton <>
>> Cc: Ingemar Johansson S <>om>;
>> Subject: Re: [tsvwg] path forward on L4S issue #16
>> Hi Jonathan,
>>> On Jun 9, 2020, at 17:01, Jonathan Morton <>
>> wrote:
>>>> On 9 Jun, 2020, at 5:43 pm, Ingemar Johansson S
>> <> wrote:
>>>> Why don't you run the testing yourself to get the answers you look
> for?.
>>> Because we are looking for cases where SCReAM (and other L4S
>> transports) fail - and we have already found sufficient such cases to
> raise
>> objections.  We don't need to look further.
>>> The burden of proof is now on you (and the rest of the L4S proponents)
> to
>> show that these problems have been overcome.    This will require
>> *changes* to L4S, and testing of an implementation of that changed
>> specification.
>>> Sebastian merely listed a few general scenarios where we know L4S does
>> badly.
>> 	[SM] Well, to be generous, these are important scenarios where we
>> know way too little about L4S' robustness and reliability. The recent
> testing
>> indicates that L4S has ample opportunity to improve its performance/safety
>> under these conditions.
>> 	Now, I have a hard time believing that none of the engineers and
>> companies that opted for L4S did this based purely on the obviously
> overly-
>> optimistic promises in the L4S drafts and the RITE project. So, I would
> really
>> appreciate if data that was acquired in the process of seeing whether L4S
>> was/is fit for roll-out and implementation in silicon (if that actually
> happened
>> at all) could be presented here on the list.
>> Best Regards
>> 	Sebastian
>>> Those are tests which you should run internally as part of your R&D
> cycle,
>> and then present results of, in order to give us confidence that L4S can
> safely
>> be deployed.
>> 	[SM] +1.
>> Sebastian
>>> - Jonathan Morton