Re: [tsvwg] plan for L4S issue #29

["De Schepper, Koen (Nokia - BE/Antwerp)" <[e-mail]>]

Hi Wes, Pete,

I think to make progress on avoiding both false negatives and false positives, a good view on the conditions that cause problems is needed. So we better have the means to detect the real life impact of Classic-ECN-FIFO deployments. This means we need to be able to switch off Classic ECN detection (under controlled or even known conditions).

Another point is that it would be useful also to have all control variables of the existing implementation configurable for everyone willing to further experiment (without necessarily needing to change code). As I understood, the right tuning of these can bring a lot of further improvement opportunities. Also depending on a typical deployment, these parameters could be tuned for that specific targeted case.

So the resolution of this issue is exactly to facilitate further improving the detection algorithm (preferably via tuning), and being able to disable it when conditions are controlled or safe to avoid these false negatives.

I think these are topics that can be covered by the Operational Guidelines draft.

Regards,
Koen.

-----Original Message-----
From: tsvwg <[e-mail]> On Behalf Of Pete Heist
Sent: Friday, July 31, 2020 8:53 PM
To: Wesley Eddy <[e-mail]>
Cc: [e-mail]
Subject: Re: [tsvwg] plan for L4S issue #29

Hi Wesley,

One thing I noticed during testing was that the current implementation of TCP Prague in Linux allows disabling bottleneck detection through the prague_ecn_fallback kernel module parameter (https://github.com/L4STeam/linux/blob/0e7cf8acb318873c3f61084453f8da15b2e398be/net/ipv4/tcp_prague.c, line 158). I don’t know if that was left in only for testing.

In section 6.3.3 of l4s-arch, there is discussion around classic bottleneck detection. Since I don’t see an explicit MUST that it remain enabled (although I do see the text “an L4S sender will have to fall back to…”), it’s not completely clear to me if it’s actually required to be implemented and permanently enabled in all implementations. If it is, I suppose the implementation should reflect that also.

While I feel it best that detection identifies both types of queues accurately, if bottleneck detection were both an explicit MUST in the text *and* not possible to disable in any implementation, I think that would make the misidentification of L4S queues as classic ECN queues less of a safety concern, since it would be impossible to turn off. It would remain an issue for the architecture overall though.

Hope that helps...

Pete

> On Jul 31, 2020, at 5:41 PM, Wesley Eddy <[e-mail]> wrote:
> 
> Hello, ticket #29 for the L4S documents is about classic bottleneck detection misidentifying L4S queues as classic ECN queues.
> 
> https://trac.ietf.org/trac/tsvwg/ticket/29
> 
> In contrast to other issues, it doesn't seem like this should block a WGLC on the L4S drafts.
> 
> 	• It is specific to classic bottleneck detection algorithm, which is planned to be worked on in the Prague ICCRG draft.
> 	• The result is sometimes failing to achieve the best possible L4S behavior, but doesn't seem to be an Internet safety issue.  This resulting in people turning off classic bottleneck detection would be a different issue, and something maybe the operator guidelines would address.
> 	• It seems like it can be worked on further in the course of L4S experimentation, without negative effects to others.
> So, I believe we should track this work in the ICCRG, and close the ticket here.  Please let me know in the next week if I've misunderstood any aspect of this and it should remain open.
> 
>