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

Ingemar Johansson S <ingemar.s.johansson@ericsson.com> Wed, 10 June 2020 08:35 UTC

Return-Path: <ingemar.s.johansson@ericsson.com>
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 15C573A00C0 for <tsvwg@ietfa.amsl.com>; Wed, 10 Jun 2020 01:35:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 FBUiT1hJufDL for <tsvwg@ietfa.amsl.com>; Wed, 10 Jun 2020 01:35:14 -0700 (PDT)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2077.outbound.protection.outlook.com [40.107.21.77]) (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 63D863A00B3 for <tsvwg@ietf.org>; Wed, 10 Jun 2020 01:35:14 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TJyOENjDc0d6OuhuX/pjx7KVAoFftGACmlWrM4HcnInGvO0zG6F9eDdYbLTh2xltNTqIicLleIgrDTdBGRCVfxICl1ZIR1JxLmd6CgLS9Q1LoWsyUBwkna0MObuuSiWSmVYQnO4zetbKXvWM57ZtbCOHPn4Wzj5O6+GNbUEN5rh4Hnq71gi/wNFn7zKGExwHlmVo4v/D/0Sc6n0SL6eT4IMx4+uuGurKimXrtjOd7UfYsQPurU8L8IgNK1UsoR+YYs7sslCno2GbjXUgmfIt18ms3zALvGScurMhdh1OE5M2JvmCyJ+2c7FbMVR9DvsTn8b6dBDYHTr7ueR9wkK8dw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mzVqeZxf6T+cifzZJV9S2Tsqdj0RiO4to9s4HMgSzA4=; b=PULYEdGYk/sLdfnYb3opfOyNKth6aigpV3nXViKh2vQycf2feJxBqZ4MlAeDDq00sml3F5ZEqmeJY68WDR+7jlLfG1G7908kcKuXEDz7RAKQzZa03/BuKxmMUopsG/U4ax9+qrmtTpa27lpAGvYY96Z3ri2I5YP+FaVaZ8i2cF/EAV3maB/X1iMEwEnpn+WdbT+Tx2aiQnrJ889LZYkFWC7FLwS+61i9uYi7R/6hoFkFouUmBw98PJvRUmYWnQh3NgZlCBhpS5F8VnlkpEUqWzS/69JagwjOYyFg3VOG/er4xO+DGz/AWyKMTaDJZHt5wXohf239+/b2q/DbQ1t/OA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mzVqeZxf6T+cifzZJV9S2Tsqdj0RiO4to9s4HMgSzA4=; b=NIuHJPwrY0Nl/ghd0x0doS/nPPSK1hJcYjxpQtT1hGcWMYINOFSj1adD70rn64OCT/33+CzL1Ly7Wvhm7hmYxsuDu9APXM0nLaMvT+Bw+pE4vqTLKUGflQj2aduCBV2yeatluTk9Cbd0wCXEFzfAkaBTyw0b0kn6xV5hwwYDBk4=
Received: from HE1PR0701MB2876.eurprd07.prod.outlook.com (2603:10a6:3:56::8) by HE1PR0701MB2332.eurprd07.prod.outlook.com (2603:10a6:3:68::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.17; Wed, 10 Jun 2020 08:35:11 +0000
Received: from HE1PR0701MB2876.eurprd07.prod.outlook.com ([fe80::f411:8f72:4035:41d1]) by HE1PR0701MB2876.eurprd07.prod.outlook.com ([fe80::f411:8f72:4035:41d1%8]) with mapi id 15.20.3088.018; Wed, 10 Jun 2020 08:35:11 +0000
From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
To: Sebastian Moeller <moeller0@gmx.de>
CC: Jonathan Morton <chromatix99@gmail.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Thread-Topic: [tsvwg] path forward on L4S issue #16
Thread-Index: AQHWPkYZyJNg6cgsQkOoRWoF9Fsxh6jQUFNQgAAFjoCAAAT/IIAABjQAgAAXTICAACKkgIAAFF2AgACvbJCAABzFAIAAByHA
Date: Wed, 10 Jun 2020 08:35:11 +0000
Message-ID: <HE1PR0701MB287695F2245A480A43DB5F9BC2830@HE1PR0701MB2876.eurprd07.prod.outlook.com>
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> <5ADEBD56-1A2C-4C34-9132-E50A4A7A4A42@gmx.de>
In-Reply-To: <5ADEBD56-1A2C-4C34-9132-E50A4A7A4A42@gmx.de>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: gmx.de; dkim=none (message not signed) header.d=none;gmx.de; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [192.176.1.83]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0614d19c-6501-4768-e380-08d80d193086
x-ms-traffictypediagnostic: HE1PR0701MB2332:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <HE1PR0701MB233265044C44DDC01A46A0D0C2830@HE1PR0701MB2332.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:6790;
x-forefront-prvs: 0430FA5CB7
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: bQ3+Mu6ES3+CQz8hhp2vm0+mFychiVx/+p5+dvREgkRCGlZg4ae/rAfg5UkPHezVkbIiU6Z8YIMnwciG787CooPcM2XJLlK2h/SL7PSU5tBjNzNM0bvn1G+0iJ+7EzFayFt3zEcdtIxtNsrksms1dkx28B9VwuO8X3A6JkSbv1KuEoLbygcDjmhsOG8c0uizuc65JEnfdsFZL7Lnyg4U5LnTnzthkg4xNylv3k/cZwxligkg0/DC8aYdGEISMWEe9P4CIbpEQXa6BtTwdylUsX7PvpVMa3aZaK0sQb2qurvDS+LyMUvmdqzBFjFC5fgRV+tR65xw1sX0lqL606Eb8w==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB2876.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(346002)(366004)(39860400002)(376002)(136003)(9686003)(64756008)(55016002)(66616009)(66476007)(66556008)(66446008)(4326008)(52536014)(107886003)(76116006)(66946007)(33656002)(30864003)(71200400001)(6916009)(86362001)(5660300002)(26005)(316002)(66574014)(8676002)(6506007)(53546011)(83380400001)(7696005)(186003)(478600001)(54906003)(99936003)(8936002)(2906002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: SteUw9C6vV8KwGLZkmRk/XXtnBgWetsiJy58qGjkvtwZ10LGE7WiOxAPiMjNtzlhkb2l36tYPkz80hA7xnmgs3LpsMHakAPrTnSerOuuF1yvyhKAnARbE1IwU9CGY9Fm0FivmrPAnuG8pTXTpjQeinVJTzcIQkExQmk6VBz2dlkVSNExzBeQSN0Rf1QIIvSwGVqP9Q9J/BEd/MELT+m3hXzzvZrPCADWn4MEB4SJ1QANTrJbfBrlap79adEhzoC6eOuVOUpXmUKWl9eSUNgmoZwx8OGhjJNc4T/LUGmdYF69xwQCEVd0pLolYqF2QFG6wH1faUICA4+xzRvatTC1HiIBxuzJ4Xy0EchixLEXSL8tUub8pBj7YoHUtj4YvWUDzcee7lMMtGu6KI6l5iUzOWTZdWlI3Z+5ya+Y6t5lDOV8kGsnfRUr+Cz610kbxKbJM59vWJhf44jxXGbyMcteZtuMznQCBFAGluZIlzwRBuM=
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_03B1_01D63F12.D031BC90"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0614d19c-6501-4768-e380-08d80d193086
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2020 08:35:11.0325 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: AFgCjsBQafqWYmxBmIhlAkWoRftuA73fhInJBQwrF3c/h59JuKABPfMk9dESh5Y9ZcFrnUNBGt+Yr+tT5xoEcDNSDhJRG7QHVCbw6aH6DFDSRbf7VKGGG+S2v1SXqMsO
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2332
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/J3ObgSftIG5RP64o6maFVwib06k>
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 08:35:17 -0000

Hi

Coming back to my questions. Is it possible to answer these first?, then we
can move on to the other questions, isn't this reasonable ?

1) How widely are  RFC3168 ECN capable AQMs deployed _and_ enabled ?
2) If they are deployed _and_ enabled, can/will they be updated ?

I mean there should be an interest in getting some indication as regards to
the level of severity to the problem that we try to solve, right ?


> -----Original Message-----
> From: Sebastian Moeller <moeller0@gmx.de>
> Sent: den 10 juni 2020 09:52
> 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,
> 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