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

[Sebastian Moeller <[e-mail]>]

See below....

On November 7, 2019 5:25:11 PM GMT+01:00, Pete Heist <[e-mail]> wrote:
>
>> 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. :)

 [SM] I guess it is worth repeating that the obvious solution to all of these challenges would be to fix the actual root cause of the issue, instead of trying to paper over the symptoms. If L4S would not try to make the ECT(1) and the CE codepoint do the work that would require 2 independent bits neither issue 16 nor 17 would exist in the first place. I wonder how, after having eloquently argued for the requirement of strict isolation/separation between tcp-friendly and dctcp-style traffic, one could have converged on this clearly sub-optimal approach. 
I have read the discussion of the alternatives in the L4S draft and while clearly none of the options is perfect, most have less undesirable side effects on normal traffic than the admittedly clever 'overload ECN codepoints' variant that currently is being pushed.

Best Regards
        Sebastian