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>; Ingemar >>> Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>; >>> 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 >
- [tsvwg] path forward on L4S issue #16 Wesley Eddy
- Re: [tsvwg] path forward on L4S issue #16 Black, David
- [tsvwg] FW: path forward on L4S issue #16 Black, David
- Re: [tsvwg] FW: path forward on L4S issue #16 Jonathan Morton
- Re: [tsvwg] path forward on L4S issue #16 Ingemar Johansson S
- Re: [tsvwg] FW: path forward on L4S issue #16 Steven Blake
- [tsvwg] Options for improving L4S safety alex.burr@ealdwulf.org.uk
- Re: [tsvwg] Options for improving L4S safety Jonathan Morton
- Re: [tsvwg] FW: path forward on L4S issue #16 Ingemar Johansson S
- Re: [tsvwg] path forward on L4S issue #16 Jonathan Morton
- Re: [tsvwg] path forward on L4S issue #16 Ingemar Johansson S
- Re: [tsvwg] path forward on L4S issue #16 Sebastian Moeller
- Re: [tsvwg] path forward on L4S issue #16 Ingemar Johansson S
- Re: [tsvwg] path forward on L4S issue #16 Sebastian Moeller
- Re: [tsvwg] path forward on L4S issue #16 Jonathan Morton
- Re: [tsvwg] path forward on L4S issue #16 Rodney W. Grimes
- Re: [tsvwg] path forward on L4S issue #16 Sebastian Moeller
- Re: [tsvwg] path forward on L4S issue #16 Ingemar Johansson S
- Re: [tsvwg] path forward on L4S issue #16 Ingemar Johansson S
- Re: [tsvwg] path forward on L4S issue #16 Sebastian Moeller
- Re: [tsvwg] path forward on L4S issue #16 Ingemar Johansson S
- Re: [tsvwg] path forward on L4S issue #16 Sebastian Moeller
- Re: [tsvwg] path forward on L4S issue #16 Ingemar Johansson S
- Re: [tsvwg] path forward on L4S issue #16 Jonathan Morton
- Re: [tsvwg] path forward on L4S issue #16 Ingemar Johansson S
- Re: [tsvwg] path forward on L4S issue #16 Sebastian Moeller
- Re: [tsvwg] path forward on L4S issue #16 Ingemar Johansson S
- Re: [tsvwg] path forward on L4S issue #16 Rodney W. Grimes
- Re: [tsvwg] path forward on L4S issue #16 Sebastian Moeller
- Re: [tsvwg] path forward on L4S issue #16 Ingemar Johansson S
- Re: [tsvwg] path forward on L4S issue #16 Ingemar Johansson S
- Re: [tsvwg] path forward on L4S issue #16 Sebastian Moeller
- Re: [tsvwg] path forward on L4S issue #16 Ingemar Johansson S
- Re: [tsvwg] path forward on L4S issue #16 Sebastian Moeller
- Re: [tsvwg] path forward on L4S issue #16 Jonathan Morton
- Re: [tsvwg] path forward on L4S issue #16 Ingemar Johansson S
- Re: [tsvwg] path forward on L4S issue #16 Ingemar Johansson S
- Re: [tsvwg] path forward on L4S issue #16 Spencer Dawkins at IETF
- Re: [tsvwg] path forward on L4S issue #16 Holland, Jake
- Re: [tsvwg] path forward on L4S issue #16 Ingemar Johansson S
- Re: [tsvwg] path forward on L4S issue #16 Sebastian Moeller
- Re: [tsvwg] path forward on L4S issue #16 Jonathan Morton
- Re: [tsvwg] path forward on L4S issue #16 Ingemar Johansson S
- Re: [tsvwg] path forward on L4S issue #16 Sebastian Moeller
- Re: [tsvwg] path forward on L4S issue #16 Rodney W. Grimes
- Re: [tsvwg] path forward on L4S issue #16 Wesley Eddy
- Re: [tsvwg] path forward on L4S issue #16 Ingemar Johansson S
- Re: [tsvwg] path forward on L4S issue #16 Jonathan Morton
- Re: [tsvwg] path forward on L4S issue #16 Sebastian Moeller
- Re: [tsvwg] path forward on L4S issue #16 Black, David
- Re: [tsvwg] path forward on L4S issue #16 Ingemar Johansson S
- Re: [tsvwg] path forward on L4S issue #16 Sebastian Moeller
- Re: [tsvwg] path forward on L4S issue #16 Sebastian Moeller
- Re: [tsvwg] path forward on L4S issue #16 Wesley Eddy
- Re: [tsvwg] path forward on L4S issue #16 Paul Vixie
- Re: [tsvwg] path forward on L4S issue #16 Wesley Eddy
- Re: [tsvwg] path forward on L4S issue #16 Holland, Jake
- Re: [tsvwg] path forward on L4S issue #16 Ingemar Johansson S
- Re: [tsvwg] path forward on L4S issue #16 Sebastian Moeller
- Re: [tsvwg] path forward on L4S issue #16 Sebastian Moeller
- Re: [tsvwg] path forward on L4S issue #16 Jonathan Morton
- Re: [tsvwg] path forward on L4S issue #16 Sebastian Moeller
- Re: [tsvwg] path forward on L4S issue #16 Holland, Jake
- Re: [tsvwg] path forward on L4S issue #16 Rodney W. Grimes
- Re: [tsvwg] path forward on L4S issue #16 Ruediger.Geib
- Re: [tsvwg] path forward on L4S issue #16 Scharf, Michael
- Re: [tsvwg] path forward on L4S issue #16 Wesley Eddy
- Re: [tsvwg] path forward on L4S issue #16 Wesley Eddy
- Re: [tsvwg] path forward on L4S issue #16 Martin Duke
- Re: [tsvwg] path forward on L4S issue #16 Holland, Jake
- Re: [tsvwg] path forward on L4S issue #16 Rodney W. Grimes
- Re: [tsvwg] path forward on L4S issue #16 Wesley Eddy
- Re: [tsvwg] path forward on L4S issue #16 Sebastian Moeller