Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs

[Pete Heist <[e-mail]>]

> On Nov 7, 2019, at 7:54 AM, [e-mail] wrote:
> 
> On Thursday, November 7, 2019, 3:35:06 AM GMT, Jonathan Morton <[e-mail]> wrote:
> 
> > > - if the CoDel queue is upgraded to perform Immediate AQM on L4S flows, the latency spike can be largely avoided.
> 
> > This is not relevant, since the point of this exercise is to establish the extent of L4S' compatibility with existing, unmodified networks, in which Codel happens to be the most widely deployed > AQM.  You cannot reasonably expect the entire Internet to "upgrade" to L4S compatible AQMs before you can safely begin deployment.
> 
> I wonder if Codel actually is the most widely deployed AQM. This is not to dispute your point, which is correct - proposing an update to Codel doesn't addess existing deployments..

I can’t contribute any information to which is the most widely deployed, however to counter any suggestion that CoDel _isn’t_ widely deployed, Ubiquiti’s UniFi and EdgeMAX line of products use fq_codel in what they call their “smart queueing” feature, and are often deployed at bottlenecks (CPE equipment and backhauls). In their UniFi administrative controller, they also passively monitor TCP RTT, and according to some internal heuristic, send notifications to the administrator to consider turning on smart queueing (i.e. fq_codel) at the UniFi gateway. In the subtitle for the UniFi product page is the text “millions of shipments per year in 180+ countries”. Although that’s only marketing, it gives some idea of the scale of deployment from this vendor.

It does look like the issue is being worked on though, so this is just to add some weight to the importance of handling it well, which to me means minimizing false positives or negatives for non-L4S queue detection, minimizing detection time, and taking into account path changes that might move the bottleneck at any time. :)