Subject: [tsvwg] plan for L4S issue #29

From: Wesley Eddy <[email-masked]>
Date: Fri, 31 Jul 2020 11:41:39 -0400

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.

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Fri, 31 Jul 2020 10:35:08 -0700 (PDT)

>     planned to be worked on in the Prague ICCRG draft.

I would think for good engineering to insure this issue is not left
unaddressed when you can open this issue or address it in said Prague
ICCRG draft is when you should be able to close it here?

Closing it here before then is a certain way to loose the issue.

>     be a different issue, and something maybe the operator guidelines

Failure of the bottleneck detection algorithm has been shown to
cause very undersirable behavior and does lead to a safety issue.

> ticket here.? Please let me know in the next week if I've misunderstood 

When there is a place to track this in ICCRG you can close it here
AFTER it has been addressed.

Again I find it that issues are simply not actually being addressed,
but rather just shoved off "until later."  

-- 
Rod Grimes                                                 [email-masked]

---

From: Jonathan Morton <[email-masked]>
Date: Fri, 31 Jul 2020 21:03:00 +0300

> On 31 Jul, 2020, at 6:41 pm, Wesley Eddy <[email-masked]> wrote:
> 
> Hello, ticket #29 for the L4S documents is about classic bottleneck detection misidentifying L4S queues as classic ECN queues.
> 
> 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.

Presently, the Prague congestion control algorithm is unsafe on the Internet without a properly functioning classic-bottleneck detection heuristic.  Additionally, the classic-bottleneck detection heuristic that has been published and demonstrated does not function properly.  This combination of facts absolutely *is* a blocker for WGLC.

Therefore, this issue should not be closed until it has been concretely addressed.

 - Jonathan Morton

---

From: Pete Heist <[email-masked]>
Date: Fri, 31 Jul 2020 20:52:56 +0200

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 <[email-masked]> wrote:
>