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

[Michael Welzl <[e-mail]>]

Hi,

A few answers in line:


> On Dec 4, 2020, at 1:32 PM, Mirja Kuehlewind <[e-mail]> wrote:
> 
> Hi all,
> 
> to add one more option.
> 
> To be clearly any issues discussed only occurred if RCF3168-AQMs (without FQ) are deployed in the network (no matter if any traffic is actually RFC3168-ECN enabled or not). 
> 
> My understanding of the current deployment status is that only ECN-AQMs with FG support are deployed today and I don't think we should put a lot of effort in a complicated RFC3168-AQM detection mechanism which might negative impact the L4S experiment if we have no evidence that these queues are actually deployed.

If that’s the case, I would say that it would be a more reasonable sequence to first move RFC 3168 to historic.
If we can’t find consensus on this, then how can there be consensus to go out and deploy a mechanism that essentially starves traffic which uses this other mechanism?


> Further I would like to note that RCF3168 AQMs are already negatively impacting non ECN traffic and advantaging ECN traffic. However, I think it's actually a feature of L4S to provide better performance that non-ECN and therefore providing a deployment incentive for L4S, as long as non-L4S is not starved entirely.

Starving entirely, or something *very* close to that, is what’s on the table - unless these plots were made with broken code or completely invalid scenarios for some reason:
https://github.com/heistp/l4s-tests#unsafety-in-shared-rfc3168-queues <https://github.com/heistp/l4s-tests#unsafety-in-shared-rfc3168-queues>

Cheers,
Michael


> We really, really must stop taking about fairness as equal flow sharing. That is not the reality today (e.g. video traffic can take larger shares on low bandwidth links and that keeps it working) and it is not desired at all because not all flows are equal!!! The endpoints know what is required to make their application work and as long as there is a circuit breaker that avoids complete starving or collapse, the evolution of the Internet depends on this control in the endpoint and future applications that potentially have very different requirements. Enforcing equal sharing in the network hinders this evolution.
> 
> I also would like to note that L4S is not only about lower latency. Latency is the huge problem we have in the Internet today because the current network was optimized for high bandwidth applications, however, many of the critical things we do on the Internet today actually is more sensitive to latency. This problem is still not fully solved, event hough smaller queues and AQM deployments are a good step in the right direction. L4S goes even further and the point is not only about reducing latency but to enable the deployment of a completely new congestion control regime with takes into account all the lessons learnt from e.g. data center deployment where we not have to be bounded by today's limitation of "old" congestion controls and co-existence. L4S is exactly a way to transmission to this new regime without starving "old" traffic but there also need to be incentives to actually move to the new world. That's what I would like to see and why I'm existed about L4S.
> 
> Mirja
> 
> 
> 
> 
> On 04.12.20, 12:49, "tsvwg on behalf of Michael Welzl" <[e-mail] on behalf of [e-mail]> wrote:
> 
> 
> 
>> On Dec 4, 2020, at 12:45 PM, Jonathan Morton <[e-mail]> wrote:
>> 
>>> On 4 Dec, 2020, at 1:33 pm, Michael Welzl <[e-mail]> wrote:
>>> 
>>> 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.
>> 
>> Right, there was a heuristic added to TCP Prague to (attempt to) detect if the bottleneck was RFC-3168 or L4S.  In the datasets from around March this year, we showed that it didn't work reliably, with both false-positive and false-negative results in a variety of reasonably common scenarios.  This led to both the L4S "benefits" being disabled, and a continuation of the harm to conventional flows, depending on which way the failure went.
>> 
>> The code is still there but has been disabled by default, so we're effectively back to not having it.  That is reflected in our latest test data.
>> 
>> I believe the current proposals from L4S are:
>> 
>> 1: Use the heuristic data in manual network-operations interventions, not automatically.
>> 
>> 2: Have TCP Prague treat longer-RTT paths as RFC-3168 but shorter ones as L4S.  I assume, charitably, that this would be accompanied by a change in ECT codepoint at origin.
>> 
>> Those proposals do not seem very convincing to me, but I am just one voice in this WG.
> 
>    Yeah, so I have added my voice for this particular issue.
> 
>    Cheers,
>    Michael
> 
>