Re: [tsvwg] Reasons for WGLC/RFC asap

["De Schepper, Koen (Nokia - BE/Antwerp)" <[e-mail]>]

Hi Sebastian,

Can you revisit these arguments again from the non-Flow identifying point of view? If compared with an FQ, clearly a better flow rate can be enforced. L4S can also support an FQ solution, so the comparison should be fair here. So either compare FQ_L4S with FQ_Codel or compare DualPI2 with Single Queue CoDel.

Regards,
Koen.

-----Original Message-----
From: Sebastian Moeller <[e-mail]> 
Sent: Wednesday, November 18, 2020 2:46 PM
To: De Schepper, Koen (Nokia - BE/Antwerp) <[e-mail]>
Cc: tsvwg IETF list <[e-mail]>
Subject: Re: [tsvwg] Reasons for WGLC/RFC asap

HI All,

as you might predict, I object. More verbosely below in-line pre-fixed with [SM]


> On Nov 18, 2020, at 11:31, De Schepper, Koen (Nokia - BE/Antwerp) <[e-mail]> wrote:
> 
> Hi all,
>  
> To continue on the discussions in the meeting, a recap and some extra thoughts. Did I miss some arguments?
>  
> Benefits to go for WGLC/RFC asap:
> 	• There is NOW a big need for solutions that can support Low Latency for new Interactive applications

	[SM] citation needed. That is simply an assertion and not a fact. Compared to the best of class AQM's ~5ms average queueing delay (with existing TCP mind you) L4S' 1ms really is only a minor improvement, so whoever is waiting now, is simply unaware of what is the state of the art.


> 	• The big L4S benefits were a good reason to justify the extra network effort to finally implement ECN in general and AQMs in network equipment

	[SM] Which big benefits again, certainly not introducing a robust and reliable bias for L4S over non-L4S flows also not introducing even more RTT-dependence than we have right now, nor the rfc3168 compatibility issues, or DualPI2's inherent misdesign...

> 	• Timing is optimal now: implementations in NW equipment are coming and deployment can start now

	[SM] That exact same argument will be exactly as true in any time point in the future. This is a rather thin argument for L4S, really.


> 	• Deployment of L4S support will include deployment of Classic ECN too! So even for the skeptics among us, that consider that the experiment can fail due to CCs not performing to expectations, we will fall back to having Classic ECN support

	[SM] Remind me again, how the outcome of the experiment is supposed to be measured, and how the experiment on failure is to be un-done?


> 	• Current drafts are about the network part, and are ready and stable for a very long time now.

	[SM] But assume all the hopes the network parts put in the protocols bear out in the end. Since these hopes include operational safety I object that the current network parts are ready and stable for a very long time. There is a standing list of issues with the network parts, like bias against non-L4S flows in general, unexplained magic variables all over the place, like the completely missing rationale for the 15ms delay-Target setting for the deep-queue side of the DualPI2. Non of this is new, but a documented short-coming will not automatically becom acceptable only because it has not been tackled for X years.


> 	• Only dependency to CCs in the drafts are the mandatory Prague requirements (only required input/review from future CC developers: are they feasible for you)

	[SM] This is bad engineering to outsource your safety measures to "stuff still to be designed", as it is bad engineering to assume that an optimal interplay between AQM and end-points can be designed by just thinking about the AQM conponent.


> 	• We have a good baseline for a CC (upstreaming to Linux is blocked by the non-RFC status)

	[SM] Please cite the mail from the net-dev list showing that objection, please. Or do you voluntarily refrain from asking for inclusion?


> 	• Larger scale (outside the lab) experiments are blocked by non-RFCs status

	[SM] Which would be stronger argument if all relevant lab experiments were already concluded with L4S coming out as ready for prime time. Recently posted data puts that very much in question.

> 	• It will create the required traction within the CC community to come up with improvements (if needed at all for the applications that would benefit from it; applications that don’t benefit from it yet, can/will not use it)
> 	• NW operators have benefits now (classic ECN and good AQMs) and in the future can offer their customers better Low Latency experience for the popular interactive applications

	[SM] Well, sure your bastardized version of PIE is better than no AQM (though I wonder about the consequences of you ripping-out the burst tolerance code, if you have data showing how this affects its operation, please post a link).

> 	• When more L4S CCs are developed, the real independent evaluation of those can start

	[SM] Which is not gated on L4S getting L4S status at all, only on convincing CC developers that L4S has enough merit to spend some time. What we heard here on the list is that even staunch L4S proponents like Ingemar, have refrained from creating an L4S requirements-compliant CC for their protocol, hardly a show of confidence.

>  
> Disadvantages to wait for WGLC/RFC:
> 	• We’ll gets stuck in an analysis paralysis (aren’t we already?)

	[SM] Nope, we are in, the issues are openly documented, but the developers try to outwait the critics instead of making the required real changes.

> 	• Trust in L4S will vanish

	[SM] After 7+ years, one or two more years are not going to catastrophically change the trust level, that is  not a logical argument.

> 	• No signs that we can expect more traction in CC development; trust and expectations of continuous delays will not attract people working on it, as there will be plenty of time before deployments are materializing

	[SM] Which the exact rationale, why the network bits need to be redesigned and changed to require much less cooperation from the CC side for L4S to reach its goals and promises (and maybe scaling down the promises)


> 	• Product development of L4S will stall and die due to uncertainty on if L4S will finally materialize

	[SM] Which might be the best outcome for customers until it has been demonstrated that L4S can robustly, reliably, and safely deliver its promised performance over the existing internet. Trust in L4S is going to vanish much quicker, if it turns out that it falls short of its promises and does not deliver.

> 	• Product development of Classic ECN will stall and die due to uncertainty on how L4S will finally materialize

	[SM] That is a non-sequitur, if at all the market opportunity for rfc3168 solutions will be larger if there is not a direct competitor. 

>  
> What are the advantages to wait? Do they overcome these disadvantages?

	[SM] Waiting, like we did basically for the last two years is not giving any advantages. Using say, the next two years to actually test and modify the L4S network and CC bits to robustly, reliably and fairly deliver on their promises however would be well spent time. And if that dioes not happen in that time, it might be time to call the experiment off.


Best Regards
	Sebastian




>  
> Regards,
> Koen.