Re: [tsvwg] Another tunnel/VPN scenario (was RE: Reasons for WGLC/RFC asap)

[Michael Welzl <[e-mail]>]

> On Dec 4, 2020, at 11:38 AM, Jonathan Morton <[e-mail]> wrote:
> 
>> On 4 Dec, 2020, at 11:08 am, Michael Welzl <[e-mail]> wrote:
>> 
>> Imagine a scenario where L4S is deployed on some hosts feeding into a bottleneck, yet some other hosts don’t participate in the L4S experiment (e.g., these hosts could run a different OS). Now assume that the non-L4S-participating hosts want to try out 3168-style ECN **at this point in time** - and they find it performing terribly poor, worse than without using ECN, concluding that 3168-style ECN isn’t even worth trying. Then, the only possibility for improvement is to also participate in the L4S experiment - and what if this, then, also doesn’t hold its promises (e.g., because the only existing end system implementation doesn’t work well) ?   Won’t this lead to an overall conclusion that ECN isn’t worth it, and never has been?
> 
> In this situation, the effects would be seen by the non-L4S hosts even *before* they enabled ECN.  Here's an example of what they might encounter, noting that a Not-ECT CUBIC flow is involved here:
> 
> http://sce.dnsmgr.net/results/l4s-2020-11-11T120000-final/l4s-s6-rfc3168-1q/l4s-s6-rfc3168-1q-ns-prague-vs-cubic-noecn-pie-50Mbit-20ms_tcp_delivery_with_rtt.svg
> 
> For insight into this, consider that RFC-3168 AQMs are required to drop Not-ECT packets at the same rate as they mark ECT traffic.  That is, the decision to apply a congestion signal to a packet is made independently of its ECT status, and the latter only determines whether it can be a mark, or must be a drop.  The L4S traffic still looks like ECT packets (because RFC-3168 treats ECT1 as equivalent to ECT0), so the marking and dropping rates still go up in concert and the conventional traffic still gets squashed - only now it also has to perform retransmissions, so the goodput actually suffers a bit more than with ECN enabled.

Right; bad! But the inherent problem is the same: TCP Prague’s inability to detect the 3168-marking AQM algorithm. I thought that a mechanism was added, and then there were discussions of having it or not having it?  Sorry, I didn’t follow this closely enough.


> The conclusion that a user or ISP (who isn't familiar with L4S but is simply trying to roll out ECN) might draw from this is that AQM is bad and unreliable, rather than ECN per se; they would actually see a slight improvement from enabling ECN at the endpoint, but a much bigger one from disabling the AQM.  This runs contrary to the established wisdom that AQM reduces latency (which is good) without having too much effect on throughput (which would be bad).
> 
> Another possible conclusion that a more paranoid network operator could draw is that ECN *in general* is a potential DoS attack vector and must therefore be blackholed.  That would be bad for *everyone* including L4S, and would also prevent reverting to RFC-3168 deployment upon failure of the L4S experiment.  I think that is a substantial risk that must also be weighed.

I agree with that.

Cheers,
Michael