Re: [tsvwg] feedback and thoughts L4S / SCE

[Pete Heist <[e-mail]>]

Hi Michael, a few replies below...

On Fri, 2020-11-20 at 14:33 +0100, Mikael Abrahamsson wrote:
> 
> 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.

I do accept the criticism that the phrase "widely deployed" was only
qualified with a vendor list. So in response, I've contributed some ECN
data under a new thread, and I'll review my part of the writeup later
for any language that I think isn't supported well enough. Just asking
for some patience with that. :)

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

However, it's still used, at the edge, in backhauls, and built into
Linux WiFi drivers. The Preseem QoE platform is indirect evidence of
fq_codel use in backhauls, and we know there are ISPs that manage
queues in their backhauls with custom scripts using fq_codel. Instead
of delving into various products, I suspect that trying to gather ECN
stats at relevant places on the Internet might be more fruitful(?)

It's a known issue that any non-FQ RFC3168 bottleneck leads to
domination of non-L4S flows by competing L4S flows, tunnel or not. I'll
post another test scenario with several AQMs showing that once I write
it up.

> "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.

Let's see if we can come up with more data.

>  SCE proponents 
> have to stop arguing that we'll have FQ_ anything near term, or that
> this 
> is in wide use. It's not.

We're working on SCE and know where we're headed at least, but it isn't
on the WG's table now.

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

:)