Re: [tsvwg] Reasons for WGLC/RFC asap

[Jonathan Morton <[e-mail]>]

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

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