[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [69.59.192.140]) (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 [127.0.0.1]) 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
Bob, > 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? Regards, -- Rod Grimes rgrimes@freebsd.org
- [tcpPrague] ecn-l4s-id: Proposed Changed to Norma… Bob Briscoe
- Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Chan… Sebastian Moeller
- Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Chan… Christian Huitema
- Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Chan… De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [tcpPrague] ecn-l4s-id: Proposed Changed to N… Christian Huitema
- Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Chan… Sebastian Moeller
- Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Chan… Sebastian Moeller
- [tcpPrague] L4S and BBR (was: [iccrg] ecn-l4s-id:… Bob Briscoe
- Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Chan… Jonathan Morton
- Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Chan… Christian Huitema
- Re: [tcpPrague] L4S and BBR (was: [iccrg] ecn-l4s… Christian Huitema
- Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Chan… Gorry Fairhurst
- [tcpPrague] Realistic Queue delay targets Rodney W. Grimes
- Re: [tcpPrague] [tsvwg] L4S and BBR (was: [iccrg]… Sebastian Moeller
- Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Chan… De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [tcpPrague] L4S and QUIC Bob Briscoe
- Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Chan… Christian Huitema
- Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Chan… Jonathan Morton
- Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Chan… Greg White
- Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Chan… Christian Huitema
- Re: [tcpPrague] [iccrg] Realistic Queue delay tar… Ingemar Johansson S
- Re: [tcpPrague] [tsvwg] [iccrg] Realistic Queue d… Sebastian Moeller
- Re: [tcpPrague] [tsvwg] [iccrg] Realistic Queue d… Ingemar Johansson S
- Re: [tcpPrague] [tsvwg] [iccrg] Realistic Queue d… Sebastian Moeller
- Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Chan… De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Chan… De Schepper, Koen (Nokia - BE/Antwerp)