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

[Sebastian Moeller <[e-mail]>]

Hi Wes,


> On Jun 17, 2020, at 18:23, Wesley Eddy <[e-mail]> 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
	Sebastian


*) 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.