Re: [tsvwg] plan for L4S issue #29

"Rodney W. Grimes" <> Fri, 31 July 2020 17:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 065EE3A0BD7 for <>; Fri, 31 Jul 2020 10:35:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c4BxQhDvT25X for <>; Fri, 31 Jul 2020 10:35:10 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7A1013A096B for <>; Fri, 31 Jul 2020 10:35:10 -0700 (PDT)
Received: from (localhost []) by (8.13.3/8.13.3) with ESMTP id 06VHZ9V0087684; Fri, 31 Jul 2020 10:35:09 -0700 (PDT) (envelope-from
Received: (from ietf@localhost) by (8.13.3/8.13.3/Submit) id 06VHZ8El087683; Fri, 31 Jul 2020 10:35:08 -0700 (PDT) (envelope-from ietf)
From: "Rodney W. Grimes" <>
Message-Id: <>
In-Reply-To: <>
To: Wesley Eddy <>
Date: Fri, 31 Jul 2020 10:35:08 -0700 (PDT)
CC: "" <>
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Archived-At: <>
Subject: Re: [tsvwg] plan for L4S issue #29
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 31 Jul 2020 17:35:13 -0000

> 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.

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.

>   * 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.

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

>   * 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.

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