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

Sebastian Moeller <> Wed, 17 June 2020 19:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 19ED63A0CDD for <>; Wed, 17 Jun 2020 12:25:42 -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 dQnQ9-SWgWcK for <>; Wed, 17 Jun 2020 12:25:40 -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 230543A0D0D for <>; Wed, 17 Jun 2020 12:25:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1592421934; bh=BK7bhW6jSH9112or0WPGFDeX0m2iA9FEuxT0xzdnlY4=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=astkN8j9UtqtAz7joHc82GixUSWr6Dqeqgm/mOQBsW3gdremonFL6J2esS73hI/sY afmvM3t3EhP5lJqOmjjss1XdIplqWCbyHfunu4eX1DRn+zmkWKi0ttwIOUYcPNfuR+ xLncWcTxMupyCDHrXa6iSaTYD0HkKXPBxqH7smEk=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from hms-beagle2.lan ([]) by (mrgmx105 []) with ESMTPSA (Nemesis) id 1MoO6C-1j5xCw2fbk-00oqkY; Wed, 17 Jun 2020 21:25:34 +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 21:25:32 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Wesley Eddy <>
X-Mailer: Apple Mail (2.3445.104.14)
X-Provags-ID: V03:K1:9g9PSN/rhQwpcKJBuMHpsyyba3m90Buye4mqlpdbL9AmvT0osGR ofnZAf1KYHwgCesPor0oK9lk2SX9EAt/PQjD5J1njF1Q0wKuFHXrAz2g/EW0JSJT7fvikHq GDC1bJnKfPWMmOWroXhwbGBSgJqx6rraXnHK59JmJabeDJwBafoaT80ilIz3R5GAQsyzGvr p8rIXOwgE/6Ktcoz3yMgA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:XQgTfDt2yxs=:HOpEsRCSRimbzWpYqm2Wm/ pwJ6Mt7Bok4ClDrejj5qjMPG4ujHhQSRR40XFYOy5LpzZhDF3z9a0LqEsI3YHPu+Aa2/DBPFl jnmrdd+9LeWnFh2ipWWjUyQB5pQs7OI60AiQ+tjQ/8GaHWl+Y0TGDxLrEWmas0kUPdFUm+Tu5 Y3SlTQLUbMIlkuQdk3IB6aHFZFNeu5GrMxcIVB54XuzTd3gOahNAuMk3hP0KdvlxepUHpopwy X2RXPTNSvfwufNe0+MqKM7exv3dnp7w2jZxDtMSR5ROqUuwFYRbUijgXxy0TUUg5QzQvTVDXQ 4uvBMJTFc9RSNZyUjiucHZfMo5jpMlr2Ev1oJObzaiGem/2FZ2cquXFQ8BT5M1zaTnH/+xItp 2Z3ooYjJzKLFipmastEw8phc4VvwzcYpZkh3V8jK9PdBrv1Di2t+FYbgnKPQwSzC6XzuK6S1A lgqdRSfqE+Xc/H5iP+fQ9DdZPyE+fYAudPXc/3Hz/BYxgofo1O+Fi7bA8suKYffeSeMy/7T1X F0g72ZR59mWb4pa1qUSOCbQZO38TF6cT7OranK2I0/NTj0WWQv1IORqvdhgVvvj6n7149WI6F iEUg1tMT6qorCCDx+u/D11ijuok5S4L6/6+HArHtGCVBaX19pWiuYeiMezXWDPb13qmNJJ0lr hLKgTVR78rTM0XRTpOn3K/NdogfVa0CzpaP36zEtval0/aTzMrAJcWOieZ6oTTL4qErI+tkUp ZviwCH17WaMPH2B+b2HCcwXK3qDO2fpG/sON9f5hpr+LOGLIEwtuubGkKV5OhVS2Dxs1YASww YdbLiPRvwE5uM08AcEWcmaLrd+uJ9eOVoj9Q1U4nyTMS9wqU+Y2dbKudbIcwzZqS+H+ixxYxh eQpAqROTl+pGT2DHcSJRBpYvlx5NT9vDi7a7BzabrQJU2NJgYIljMXLU5KzYx/dWGF1pZFv57 yOwmeh9Gnx9U7BOwA7dia301MbDqFbh37UQzU6n0Yw94LOe43/cVxAtJmgeCRapBe9xuTY199 FojNJ2UgmPoGBiuTT7NPpef4sHMAbs+61f6cqnXiWE73pcXg9sUddh4kHJ7bJIGOsZ4/P1r5D 2TSIt3ZNiEygl2RnJjsAEisXCAi1ANC+MM4atwU2jI4RWd/D+Rxr0elx6LkuHFT/fwCXj7A2a KqK1G5DmCRVZBa6Yt//sIiRJrjHwerKTYECOCFo56e7quqAeiZLSo+m/LYdnMQiWFFJ64=
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 19:25:42 -0000

Hi Wes,

> On Jun 17, 2020, at 18:23, Wesley Eddy <> wrote:
> On 6/17/2020 10:19 AM, Rodney W. Grimes wrote:
>> 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.
> I don't suspect that it will soothe you, but will just say that I volunteer as a co-chair and shepherd this particular work out of care for the "actual internet community" you mention.  The desire to experimentally roll-out low-latency services is aimed at serving that community.

	[SM] Please elaborate why you believe that for experimenting with low-latency services in the actual internet, an IETF RFC seems required? The bufferbloat/fq_codel/SQM crowd has been busy doing exactly that in the real live since before 2012's Codel ACM article. Codel and fq_codel both grew proper RFC AFTER demonstrating their safety, reliability and robustness in several implementations in real code in the real internet. Why is L4S such a special case that will be given a pass on demonstrating safety, reliability and robustness BEFORE being codified in an RFC? 
As I have argued multiple times in the past L4S offer precious little over the current state of the art at a considerable cost, so is far from a slam dunk solution the whole internet is just waiting for. There are a few interesting ideas in L4S all worth exploring properly, but nothing really requires timely standardization from a technical perspective (marketimg might be a different game altogether, but I believe not the IETF's main concern)

> It has not been recklessly "pushed through the process" as you are concerned with.  

	[SM] Not my words, but the framing of the L4S or SCE decision as ECT(1) as input/output question squandered a lot of good will, needlessly. (Why needlessly, because without first answering the can ECT(!) as input be safe enough question making a decision how/if to re-use the ECT(1) codepoint seemed premature).

> There are itemized issues to be resolved in order to have confidence that this can be safely deployed

	[SM] L4S issue is not the lack of enumerated lists that "improve" IETF meeting over IETF meeting, but a lack of real hard testing under realistic internet conditions. The items in the tracker try to give points to hang-up the discussion and results of these tests, but so far that amount of real-world data from the L4S proponents* has been scarce.

> (and if more emerge, they can be dispositioned and added if needed).  This particular thread is about agreeing on a path forward on the one labelled "issue #16" in the tracker.  Suggestions and discussion about that are good and welcome; repeatedly accusing others of bad intentions is not.

	[SM] In the spirit of progress, how about team L4S either accepts rfc3168 compatibility to be a hard requirement and we start to discuss what kind of properties the L4S solution needs to achieve (degree of flow imbalance, temporal fidelity of the detection, false negative rates, ...) or team L4S lays out a plan how to assess the position Ingemar (and Bob in the past) seem to take that rfc3168 AQMs are sufficiently rare in the real world to allow ignoring them. I would expect that we then discuss how to measure this** and decide on what thresholds we consider for significance before hand.

Best Regards

*) This is a call to action not only for the core L4S team, but really to everybody who voiced support or opposition to L4S, people staying completely mum in the debate so far are excused ;)

**) And yes we also need to assess who needs to make these measurements.