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

Sebastian Moeller <moeller0@gmx.de> Wed, 10 June 2020 07:52 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 419663A0F84 for <tsvwg@ietfa.amsl.com>; Wed, 10 Jun 2020 00:52:26 -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 ks_OqdT8rqXh for <tsvwg@ietfa.amsl.com>; Wed, 10 Jun 2020 00:52:24 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 231923A0F83 for <tsvwg@ietf.org>; Wed, 10 Jun 2020 00:52:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1591775539; bh=dy4ckrKn9U4fsYjmGf8UzK8x5MjeUKyrhRf462wZ+gg=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=JXots2umPn/mFcNCLqbevuD9FlG5+OmrrP7r3+RG1GFiyJen45d753nAA54SDL4LA VETJDOKCfmM8hrdX6EpkHG4VEdlp5vBBqzfRuh9zEepZxMyx5jyKGxMW/wLBKRztI7 2Ywx8zwaTUI4qjaM0qFMbRm2QEDrfc3YrLTfKgLE=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.11.12.3] ([134.76.241.253]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MhlKy-1jDyUd2xVo-00dnxF; Wed, 10 Jun 2020 09:52:19 +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: <HE1PR0701MB28767A1E570A705EBC65EFC4C2830@HE1PR0701MB2876.eurprd07.prod.outlook.com>
Date: Wed, 10 Jun 2020 09:52:16 +0200
Cc: Jonathan Morton <chromatix99@gmail.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5ADEBD56-1A2C-4C34-9132-E50A4A7A4A42@gmx.de>
References: <HE1PR0701MB2876AA3CBBA215B9FB895B0AC2820@HE1PR0701MB2876.eurprd07.prod.outlook.com> <3637517F-63A0-4862-9885-AB5EA7E6C273@gmail.com> <VI1PR0701MB2877E21B7F406C3DFCFF08BCC2820@VI1PR0701MB2877.eurprd07.prod.outlook.com> <92525827-39B6-4E88-B453-660F8FE22523@gmx.de> <VI1PR0701MB287768D465C37DC46A459C12C2820@VI1PR0701MB2877.eurprd07.prod.outlook.com> <57D7632A-594E-47BC-B6B0-5FBC22AAFE37@gmail.com> <DF67B660-DE2B-4EB8-AD77-5FECF27D1BAC@gmx.de> <HE1PR0701MB287679D1842F15FCDAC6223EC2820@HE1PR0701MB2876.eurprd07.prod.outlook.com> <7EEF7075-396F-4565-89C6-674CBB1E6CB8@gmx.de> <HE1PR0701MB28767A1E570A705EBC65EFC4C2830@HE1PR0701MB2876.eurprd07.prod.outlook.com>
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
X-Mailer: Apple Mail (2.3445.104.14)
X-Provags-ID: V03:K1:j40Crf6ye/bTA+zhIX07MbRurcxCpmQZP4Hu9R4xDR2bkerBydV FPzyNu3e3dWVTUp2/N/X9EEuh3FWaFk5vgzYt9/LkhBDeZ0tTot+sjM1ovsuOL6PJpKnx93 634y3BCjTSdwlGF5v5ZQlIfpv7eng3fx0gbAQ5oRdkFrLGHL4VYJ8rkbfM92srT+zVdRrHQ WvXgpskoOFYulGPszyOWg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:4MGt7NipdIA=:2vI70PmTjoOa9S7zLQpTmd rtsBYOk+o+lzyOfRDK8FKgOeu7hxEod7SYS8B6vXWsjfdg72ksAaGZha9zE5T3tCxTtw1iyxe XxEfMcpTndjzGXeAnXdmJfi4mMEFS847g7FvRwgar6uCVTEbBFU0CmVMM016uNwQnsOOy4OHd 5XQ3eEXcnHITjOm1f/bj8bqnfzV3F+TN3yny6NR3mZaXgUBC6n+kWhakrREyy0YdDihqhL7rH 8EQZ9Arvoi1FB0JCvvCp5CKQuRWA2ZtXo9XhkzVUVIeBgjvUqjcUY92jxRcWeZ8i16QXWtVrD cHfPvMV6ix1o0EUEztR22jJ7mxEwtYjBKWYyQ7pyGLvza1R8Jr3a0rG4jxoW13B/IC7yK+qWa EXK1SvGRsT7R6StcoC1l57br/u/wjOfOtIZZSVWggxkW+iqTf2jRDoEx0NgEo/vD1dGq5wsWq RhOevJ1V4iimqgc6cAdzYAi1A1wj/7rjKvWXcyuGwBrh91HdU/uflgy9qIA9Aaz0fYw7rQvxO ueHy+t95XDtShwtp5gnKa2GPajE151bFvCdGd5S0Q/3YYw7VVDzKIViSoznLLCUAHA3obyWe5 YfoOHQ0MPhZz3ghGa4eHbcrF63SR8oc7/SPhJTk0weU+lcCKIBYH07e4XEwG5KzicqrynCiLR Ukod4c/0wQWr1ZVzjLEVtmji+09+q3c0k4lYMJku6ieMmU+U9nwmdjqDUvGjmmfelMCz5xCI5 acug2r1OiCIQ/zvoJXEpLMj0vzD9syqXOz/ckVxkOOeFCn3oQrtNLaCun/Zcfb+oHEl6Fd1lR D+iTOC4APNTsOOC4TbdybHNGR4caLSI7ccQI+1LVDjrw5sUj14gVaMk3K2um+stw4aCp0IYRq MC3I9bRUnOAEWyzFvT27QYy6MshAduzUDmMBCy83TTg2u3+36bXd8tA4hBgupEbedpf5oCbcW VT2qMTJDBZMdCJ7iw2HxKTtTqtLEDllbCDZvHHW2JBPMJS3YU/Xnm8fQyDUa/LCDxEEu41GLd JygaAWHSI7lPncryeWWuamrvf1ObxUtuY+8d++HNzkVQhjGluigLof5JG023f6lc5kBN+cfqN KS65T0/XmD/AZzJfSXTpZLP1TFj8ZI0P7W0LbXsANFrPOU+NohUgk5v93E2ivfTEL03pnPGUZ hiqZEPTbYsxCLwx3g4nCGPQX+mfx96rTNmqzx/FYNX7a8fElm4AR/jZb16qA67/iE0lZIGVSD uzIvmmz0m4ZgsBHXL
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/1ZJF9NhbW5Pe3zBKidSbrrNSiJE>
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, 10 Jun 2020 07:52:26 -0000

Hi Ingemar,
more below in-line.

> On Jun 10, 2020, at 08:44, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:
> 
> Hi Sebastian
> 
> Please see inline
> /Ingemar
> 
> 
>> -----Original Message-----
>> From: Sebastian Moeller <moeller0@gmx.de>
>> Sent: den 9 juni 2020 21:41
>> To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
>> Cc: Jonathan Morton <chromatix99@gmail.com>om>; tsvwg@ietf.org
>> Subject: Re: [tsvwg] path forward on L4S issue #16
>> 
>> Hi Ingemar,
>> 
>> 
>>> On Jun 9, 2020, at 20:58, Ingemar Johansson S
>> <ingemar.s.johansson@ericsson.com> 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.
> 
> [IJ] That boils down to an assessment how severe the issues you point out
> really are, and to some extent it boils  down to my questions #1 and #2
> below. 

	[SM] Honestly, I disagree, while we are currently focussing on RFC3168 compatibility this is by far not the only realistic internet scenario in which L4S falls painfully short of its promises. Let me remind you on the abysmal sharing behavior between the two queues at short RTTs. I keep harping on this for the following reasons:

a) Fixing this design error in the dual queue coupled AQM in the transport layer is clearly the wrong place, given the fact that TCP Prague will not be the only transport envisioned to carry ECT(1), as far as I can tell you have made so far no tests in scream to see whether you are affected by the same issue (and truth be told, on an end-user mobile link a certain priority/dominance for real-time video streams might actually be in the users interest, as a user I would prefer some sort of opt-in though).

b) the short RTT/few hop scenario is the only one that has seen some modicum of testing in the L4S effort, and it is also the only one where decreasing the RTT by a few dozens milliseconds will actually translate into significant RTT/jitter reductions.

c) the fact that team L4S constantly tries to kill the messenger and to conflate the DualQ mis-design with RTT-independence and other red herrings, indicates a lack of solid engineering principles, which I for one find disheartening in what, by its own proponents, seems to be designed to be the future of congestion control in the internet.

In almost every corner we looked, the current L4S implementation revealed gaping holes and undesirable behavior, and the L4S team did sped most of its time not fixing the issues, but trying to arfgue the issues away. I see your point #1 as one of these attempts to argue a hard problem away instead of either solving it, or re0-designing L4S to not have that issue in the first place, which, obviously, is my personal subjective opinion.


> 
>> 
>>> 
>>> 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.
> 
> [IJ] Then one need to define the meaning of "localized experiments" but I
> skip that part. I guess it is not IETFs intention to leave up to other SDO's
> like 3GPP to do what they like with the ECN bits until IETF has made up its
> mind. Or is it ?, this is at least not how I read the message in TSVWG.

	[SM] I still maintain, that even for internet scale experiments no SDO needs to be involved, unless one attempts to "volunteer" one's own iusers into the experiment. But I consider that to be bad style and questionable. Also such an "experiment" should only be performed once the scenarios I outlined have been tested and the to be rolled-out mechanism survives these tests satisfactorily.
	Heck, with a modicum of cooperation, mobile carriers all over the world could run tests between their respective development labs, giving world-wide coverage without the need to put any usaer in harms way.


> 
>> 	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).
> 
> [IJ] OK, I tend to use the this IPv4/6 analogy every now and then, but that
> does not at all apply here. 
> IPv4 is widely deployed and I don't even use IPv6. I seriously wonder how
> widely RFC3168 is deployed and used in AQMs

	[SM] I see, partly a disconnect on my side, I am not laser focussed on your #1 and #2, as I do not believe that this an exhaustive enumeration of L4S issues that need fixing, I am looking at this more from the perspective of L4S's implicit claim to be the future of congestion control to replace all classic congesyion control. Under that perspective the IPv4/6 analogy seems quite apt to me.


> So here my questions are (repeated):
> 1) How widely are  RFC3168 ECN capable AQMs deployed _and_ enabled ? 
>   IPv4 and RFC3168 ECN capable AQMs seem to have very little in common when
> one look at deployment and use, so how commonplace is it that nodes on the
> internet have RFC3168 ECN capable AQMs deployed _and_ enabled, 1%, 10% ???? \

	[SM] From a safety perspective, I still believe this is the wrong question to ask, as it implies a course of action of simply ignoring the existing deployment, trying to assess importance simply be sheer number, which is not a good proxy.

> 
> 2) If they are deployed _and_ enabled, can/will they be updated ?
>   You gave your personal view on this matter.

	[SM] You keep saying that like you and team L4S deals in objective truth statements, to which I take offense. Also I believe that the question is ill-posed without adding a time horizon for potential updates.


> 
> I guess it can be a good exercise for the opponents to the L4S to come with
> verifiable answers to these two questions.

	[SM] I would love that, but I venture a guess, that we will see more personal views on that matter. I have, as you might have noticed, asked repeatedly for cold hard data, and so far we have not seen that much, and most of if it from the SCE effort.

Best Regards
	Sebastian



> It is important to know so we
> don't waste a lot of energy on a problem that diminishes among all other
> problems.
> 
>> 
>> Best Regards
>> 	sebastian
>> 
>> 
>>> 
>>> /Ingemar
>>> 
>>>> -----Original Message-----
>>>> From: Sebastian Moeller <moeller0@gmx.de>
>>>> Sent: den 9 juni 2020 18:25
>>>> To: Jonathan Morton <chromatix99@gmail.com>
>>>> Cc: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>om>;
>>>> tsvwg@ietf.org
>>>> Subject: Re: [tsvwg] path forward on L4S issue #16
>>>> 
>>>> Hi Jonathan,
>>>> 
>>>> 
>>>>> On Jun 9, 2020, at 17:01, Jonathan Morton <chromatix99@gmail.com>
>>>> wrote:
>>>>> 
>>>>>> On 9 Jun, 2020, at 5:43 pm, Ingemar Johansson S
>>>> <ingemar.s.johansson@ericsson.com> 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