Re: [tsvwg] Reasons for WGLC/RFC asap

[Jonathan Morton <[e-mail]>]

> On 19 Nov, 2020, at 6:34 pm, Gorry Fairhurst <[e-mail]> wrote:
> 
> It would help me if you clarify what you mean by  "unsafe" - to me "safety" relates to traffic unresponsive to drop, as in CBR traffic, etc. I've not understood how CE-marked traffic can erode safety, but maybe I missed something?

There is the potential for traffic between existing, RFC-compliant endpoints over an existing, RFC-compliant network to suffer a Denial of Service due to the presence of L4S traffic on that same network.  In some runs, we see CUBIC and Reno forced down to the minimum cwnd of 2 segments, and would be forced down further if that were possible.  That is the safety concern.

There is separate concern that the reference implementation of L4S doesn't meet its own specifications.  That's less of a safety concern, but we think L4S proponents should be more concerned about it than appears to be the case.  These results can (and should) be confirmed in the lab before attempting any kind of deployment.

> I'm not sure why "tunnels have crept in here. There have always been side-effects with classification (and hence scheduling), but I don't see new issues relating to "tunnels" with ECN.

An L4S middlebox can cope with tunnels containing a mixture of conventional and L4S traffic.  An RFC-compliant middlebox cannot, even if it implements FQ, which is otherwise held up as being "sufficient" to isolate L4S traffic from conventional traffic.  It is the fact that tunnels can defeat FQ that is causing renewed concern here.

The l4s-ops draft appears to say some things about this which should be a relevant point of discussion.  However, L4S proponents appear to be keen to proceed with L4S WGLC without waiting for l4s-ops.  That is a problem.

 - Jonathan Morton