[tcpPrague] Realistic Queue delay targets

"Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net> Sun, 01 November 2020 20:24 UTC

Return-Path: <ietf@gndrsh.dnsmgr.net>
X-Original-To: tcpprague@ietfa.amsl.com
Delivered-To: tcpprague@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 62F653A0E5D; Sun, 1 Nov 2020 12:24:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.623
X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.275, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id vxEiYLDbomag; Sun, 1 Nov 2020 12:24:33 -0800 (PST)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ACCB3A0C98; Sun, 1 Nov 2020 12:24:32 -0800 (PST)
Received: from gndrsh.dnsmgr.net (localhost []) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 0A1KNkWH011765; Sun, 1 Nov 2020 12:23:46 -0800 (PST) (envelope-from ietf@gndrsh.dnsmgr.net)
Received: (from ietf@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 0A1KNkue011764; Sun, 1 Nov 2020 12:23:46 -0800 (PST) (envelope-from ietf)
From: "Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net>
Message-Id: <202011012023.0A1KNkue011764@gndrsh.dnsmgr.net>
In-Reply-To: <69a73308-6718-7304-be24-0eb84f77e50d@bobbriscoe.net>
To: Bob Briscoe <ietf@bobbriscoe.net>
Date: Sun, 01 Nov 2020 12:23:46 -0800
CC: Christian Huitema <huitema@huitema.net>, tsvwg IETF list <tsvwg@ietf.org>, iccrg IRTF list <iccrg@irtf.org>, TCP Prague List <tcpPrague@ietf.org>, "De Schepper, Koen (Koen)" <koen.de_schepper@nokia.com>
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: <https://mailarchive.ietf.org/arch/msg/tcpprague/fwWDDRqMcn0ZN7-TY8KHL99IYEw>
Subject: [tcpPrague] Realistic Queue delay targets
X-BeenThere: tcpprague@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." <tcpprague.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpprague/>
List-Post: <mailto:tcpprague@ietf.org>
List-Help: <mailto:tcpprague-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Nov 2020 20:24:35 -0000


> Christian,
> I've changed the subject line given it's no longer appropriate.
> See inline tagged [BB]...

And I am changing it again... as only addressing a statement that
I have great concerns about.

See inline ragged [RWG]

> On 01/11/2020 01:07, Christian Huitema wrote:
... [ much text deleted ] ...

> [BB] Yes, once the IETF assigns the codepoint, BBRv2 will be 'allowed' 
> to send packets over the Internet as ECT(1). Then, yes, an L4S DualQ 
> Coupled AQM will classify BBRv2 packets into the L4S queue. This should 
> have a very shallow ECN marking threshold (500us - 1ms), so even if the 
> flow (whether QUIC or TCP) is flying just under the available capacity, 
> bunching of packets means it is unlikely to completely avoid ECN marking 
> between probes. If it could avoid ECN marking, you are right that it 
> would get a bump of ECN marks during the probe. I haven't studied the 
> code, but when it experiences ECN marking I believe it switches into an 
> L4S ECN mode for a while, and uses ECN rather than delay probing to 
> track available capacity. I assume it switches back to BBR's delay 
> probing mode if it gets no ECN for a while (e.g. the bottleneck might 
> have moved). But I haven't looked at BBRv2's ECN behaviour in detail.

 [RWG] I have great concern about this 500uS to 1mS ECN marking threshold
given that I have recently learned the latest WiFi standards actually
run with a packet aggregation time of 4mS thus making it probably
impossible to have such traffic work in such a targeted low latency queue.

 [RWG] Has any consideration been given to what is already deployed on
the Internet as link layer technologies that would preclude the
operation of the L4S low latency queue?

Rod Grimes                                                 rgrimes@freebsd.org