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

Sebastian Moeller <moeller0@gmx.de> Wed, 17 June 2020 18:19 UTC

Return-Path: <moeller0@gmx.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4EA3A0AD6; Wed, 17 Jun 2020 11:19:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTFL4QlGjVOc; Wed, 17 Jun 2020 11:19:45 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 018F23A0CCF; Wed, 17 Jun 2020 11:19:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; 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 ([77.8.173.241]) by mail.gmx.com (mrgmx105 [212.227.17.168]) 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 <moeller0@gmx.de>
In-Reply-To: <MN2PR19MB40450A06A919354C8D4CFC74839A0@MN2PR19MB4045.namprd19.prod.outlook.com>
Date: Wed, 17 Jun 2020 20:19:23 +0200
Cc: Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9E403EBC-79D4-4C6E-B000-E53BE8B29228@gmx.de>
References: <2DC5C89B-C979-4354-98D7-BBDBC78A42B1@gmail.com> <202006171419.05HEJClG085550@gndrsh.dnsmgr.net> <HE1PR0701MB287641121218FC0AA72F56B0C29A0@HE1PR0701MB2876.eurprd07.prod.outlook.com> <MN2PR19MB40450A06A919354C8D4CFC74839A0@MN2PR19MB4045.namprd19.prod.outlook.com>
To: "Black, David" <David.Black@dell.com>
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: <https://mailarchive.ietf.org/arch/msg/tsvwg/KF9Bv8_IQZ-6e4pqoGUD6cik-B8>
Subject: Re: [tsvwg] path forward on L4S issue #16
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2020 18:19:47 -0000

Hi David,

> On Jun 17, 2020, at 19:25, Black, David <David.Black@dell.com> 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
	Sebastian



> 
> Thanks, --David
> 
>> -----Original Message-----
>> From: tsvwg <tsvwg-bounces@ietf.org> 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; tsvwg@ietf.org
>> 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 <ietf@gndrsh.dnsmgr.net>
>>> Sent: den 17 juni 2020 16:19
>>> To: Jonathan Morton <chromatix99@gmail.com>
>>> Cc: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>om>; Ingemar
>>> Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>rg>;
>>> tsvwg@ietf.org
>>> Subject: Re: [tsvwg] path forward on L4S issue #16
>>> 
>>>>> On 17 Jun, 2020, at 4:20 pm, Ingemar Johansson S
>>> <ingemar.s.johansson@ericsson.com> 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
>> rgrimes@freebsd.org
>