Re: [tsvwg] Reasons for WGLC/RFC asap

[Pete Heist <[e-mail]>]

One add below...

On Fri, 2020-11-20 at 03:38 +0200, Jonathan Morton wrote:
> > On 20 Nov, 2020, at 2:42 am, Greg White <[e-mail]>
> > wrote:
> > 
> > Is it possible that in these software implementations, the LSB of
> > the ECN field can be added to the FQ flow identifier, thus allowing
> > the FQ to segregate the L4S traffic in the tunnel from the Classic
> > traffic?  If so, would that solve this problem?  Is that an
> > experiment that you’d be willing to try?  
> 
> It's technically possible.  But a problem that immediately comes to
> mind is that incoming CE-marked packets would then get sorted into a
> separate queue from ECT(0) packets.  They would thus likely be
> reordered relative to the rest of the flow, and it increases total
> occupancy of the flow hash table which increases the risk of hash
> collisions.  Overall, it just seems a bit inelegant.
> 
> And then there's the possibility of tunnels which don't properly
> handle propagating ECN to the outer header.  I don't know how
> prevalent these are, but that has the potential to disable this
> workaround, putting you back in the same position.
> 
> Finally, I really think you overestimate the chances of getting
> software updates out to a lot of these devices.  In many cases, we
> consider ourselves lucky to get software updates past the first year
> after hitting the shelves, and we have to manually check and click
> through the wizard to make the update actually happen - it is *not*
> automatic for most CPE devices (imagine if the user unwittingly cut
> the power during one, corrupting the firmware).  So fq_codel as it
> exists today will be a feature of the Internet for the foreseeable
> future.

I have some experience with Ubiquiti's EdgeRouter products, and its
Smart Queueing feature with fq_codel. Their mainline code is still on a
3.10 series kernel, apparently because the offloads support for the SoC
platform was a licensed kit that's hard to get upgraded. The upgrade
cycles on these products are very slow relative to desktop and server
Linux distributions.

> In general, you should consider me skeptical of any proposed solution
> to L4S' coexistence problems that relies heavily on changing existing
> features of the internet.
> 
>  - Jonathan Morton
>