Re: [tsvwg] feedback and thoughts L4S / SCE

[Sebastian Moeller <[e-mail]>]

Hi Ingemar,

I am not sure how your post relates to the one you seemingly replied to? 


> On Nov 30, 2020, at 10:14, Ingemar Johansson S <[e-mail]> wrote:
> 
> Hi
> 
> I am not sure what conclusions I should draw from this. 

	[SM] If you would look at what L4S actually delivers the conclusion should be that it simply is not ready, but I realize that in spite of hard supporting data your assessment ist different.


> Lossy AQMs is a non-issue as both DCTCP and Prague makes a fallback to loss
> based recovery so that is settled.

	[SM] Well, not really, both DCTCP and TCP Prague are atrocious with medium length RTTs and non-L4S AQMs (unless that AQM is flow fair), they are simply not ready for being used over the wider internet. In a sense that DCTCP is not suitable as an internet-wide protocol (without significant changes) is one of the results of the L4S experiments, as is the fact that TCP Prague does not yet? describe a complete set of required fixes (just look at TCP Pragues performance versus CUBIC in a purely drop based FIFO buffer). And Koen admitted as much when he proposed to change TCP Prague to behave like CUBIC if the RTT exceeds ~80ms. 
	I am still waiting for a demonstration of L4S robustly and reliably delivering on its promises over anything but the low hop-count short RTT paths that have been over-tested so far. 


> 
> That leaves us with the long discussion RFC3168 AQMs. Here the discussion
> leaves me thinking that we are talking about a very limited actual
> deployment in other words too much ado about very little.

	[SM] citation needed? The challenge is that we have no reliable numbers, one way or the other. Your assessment, says more about your leaning towards L4S than about the deployed reality in the internet. 


> In addition, I get
> the impression that these limited deployments are seen as monoliths that
> cannot be modified and updated,

	[SM] So I wonder in what kind of blessed reality you seem to be living? In my experience updates for most consumer-grade networked equipment are pretty rare and often stop way before the useful live of such devices, assuming all of these can/will be updated in time is simply unrealistic. Any proposal that relies on that has the onus of convincing the reviewers why this time around this will be a successful approach. 


> which is a bit confusing too as fq_codel can
> be configured for DCTCP..

	[SM] The latter point might be true, but will fq_codel with your proposed configuration change still perform equally well with standard-compliant rfc3168 ECN flows? These are and will be for a considerable time be the dominant ECN users on the internet. 

> 
> So, my conclusion is that we should move on to WGLC, worries about possible
> boxes on the network is something that can be quantified during the L4S
> experiment.

	[SM] Well, but then the experiment can not be "how to deploy L4S" maybe "can we deploy L4S" might be a worth while question, but it has become clear that nobody in team L4S is even willing to offer contingency plans what to do in case their hopes do not come true. How to re-claim ECT(1), what to do with deployed L4S dual-queue AQMs, what to do with endpoints that configured TCP Prague as default CC, all questions that should have be discussed in the L4S internet drafts IMHO, indicating that in addition to L4S' design and implementation not being ready, the drafts are equally half-baked (heck there isn't even an internet draft for L4S' reference CC implementation in TCP Prague at all, as far as I can see). Ready it ain't, so why rush to WGLC?

Sebastian


> 
> /Ingemar
> 
> 
>> -----Original Message-----
>> From: tsvwg <[e-mail]> On Behalf Of Sebastian Moeller
>> Sent: den 28 november 2020 18:07
>> To: Mikael Abrahamsson <[e-mail]>
>> Cc: [e-mail]
>> Subject: Re: [tsvwg] feedback and thoughts L4S / SCE
>> 
>> Hi Mikael,
>> 
>> I actually wanted to stay out of tis sub thread, but...
>> 
>> 
>>> On Nov 28, 2020, at 17:24, Mikael Abrahamsson <[e-mail]>
>> wrote:
>>> 
>>> On Sat, 28 Nov 2020, Jonathan Morton wrote:
>>> 
>>>> Take a random sampling of CPE devices, and see how many of them use the
>> above - or it might be easier to count the ones that don't.  I'll wait.
>>> 
>>> My ubiquiti APs come with it, but it's default turned off.
>>> 
>>> It's not only important of the devices have the capability, it also
> needs to be
>> default turned on so it's actually used (considering most people don't
> change
>> config much).
>> 
>> 	[SM] ... if end-user devices have such capabilities, the big ISPs
> that in
>> all likelihood are the biggest buyers of such devices, should have little
> issues
>> adding that to their requirements list for their purchases and making sure
>> devices are configured properly, without driving up the costs unduly, no?.
>> 	The fact that that has not happened is in itself a rather clear
> indication
>> that ISPs are really not that interested in tackling latency under load
> (and why
>> should they, often unhappy users will switch to a higher/more profitable
>> speed tier in a well-intended but not very effective attempt at improving
> a
>> link's usefulness).
>> 	Now, for end-users that is a different issue, and there are quite
> some,
>> often on-line gamers interested in reducing their internet access link's
>> latency, that are actually willing to buy and configure boutique devices,
> like
>> the NetDUMA, or more down to earth and less hyped (but IMHO even more
>> capable) evenroute's iqrouter. Incidentally, both are basically software
>> distributions for relative standard existing router's from other
> manufacturers,
>> and yet people are paying a premium to get those better behaving router
> OS,
>> as latency under load performance of stock router OSes often is not
> "cutting
>> it"...
>> 
>> 	I note that L4S never reached out to those end-users actually caring
>> for low latency... instead they are trying to convince the ISP market,
> without a
>> narrative how this is going to imprive an ISP's bottom-line (the you need
> to do
>> this to not fall behind the competition, is not a positive selling point
> IMHO).
>> 
>> Best Regards
>> 	Sebastian