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

Sebastian Moeller <> Wed, 17 June 2020 18:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1A4EA3A0AD6; Wed, 17 Jun 2020 11:19:47 -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 DTFL4QlGjVOc; Wed, 17 Jun 2020 11:19:45 -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 018F23A0CCF; Wed, 17 Jun 2020 11:19:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1592417964; bh=hHeetcqtwj3fGzxamhrUZkkc34VaUFz/EKm/iR6gBbc=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=Ru2xQ7D65g0TW/Y5TgvPM4mK1eiD4f94CDfhuR3//rThvA7AEg6hZ+rjf3PfsiD8K U8mtXqL1uYhwKBeVmzPXtwYQ0nsxasQw+dScv6fQ4t/DFNhITGQOp/z79Ji+DAtUzk 8w8d9Keq+BZy+xNov5r7HcXQwn4NWiCkUM+qKBJM=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from hms-beagle2.lan ([]) by (mrgmx105 []) with ESMTPSA (Nemesis) id 1MbRfl-1jAd4n1m7V-00buCU; Wed, 17 Jun 2020 20:19:24 +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: Wed, 17 Jun 2020 20:19:23 +0200
Cc: Ingemar Johansson S <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: "Black, David" <>
X-Mailer: Apple Mail (2.3445.104.14)
X-Provags-ID: V03:K1:0KEjCtRisiNnQtXa2B7Ge1hhOUqFYDfwAU2N8lZoLm25HWMNU7p DIygqyw06fp/vf69q+UcnbVBR/kcVJfd/bEeRLQjXsNYgZJBSi7o5LLZu496ESS2eJwonr/ Uquvs3E0j0Wx1o+nJjG4kkFxB8CkiQHsv45ZPPY/jDIGk5EtWY/2l6nOUtl+htdiICPAiVw ifOPbyDjvw1ugiKME59bw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:2nsduYbH6Hg=:M9LYtplV5RJbfUSGUUz3Hb CS3Ul8BbIj9DvVGqg92xEDask9yVO4S3dhafCXqyHRXY3+VnqMUZ+FUaSRVZEPgKEvAJfz5kd zN8KvsSCzEUvj6rgAUFqkPVcCI/wF2zqnAD7ddDm+/KyGVpBmxYRtjIQ9tsd1Ts9D2wI9OGEB l/1Req1koURfdJUkG3lHzCJppee87E589557c8DG8NYb0BlVZGPC/gLViCNUdUvPoj99YS/WL aZOF+E4AsHZMPLQ2vgkalhg/OZrfnLoiVEUPiTUrhC4GRNnbVoyx6oJ/1nKpoffMVaci2iTS8 UGhCgfYQY6AcZFPQdhjFdRj8fOXID12J8mvIsFUmpd6rYurDzZBtJGWTNX+OeQCQFZHrED4uI 6eSmT4ET33RCmwFEULBB+frSw6V2ZMkFXkBou02yGZ3s7n3ZGgJcggyfvTTaJt9xwjA0XUdFi 6+pGyp4OCv8kdOi+hRTxRkte0AP2jj3o9UIpY/dUuCn2wb5s06E1pF8cBv7qb8x3UE2MNzKQg DqevL6TCWJ80Se7+1Q14njhqI58Uhoras+mY317jeEYyHD5XeZ2ydTmB1FvYUI8mLbUJkW/ZB /6ahsug43OHejFn6rg++IiWX6ho/uWciG3kY59/PIYO7w3OD/YZMiGsofaY1qEempVuktzPPv KeNt3uI7cp4YuODyQOmU1jZV1hv1ameLAL7yMnlsfsqchtkvNToc9ftB//WO8o7T8O+83s3wZ GFylfx3dN9UBYLKWM5j6e1UK3yH+MFIOaYjniZuWHuiTgjbhZuMhFaZ1QzFpWmHX0I+3p0uQe rw5e0rcpgGg1rYtgnxW+sAQUzTrYiYOYFfGL3Y+ZdpeXH4sFhG3U4S9XgdPFxjaykIhRg9XvZ QWQXWF38VCIIxsErhuMm1GggTTBj8/t+R8cX3YUdxGy09qhzx/ZTkmxX5LsWWmmEuD105ShyH 64uJNh2udkt/jTPCZKJqYkfrp+iT8/N9HLh+qJY41JcYjWV0tzVueA9YVofGVDMwFl21lyIqb boXd5Babh/s+mxUhMF4ZNowJp+2sBckPrY5wb/TXu5t7lw10bOOrhJXksYbOVVjSXLipHKk/6 H50WSxAW/uhCZlFa1MEyc9ZXT6+553tyabENP5Ddw+WyGp3OsG8ikOQefGw9er9GM9/dTdgky F0HtDCvkb7eJnE0wIg0AdyJZi3zj9b7bERLMHdZv/s6CHnJ9i8gFZMXUFM5VewzCxMTk4=
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: Wed, 17 Jun 2020 18:19:47 -0000

Hi David,

> On Jun 17, 2020, at 19:25, Black, David <> wrote:
> Ingemar,
> [posting as an individual]
>> With that in mind, shouldn't it have been on the table to consider the
>> possible future existence of L4S in the different realizations of fq-codel
>> (and OpenWrt) development?
>> Issue #16 is pretty much a consequence of the above timeline, I see that
>> there was ample time to react but that reaction did not come until 2019 (or
>> late 2018?), was any assessment done as regards to how L4S could coexist
>> with fq-codel before the debate started in TSVWG?.
> The question seems relevant in the other direction - shouldn't L4S have taken coexistence RFC 3168 ECN more seriously in that timeframe?
> To my recollection, the overall L4S approach to this topic in that timeframe is captured by this text that is still in the l4s-id draft (Appendix B):
>      1.  It is quite unusual to experience queuing at more than one
>          bottleneck on the same path (the available capacities have to
>          be identical).

	[SM] Which again is consisten with my hypothesis that L4S was really only ever intended, designed, and tested for a single use-case, short RTT, low hop-count downlink paths from content/CDNs to consumers. In that context the above assessment, while not strictly correct, is a decent fit for the common condition. 
	I have been arguing for some time now, that L4S should be tested for more realistic internet-wide conditions, BEFORE its roll-out is approved by the IETF to demonstrate its fitness for that novel use-case, it was never optimized or even properly tested for. And I am truly puzzled that the L4S camp and all the voices that supported ECT(1) as input just recently keep staying silent about that question.

Best Regards

> Thanks, --David
>> -----Original Message-----
>> From: tsvwg <> On Behalf Of Ingemar Johansson S
>> Sent: Wednesday, June 17, 2020 12:27 PM
>> To: Rodney W. Grimes; Jonathan Morton; Sebastian Moeller
>> Cc: Ingemar Johansson S;
>> Subject: Re: [tsvwg] path forward on L4S issue #16
>> Hi
>> OK, I see that this discussion is only going in circles, nearly giving up on
>> this.
>> So far I see only one firm evidence that RFC3168 AQMs are deployed and
>> enabled and these are related to the OpenWrt project, manifested in a few
>> upgradeable devices (and some not upgradeable) that can be bought in retail
>> stores. The rest is unconfirmed.
>> This leads me to a look at the time line for L4S and how it correlates with
>> the fq-codel work and as a consequence the OpenWrt project.
>> 1) L4S was first brought up late 2013-early 2014 in TSVWG. The ECN
>> experimentation draft (now RFC8311) was a draft -00 in sept 2016 and I know
>> that this draft was preceeded by a discussion in TSVWG before that
>> 2) The FQ-codel work was finalized early 2016, not quite a perfect overlap
>> with the 00 version of the ECN experimentation work but definitely an
>> overlap with the preceeding L4S and dualQ discussions and references to the
>> RITE project which happened around 2014-2015.
>> With that in mind, shouldn't it have been on the table to consider the
>> possible future existence of L4S in the different realizations of fq-codel
>> (and OpenWrt) development?
>> Issue #16 is pretty much a consequence of the above timeline, I see that
>> there was ample time to react but that reaction did not come until 2019 (or
>> late 2018?), was any assessment done as regards to how L4S could coexist
>> with fq-codel before the debate started in TSVWG?.
>> /Ingemar
>>> -----Original Message-----
>>> From: Rodney W. Grimes <>
>>> Sent: den 17 juni 2020 16:19
>>> To: Jonathan Morton <>
>>> Cc: Ingemar Johansson S <>om>; Ingemar
>>> Johansson S <>rg>;
>>> Subject: Re: [tsvwg] path forward on L4S issue #16
>>>>> On 17 Jun, 2020, at 4:20 pm, Ingemar Johansson S
>>> <> wrote:
>>>>> Given all the input sofar my impression is that It is difficult to say
>> how
>>> serious issue 16 really is.
>>>>> Surely there is a possibility that L4S flows can get an potentially
>> unfair
>>> advantage over a congested node that is  RFC3168 capable (and ECN
>>> enabled). The question is here when things are deemed as unfair and when
>>> starvation is a fact, opinions differ.
>>>>> Another question is to how large extent there will be legacy RFC3168
>> ECN
>>> capable (and ECN enabled ) bottlenecks that will "never" be updated or
>>> replaced. This question is currently difficult to answer.
>>>> When questions such as these are "difficult to answer", the correct
>> design
>>> choice is to assume pessimistically, unless and until the question can be
>>> answered more definitively.  Therefore, the L4S design must account for
>> the
>>> possibility of RFC-3168 AQMs in the network, and actively avoid unfairness
>> in
>>> that case.
>>>>> Yet another aspect is how successful it will be to implement RFC3168
>>> bottleneck detection e.g. in TCP Prague, I am quite confident that these
>> will
>>> not always be successful.
>>>> I think we can safely say that the detection mechanism currently in TCP
>>> Prague is not successful.  David Black also pointed out that this would
>> always
>>> be a fragile mechanism, difficult to implement correctly, and thus likely
>> to be
>>> implemented wrongly by other transports even if a workable version was
>>> somehow developed.
>>>> With these facts established, I do not see how L4S can proceed without
>>> changing the signalling mechanism it uses.  This is something we
>> intuitively
>>> realised more than a year ago, when the SCE project was started, but now
>>> we have actual evidence to back up that intuition.
>>> And I would like to add to that, this is evidence the L4S team itself
>> should of
>>> identified, characterized and docuemented years ago.  I see no reason that
>> it
>>> took team SCE to disect the failure modes of L4S so that they could be
>>> addressed.
>>> IMHO the fact that L4S is years into the process and only done positive
>> test
>>> results presentations leads one to believe it is simply being pushed
>> through
>>> the process with little to no care about the actual internet community.
>>> The proponents seem to genuily be a) unwilling to acknowledge that there a
>>> problems they should be working on, and b) presenting that L4S is ready
>> for
>>> internet deployment inlight of the fact that data showing clear and
>> present
>>> problems exist.
>>>> - Jonathan Morton
>>> --
>>> Rod Grimes