Re: [tsvwg] feedback and thoughts L4S / SCE

[Greg White <[e-mail]>]

Hi Mikael,

On your point about L4S in non-ECN FIFOs, I agree that these will dominate in the Internet for quite some time. But, I don’t believe there has been any evidence of lack of safety for L4S-compatible CCs in those bottlenecks.  It is, in fact, a requirement in the ECN-L4S-ID draft that CCs respond to loss in a Reno-safe way.
https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-12#section-4.3

What has been argued is that the current TCP Prague prototype CC responds to loss *exactly* like Reno, and so is outcompeted by Cubic in these bottlenecks (see the pfifo results in https://github.com/heistp/l4s-tests#network-bias ).

If you attended Bob & Koen’s talk in ICCRG (https://datatracker.ietf.org/meeting/109/materials/slides-109-iccrg-prague-congestion-control-00), you saw that they mention (slide 9) “faster than additive increase” as an aspect that is not currently included in the Prague CC.  They also mention (slide 15) “Integration with BBR/Cubic instead of Reno” as a possible area for others to contribute.

-Greg



From: tsvwg <[e-mail]> on behalf of Mikael Abrahamsson <swmike=[e-mail]>
Organization: People's Front Against WWW
Date: Friday, November 20, 2020 at 6:34 AM
To: "[e-mail]" <[e-mail]>
Subject: [tsvwg] feedback and thoughts L4S / SCE


Hi,



I'm trying to catch up on the work has been done, but I thought I'd give

some thoughts / feedback on what I see:



https://github.com/heistp/l4s-tests



"L4S transports experience intra-flow latency spikes at RFC3168

bottlenecks, particularly with the widely deployed fq_codel"



FQ_CODEL isn't widely deployed. Yes, it's enabled in the linux kernel but

very seldom at the bw chokepoint of the connection. I do not agree with

the above statement at all. Thus any benchmarking vs FQ_ anything is

invalid. What's mostly used today are typically simple FIFOs, sometimes

diffserv enabled with multiple FIFOs.



This means the tunnel argument against any FQ or non-FQ AQM is invalid. I

also doubt we'll see widely deployed FQ going forward because of the cost

of doing this in hw (and most devices are hw accelerated).



"Deployments of fq_codel

The fq_codel qdisc has been in the Linux kernel since version 3.6 (late

2012) and is now in widespread use in commercial routers (e.g. Ubiquiti

EdgeMAX and UniFi products)"



This is misleading. Yes, EdgeMAX supports FQ_CODEL if you turn off

hw_acceleration, bringing down the performance to 10% or less of what the

hw acceleration yields. I do not agree that it's in "widespread" use.



I'd gladly take data to prove me wrong, that FQ_CODEL is in widespread use

at Internet bw chokepoints. I'd be surprised if it was enabled on more

than 1% of residential connections.



On to L4S.



Now, taking above statement and looking at what L4S is doing, for 1-2

decades going forward L4S enabled transport will often encounter FIFOs,

mostly without ECN capability at all. They need to be proven safe in this

operational reality. From what I can see, this is still not the case?



Going forward:



In order to progress to a solution, we need to have participants agree on

what the world looks like right now, what's doable in the next few years,

and what's required to handle existing/near term reality. SCE proponents

have to stop arguing that we'll have FQ_ anything near term, or that this

is in wide use. It's not. L4S proponents need to prove that their

proposals are safe in a world of FIFOs, and accept that this is going to

be a reality for years to come. AQMs aren't deployed in a hurry, we're

talking many years to deploy on the wider Internet.



We're spending the last bit in the IP header and we'd better get it right.

In order to do that, I'd like to see realism and pragmatism in the

reasoning.



--

Mikael Abrahamsson    email: [e-mail]