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

Sebastian Moeller <> Wed, 17 June 2020 17:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 20C2C3A0028 for <>; Wed, 17 Jun 2020 10:11:01 -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 jSQQNHUqz7dT for <>; Wed, 17 Jun 2020 10:10: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 C46FD3A0ACB for <>; Wed, 17 Jun 2020 10:10:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1592413841; bh=P23S1pX8TFszX/m8mr+g9gefDHdaXu1Qd1bUXYcEevo=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=jWrCJSZJWAmtEN0DsbRRjXM3Tpy3vhepNMf372n4BKq8kQjbGFAKbfobhEIFf/ZBZ U6ecaT4iCkR3PBVrb6AxS3F/rneyb+9kXpWgu93/VwyG1+q+4LnhBSkV9vQELtfD11 J7bCvPwjHqUq3kK4g0JOk5qHLkIcLtWUAURzW7rQ=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from hms-beagle2.lan ([]) by (mrgmx104 []) with ESMTPSA (Nemesis) id 1M7b6b-1jpBYC2DjJ-0085n6; Wed, 17 Jun 2020 19:10:41 +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 19:10:38 +0200
Cc: "Rodney W. Grimes" <>, 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:XcHwSvbr+7O+Y6JRIIO2a+42M3eAfyfK4/1ssn4Ogy2k1fsxF+e s0OAIGTdMV03Vdm+krV30MXcPkuuu5hLfrsG73OhdsulkxSHn1UfqihJcjREbz4cU8z4rEm r9/pNbNUJl+V3kcF/wD1ptWCmzoRz6/mZmam/Hx4pKhm8ugtxEvL/xQ6WXNQK42PSR7fUUG FVbDrkMfD2pMy5Fx2LsDA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:Uq9YW0SiBwQ=:ALL6qI0mIG0a9iTIKYZywt HUVMbum77atDPBi0/ba+V5MUfxZjmIrAktZh3NmhGiGGbw9y8j18IBZ+qs7yYZFHV1RIYJHcP zBB+RsxuB3VztahEAFvt+KsRrg61FVRWbMT1mh0ujuJF+s9ZXLtj5APlaElT28vRfiEZGklHG 2Sp9GUDEg/9M1UKSPGGReY3b8kvOsnW5z1YGPlnrZBx20Zayw0NQNmJRolt9WIepyoRjGhLOv nh4LNxzIu1/Jdi58jjZFaXRF2dnfhLKVDUW9i+YmM0gndzl61U74cgo889N9KJ8xh6keD0EQ7 B0x2twm6T4sY3y6dAnERdt0Cgt3ANLuLLC9ekM7ZYLsI8yKomO1m7Bt70r8lyPW/5t0xteqge YoBRcyTiWTZMNQC1DRkq6NVSzbVrINMn6dkh6iMnYZDTooHohxffOAdgzO9UvXF48ydLLRcvl zQbZzQbtcxeOdXr3bF15eS7QjY2jITFhpXEc4l/HXWUYa/MIzPnxhpPcb6iedUNEKqo3nuM1+ 5rWvAKR4xooc9+CZBWKFhHFazs/cptmq0VAZT+eO9sPNSieYw0nMK7ysVCUH5pJBZHgcbZQ36 XXXQMCtN6yxIwFMDE7k4cJN0R/ZtqI5/uUK1lkH503xJjBWRJuL9xdAzthdLJb4m6JzOmtZCG 5ACCmKHfm9e8zMuCwmMb/4YP8E9dpsWESfKCPOizglAObbkimXoR2oocv2t6m6eXT/+IaS8/7 r0ZYioJJST8nOCC8GzgOXvdfu59Eg6oYEp1/qbw1SmJ5r+JlmibCt3UPWI5pyoLBdbejdmFkf IVpVeELFc79ruVeLFGk/lcztK5LPNvwayRsD8sqgRH/cDASWsjEyYyj4mLA89vQ71TqN74euS Kge6We14S14ShwbLH8NqZkQzXnkajsMDktwNv6DpIgfu09AZan610XIQxcgsQFIKSj8/+jDcj 0X1Irj7ClmeQmjFau1PHF0I7m4bc2xEzgbSa0+2T7aYX4lNvCXLiuDi72FL8GPo3ad8WTRuHk AUStE9iZnqn+Mz4hh0Tl25TED1YfGtyR8In/M3QlycUeq5j8wPsHaoYAw2nBO9ZdOgnI9vVsy X27QEmnVBAtxtpoldUE9hW4j19t71puYOPNpoeFyCbzcjZiF/pHaRgGsod3FJUdrBzUKBtAMS r1S7C9KFOx9ydr+NiPtOczNEcduOzdU3x4gURgqoutwmNF7Mg5b8aAQ7644bu8gjN+tmw=
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 17:11:13 -0000

Hi Ingemar,

more below in-line...

> On Jun 17, 2020, at 18:27, Ingemar Johansson S <> wrote:
> 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.

	The ACM codel paper is from 2012... And fq_codel was deployed well before the matching RFC was published by the IETF. By virtue of being rdf3168 compliant deploy first standardize later was a viable way forward for codel/fq_codel. If only L4S would have selected an incrementally roll-out-able path, we would not be here right now.

> 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? 

	[SM] -ENOTIMEMACHINE, at the current time, L4S is not standardized and hence there is neither a known working implementation (tested internet wide) nor an accepted standard to work against. 

> Issue #16 is pretty much a consequence of the above timeline,

	[SM] That seems wishful thinking to me. #16 is a direct consequence of L4S decision to violate precedence and redefine the meaning of CE, plain and simple. The only thing where fq_codel got involved is in being a pretty good all around qdisc for tcp-friendly traffic and hence seeing decent deployment in Linux (and as I might add in Macs as it seems). Yes, that attractiveness has increased L4S' predicament, but it is NOT the root cause, let us please not confuse this here.

> 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?.

	I note that for the longest time rfc3168 compatibility was on the todo list of L4S. Only when team L4S was trying to get that requirement dropped* instead of actually tackling the issue the topic came to the fore on the tsvwg mailing list and meetings.

Best Regards

> /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
>> 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