Re: [tsvwg] WGLC: draft-ietf-tsvwg-nqb-14 - coexistence with L4S

Ruediger.Geib@telekom.de Thu, 03 November 2022 13:21 UTC

Return-Path: <Ruediger.Geib@telekom.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F138FC14CE3C for <tsvwg@ietfa.amsl.com>; Thu, 3 Nov 2022 06:21:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.675
X-Spam-Level:
X-Spam-Status: No, score=-7.675 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.571, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMPt6H7jv81k for <tsvwg@ietfa.amsl.com>; Thu, 3 Nov 2022 06:21:17 -0700 (PDT)
Received: from mailout11.telekom.de (mailout11.telekom.de [194.25.225.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF3C0C14CE45 for <tsvwg@ietf.org>; Thu, 3 Nov 2022 06:21:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1667481677; x=1699017677; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PA5JkDOfVEXtnWAB8ZpyKbY0o6HB/x8z9CVeeQG/IgA=; b=F3fZb8rSxS78aAOrlPz1Jh1n12CuZ8phVoslHsXajg06UNvfdnJHBsYH XI3dDvxm+wBvCek3UrRjKprgRWm6myg7ihgUaxdzCo1UXhhPlf/7PFWYm 3LENZaZmBjYRDz3mIDMkYIcgMYfvzSepXbu/4TBedWX3WpSl0ARqUGP/6 79A1qylB0J7NJ138f5mPL38q/ndXk9P1Q0zGaTjiqHXn3syDt1Ray+Sq6 nSVC/+mPS1TQP5XNzMxQGTfrq5Ni9yBHTLM/girZ5x8xlZW/jm0rKzP4k yg5cf2fbfK82YjtUlAwNa9aCFu8/Z78cmxtMmaLs34nCrZ5/HOuCqNLeF w==;
Received: from qdezc2.de.t-internal.com ([10.171.255.37]) by MAILOUT11.dmznet.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 03 Nov 2022 14:21:13 +0100
IronPort-SDR: hfMqY4GG6+E+5GOCoIaUT1dxbP6oOe2uhjVvCDpA34NJq994sqRwsthm9sYe96wIYtQIDoHzVf W55mQ0eaa1YVnAkoL/UvlCGFRbHbhirYg=
X-IronPort-AV: E=Sophos;i="5.96,235,1665439200"; d="scan'208";a="674604159"
X-MGA-submission: MDG0AZB8vlR2XBtOmss65jMx2TjJVyYWdHalA2VjXeFQLTdZVABwnJeTrHp4lCqwKoicdaMmltFVKG2Z5XbL088XVkF64kajE4a8+NEnXn2o0I/61/m6iyHSI2Lo8aJ73OBDNnKZBfA8v0m0mBJL0UIb30YmIhVz0cLFmxzompN4TQ==
Received: from he105715.emea1.cds.t-internal.com ([10.169.118.51]) by qde0ps.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-SHA256; 03 Nov 2022 14:21:13 +0100
Received: from HE105715.EMEA1.cds.t-internal.com (10.169.118.51) by HE105715.emea1.cds.t-internal.com (10.169.118.51) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Thu, 3 Nov 2022 14:21:13 +0100
Received: from HE104160.emea1.cds.t-internal.com (10.171.40.36) by HE105715.EMEA1.cds.t-internal.com (10.169.118.51) with Microsoft SMTP Server (TLS) id 15.0.1497.42 via Frontend Transport; Thu, 3 Nov 2022 14:21:13 +0100
Received: from DEU01-BE0-obe.outbound.protection.outlook.com (104.47.7.168) by O365mail03.telekom.de (172.30.0.232) with Microsoft SMTP Server (TLS) id 15.0.1497.36; Thu, 3 Nov 2022 14:21:12 +0100
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TfvEVSzD1eR7j7qaDCnFKpAGAuesg8PdLS6Q651it358Z2VHUIXeODQGZJ7jpwcn5szOzeUjUOkKLUm4GvMpkx5JUMFawAdw4CKCrIOCIigdUtVBJIHjo5ixytdVvdskXHUvffD1Cuc9DztDWc6aUiqUPvFwuRAgmT735u32n27mAJFlkUafrPrfySKL4acFApqvduomi4IA7+vIWOA+WU2BSLLaJt0maxl7C8QbkulRbVOzk9P+L7ovOOIVXdDwpYLxXJ2Umli+CqJSNQKQEhXByifu8GFF9LaVYddB+ELAi7QGuzSQmOTZzs4jr6zax45EtK8KFGDu+6iXWWT/iQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=PA5JkDOfVEXtnWAB8ZpyKbY0o6HB/x8z9CVeeQG/IgA=; b=A8+IKzdZ17zXRFs3j3P73yYUaDThsI3VnsEhhdXvUyt/SoheFnS2jDov1euCMq+C1QNq8OjWX9h7lKp8FXC1ON7IOa9OAg08K5Bw2lr16M7rsX9h/H+E13NenyOpv2ECcaMSD4WpRj5AY6e1np4qCUojgBOBs03Bp2Z/RBm6YE++kSrqX1Y56679n36JLN6479hnSPYz5Ielv5XBXLyVQEuRrqF5P/qWaIzZJwpD3WG1UxPdUcXisgcxrk9fFlWrQhzQcvItIG94pgR2fn+AzivpDg+kjNYWlx/1VMYTD3x4VG+My5gYUtYWJ9SaDDROqHpGq+JSkXFVNCwSR+r7bw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telekom.de; dmarc=pass action=none header.from=telekom.de; dkim=pass header.d=telekom.de; arc=none
Received: from FR2P281MB1527.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:8b::11) by BE1P281MB2885.DEUP281.PROD.OUTLOOK.COM (2603:10a6:b10:49::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5791.22; Thu, 3 Nov 2022 13:21:11 +0000
Received: from FR2P281MB1527.DEUP281.PROD.OUTLOOK.COM ([fe80::54f3:8989:c087:dabf]) by FR2P281MB1527.DEUP281.PROD.OUTLOOK.COM ([fe80::54f3:8989:c087:dabf%3]) with mapi id 15.20.5791.022; Thu, 3 Nov 2022 13:21:11 +0000
From: Ruediger.Geib@telekom.de
To: moeller0@gmx.de, g.white@CableLabs.com, roland.bless@kit.edu
CC: tsvwg@ietf.org
Thread-Topic: [tsvwg] WGLC: draft-ietf-tsvwg-nqb-14 - coexistence with L4S
Thread-Index: AQHY7soOuy2fDk2hyUuSbHs38vQrFK4rwyiAgAAOTwCAAHhAgIAAqoUAgAA2egA=
Date: Thu, 03 Nov 2022 13:21:11 +0000
Message-ID: <FR2P281MB15270F0067D8DB5A5EF04D269C389@FR2P281MB1527.DEUP281.PROD.OUTLOOK.COM>
References: <MN2PR19MB4045EDEFA651818318904ABA83399@MN2PR19MB4045.namprd19.prod.outlook.com> <FR2P281MB1527DF20C2FCD92CDDB848659C399@FR2P281MB1527.DEUP281.PROD.OUTLOOK.COM> <8ebe99bf-b2a1-b0b9-cca2-cf1e579aa611@kit.edu> <396150B7-171E-4B13-946E-B193E677EB99@gmx.de> <0D9FFEEA-3DC9-42FE-905D-2F48B8228FAA@cablelabs.com> <E59C341E-FD6A-48E7-9B8E-CBD6B311561C@gmx.de>
In-Reply-To: <E59C341E-FD6A-48E7-9B8E-CBD6B311561C@gmx.de>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=telekom.de;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: FR2P281MB1527:EE_|BE1P281MB2885:EE_
x-ms-office365-filtering-correlation-id: c090b5c8-a080-47f9-654c-08dabd9e46c0
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: VNcw7Wm80mmy8ysoFa+jkuvynyEWvBzdG5YJG8ejS0Xdps4k/ZJVX39EtgIAGMEEw2jAEQycAd63HdkgzhGO8p8prkuGTdz4quBxaJGr7ss9qm5a2VYB4kUR328hE56ldIKIuf9W/EVpSLisDOwGUY42ocjTfQ/8OL11vaMmSDsDrzY/97BJ/EEsG9JfizQ9qVrtVo0W1MABV/xMaCKXxBtKb7AUgSxgPVtgggQ78USgW67tiI84uv73X/BQeVx7+9Nf7j/D0ly0wIow7Fuu11kwn61N4Qh5CDnJZHyAV2anSNe3jB0n88AY4MxkGEAcL01frgMM1N5JWkGt8R8yjLJb8A5ToJPvgKjkmJqHJPrIqzTz9mBpha3KmazkTho96w09Y3EPoCMlTDLwSD8YkUPgzsGdekXOcPFH7MTqxpqQJWze24TxEHZ41/Rl4A0gHjpIKIgcWVdJ9sjf89bMuQKLuu/YStJK/8pXZKcZu0fr+bqW87RGWQrk18Otp+ivz6pkLERDniI8kzG62En+UlSsFfytJGl8fQkHEZiy/PuxT4QFjaTRhXRJ9pcTNO9vX/iSBdug0sORztZ/QVkncGpCsVNPDvZ33UMPjKGVsPaHRBFmryI5eXfiXs9f31gIc+vlbMDEQ7cxhyGfxKnQ5ikD2w0I+ylTAM+BEQnevbknc+mM+zeBcmlEOGFtze+9RMdAoUTL+hVPho4/jj9f63fuAs8aE5eol+qHPMjAT3jPdGcKb0j97cp2IoGbe9xrJTLRavQW7o+mZT2/9cXSOM/ChyGHnpfVi/3NOSaaetMhd9Orfeua0nSQuaIBf5dn
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:FR2P281MB1527.DEUP281.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230022)(4636009)(366004)(396003)(346002)(39860400002)(376002)(136003)(1590799012)(451199015)(66476007)(66446008)(41300700001)(76116006)(64756008)(66556008)(4326008)(8676002)(5660300002)(66946007)(316002)(52536014)(8936002)(30864003)(7696005)(6506007)(53546011)(478600001)(66574015)(71200400001)(9686003)(26005)(110136005)(966005)(55016003)(186003)(66899015)(2906002)(1580799009)(38100700002)(122000001)(83380400001)(85182001)(85202003)(33656002)(38070700005)(86362001)(82960400001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: zpG2rKSrVALZ0bNwaGo3yBUXcNEM4OuZ4EBk/6Cn5Rem1x8TdGU45xbBCbs0Zg6poOgslBsw+Gbd94S8o0FRhyFP6fDLI8Jz2x269xs2a2QI7TymPtHtcpE/JRLFn+tsnnaV2tI8ocfMLxrS2f11ih3f3mcrzpB1YGjsWoegy1Zp6zJu3W5izwmNKchNlKLuKAMz2j3LgnDRpDkpsktIEAv7S8LgsqQAXgNpFuaoc3JsusMtIttX6fK3Hk/INMke+l7vJ36GxGI6rCbPlFBiScNXdnc/GJnWSzJ1fM83LpuTi5A23I1r8vek9XhTApCcyajgG1bgYYXEN5DqchMYkfDFIHGJu3TF1pSAa9Jiw8K3+/H6nSRQ+CWssKDmjhxRsmvfVB3/At0u15RTmkffdsfJ22RVgSnhPTcgaUWZKRP59RYlAlWcO3peP+0e7hXMtVxzVNHg8wB6v6xfWG6IfmVQLbKpjrematM/SscxHrpTFUjbLiPkvWi9t8mu/xSpniv2sjYM9T8pO1GgIa9uszAB9VpiM5pGz64taJg9G8u+7BWfz0QhnBz2Z25TxoL2U0+WnwWGqyWNmajraXsbsswUdkcCBRAuLlfQTvyOH2CC3z+gxtM11FI56CGqNG/UOrGSZ9rl3dZ7+EX6p4rZPm+2K2IH9/KNh3a2FVvvC6tIj22z+ZZQGuorB8zMjtZRlhJw6Ztl8P4aPK7pPSjQwjcDlWRQ5rQ3jNu755XocmFvtS+bsWVr3D01sopSydOQeINzISmmM12b/8ZaY53ZP2IKlCWYibjuW2LTydimKa0N/cllDRHyGrEX+1WYaNMtteDi0xMs9Z1X5A103D+ZjqGSz7dn35LJ4CJ1rWZ2NDqFCHS02aif9gt16fSa97H8rE/RK4HOXBXtZVChVn1PZ+FGdj7r4jujXD/DgjduiLqvCqEA3G+1aqrQZkQIvMvlRQ9f36vdouCkM3AwX6+LgEnAEBQvX7zwh6qxm36OAddyUqs+pLQf8Rl59fPyGhe/WhYCspA6EVQkVgMis0nz6XOMgwT3YyicAYsWG7Ace4H3WcbIWW0NsrVg47ddSi/zxNsrfVdS3d/x338WkUa7IpSJfhME874smFH9RpaqSDikY8SsPUIRbu5adEbFWR01eBCnU7Qc/yOIAe2jdhhWRMjIwsoZ+yErxXr+B77Qosv5SFzIuvMa6vrk28JVNcNRTUUU87UFbIWcz8MqeDpfwUPohbTZxAUQf9t5S3BPzvVxhlM7Hf75peYe95KqqJlYPo0GE15CtuGy6OjHd481gXputh/tpI09zcfRBRrgdrVhuuxtAUcgke1CUcPw2myCz3UKhHhd/kzMQhCTquyPlTY1lDKoCe3CQU23sOauXLijW5kmua4SQkTl8dD/zG7W0Ybh5l5Wn/lEchTFoM/17i6hTjGxA32JxbZlkoE1KAl9iukp131XgW6BFXeQTyCvtorEnb/qfeh1NRrPO54l8yqkqOFJPR95RLah0jN6rCDaK5r90eqcFTW25PlZRKMqMvP2xbHosmX/v9Ca2NTnpNKWAfrJd12BH0IZfJfOjgMPfRLQukmXR/T3gu2v/UP3+fMD+edHMlDx4jnGmAYLBg==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: FR2P281MB1527.DEUP281.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: c090b5c8-a080-47f9-654c-08dabd9e46c0
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2022 13:21:11.5374 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: rTREerZ8gHYP+tOb22bAbznihJfR3kcKZllb9QXLjVGnEzZxSycRCrwiXbFefAOtQv8uKI2d8p2bvON0GHEvpTrwO8J5pk4AqD3UhoQ4eNU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BE1P281MB2885
X-OriginatorOrg: telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/hjna0f8mu4zyu6_STW7GLoRsXUc>
Subject: Re: [tsvwg] WGLC: draft-ietf-tsvwg-nqb-14 - coexistence with L4S
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Nov 2022 13:21:23 -0000

Dear colleagues,

thanks for exchanging views. My take from what I read

- there is no clear separating of the PHBs NQB and L4S in current standards.
- there is no standards text expressing whether or not setting NQB DSCP combined with L4S ECT 1 is conforming to current specs or not.

Sebastian, I'm having the impression too that an application combining NQB DSCP with L4S ECT 1 may gain unfair advantage over QB flows if competing for WiFi spectrum by DSCP NQB after having passed a coupled Queue scheduler by L4S ECT 1 scheduling. I note that NQB is a standards track RFC and I'd expect to have clarity, whether a new standard may cause harm for consumers, especially, if correct implementation of NQB conforming sender behaviour is left to application programmers. I'm not an application programmer and I wonder, whether application programmers generally are concerned with sender behaviour at all. In a majority of cases, I'd assume a transport protocol between network and application layers.

Regards,

Ruediger


Sebastian, RFC791 states:

Type of Service
........
    Precedence.  An independent measure of the importance of this
    datagram.

If you read the NQB draft, you'll additionally note that "importance" is frequently used there.



-----Ursprüngliche Nachricht-----
Von: tsvwg <tsvwg-bounces@ietf.org> Im Auftrag von Sebastian Moeller
Gesendet: Donnerstag, 3. November 2022 10:45
An: Greg White <g.white@CableLabs.com>
Cc: Bless, Roland (TM) <roland.bless@kit.edu>; tsvwg@ietf.org
Betreff: Re: [tsvwg] WGLC: draft-ietf-tsvwg-nqb-14 - coexistence with L4S



> On Nov 3, 2022, at 00:34, Greg White <g.white@CableLabs.com> wrote:
> 
> Hi all,
> 
> See my responses to the points that relate to the NQB draft below [GW].
> 
> -Greg
> 
> On 11/2/22, 10:24 AM, "tsvwg on behalf of Sebastian Moeller" <tsvwg-bounces@ietf.org on behalf of moeller0@gmx.de> wrote:
> 
>    Hi Roland,
> 
> 
>> On Nov 2, 2022, at 16:32, Bless, Roland (TM) <roland.bless@kit.edu> wrote:
>> 
>> Hi Rüdiger,
>> 
>> see below.
>> 
>> On 02.11.22 at 15:47 Ruediger.Geib@telekom.de wrote:
>>> 
>>> current draft text informs about a coexistence of NQB and L4S in the same LowDelay queue. Does this include that
>>> 	• NQB traffic should or could be marked by a DSCP and have ECN 1 set?
>>> 	• L4S traffic should or could have ECN 1 set and be marked by NQB DSCP?
>>> 
>>> The current text is not clear on that issue. As all marking is to be done by application programmers and this is a standards track doc, I’m interested for the draft to be crisp and clear to that point. Include or exclude simultaneous NQB&L4S  DSCP&ECN setting?
>> As far as I understand the draft, it is just an implementation detail:
>> NQB packets do not need to have ECT(1) set to be put into the L4S low-latency queue.
>> It is a node local mapping from the NQB DSCP(s) to the L4Slow-latency 
>> queue, i.e., they just use the already existing low-latency queue.
>> If I understand section 3.1 correctly, L4S flows should not be marked 
>> as NQB traffic since they violate the following condition:
>> 
>> " In contrast, Queue-Building (QB) flows include those that use TCP 
>> or QUIC, with Cubic, Reno or other TCP congestion control algorithms 
>> that probe for the link capacity and induce latency and loss as a result."
>> 
>> and especially L4S flows may also violate the (not so strict) condition of a 1Mbit/s limit.
> 
>    	[SM] That is IMHO incorrect at least generally. Just because TCP allows a flow to search for the capacity limit applications can (and do) decide to send less than possible. 
> 
> [GW] Sebastian's clarification here is correct.  An application could mark its packets with both ECT(1) and NQB if it meets the requirements for both.  This might be a relatively unusual case, but it isn't precluded.  To Ruediger's original request that the draft be crisp and clear on this point, we could add a statement in Section 3.3 that explains this. 

	[SM] Let's see how unusual that is going to be, after all NQB will result in a noticeable better low-latency performance over the ubiquitous WiFi networks (with the cost of that choice invisible to the application employing NQB marking unless the same application also establishes a CS0 parallel flow to asses whether the WiFi network is NQB-aware and whether NQB usage does not result in an overall throughput hit for the WiFi network (less aggregation will result in a total throughput loss)).


> 
> 
>              [SM]But I guess the bigger issue is that the L4S drafts have some words to say when and when not to set ECT(1):
> 
>    https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-29#page-14:
> 
> 
>    In order to coexist safely with other Internet traffic, a scalable
>       congestion control is not allowed to tag its packets with the ECT(1)
>       codepoint unless it complies with the following numbered requirements
>       and recommendations: [list skipped]
> 
>    So NQB flows would need a scalable congestion control to be allowed 
> to set ECT(1)
> 
> 
>    However usage of a "scalable congestion control" is not mandatory for setting ECT(1):
> 
>    As a condition for a host to send packets with the L4S identifier
>       (ECT(1)), it SHOULD implement a congestion control behaviour that
>       ensures that, in steady state, the average duration between induced
>       ECN marks does not increase as flow rate scales up, all other factors
>       being equal.  This is termed a scalable congestion control.
> 
> 
>    I would respectfully argue that that SHOULD is mighty weak...
> 
> 
>    BUT that L4S draft hasd the following ot say about NQB:
> 
>    To identify packets for just the scheduling treatment, it would be
>       inappropriate to use the L4S ECT(1) identifier, because such traffic
>       is unresponsive to ECN marking.  Examples of relevant non-ECN
>       identifiers are:
> 
>       *  address ranges of specific applications or hosts configured to be,
>          or known to be, safe, e.g. hard-coded IoT devices sending low
>          intensity traffic;
> 
>       *  certain low data-volume applications or protocols (e.g. ARP, 
> DNS);
> 
>       *  specific Diffserv codepoints that indicate traffic with limited
>          burstiness such as the EF (Expedited Forwarding [RFC3246]), Voice-
>          Admit [RFC5865] or proposed NQB (Non-Queue-
>          Building [I-D.ietf-tsvwg-nqb]) service classes or equivalent
>          local-use DSCPs (see [I-D.briscoe-tsvwg-l4s-diffserv]).
> 
>    It makes a ton of sense to mirror this in the NQB draft explicitly to
>    at least keep these two consistent.
> 
> [GW] I'd argue that mirroring this text in NQB isn't warranted, but I would agree that referencing it in NQB section 3.3 would be appropriate (and it's easier to ensure consistency that way).

	[SM2] I agree, mirroring was bad phrasing, what I meant is describe the same recommendation (only use ECT(1) for "scalable protocols", otherwise use the NQB DSCP for other flows fulfilling the L4S requirements) and add a reference. I see that "mirroring" sounds like I wanted to propose to copy the text verbatim, which I agree would be too much.

> 
> 
>> 
>> So my interpretation of the draft is that the answer to both 
>> questions is no, i.e., either NQB DSCP is set or ECT(1) is set. 
>> However, there should be a hint what to do in case both are set 
>> (following the L4S argument of letting DiffServ being orthogonal, ECT(1) should take precedence and the DSCP should be kept nevertheless).
> 
> [GW] While both the NQB draft and the RFC-to-be on ECN-L4S-ID talk about NQB and L4S traffic sharing a low latency queue, it isn't precluded that they be queued separately (i.e. an NQB queue and an L4S queue).  If they were to be queued separately in a node that supports both, I think I agree with you that ECT(1) should take precedence.  The only situation where I can imagine a debate about that would be if a node implemented Traffic Protection for the NQB queue, but didn't implement such a feature for the L4S queue. That said, I'm not super comfortable with starting down the path of making recommendations for this separation of L4S and NQB, since I think it opens a can of worms. For example, is the NQB queue given equal forwarding preference compared to the "Classic" queue in the L4S dual-queue, or is it given equal forwarding preference compared to the L4S/Classic dual-queue combination?  

	[SM2] I read "preference" as a synonym for the more usual "priority" here... why call it preference? (Genuine question: is this a usual nomenclature used in the field?)

> And, would we then want to also describe the use of 4 queues (instead of 3) to handle all four combinations independently (in which case there is no precedence between the two markings)?

	[SM2] I would respectfully propose that until we implement and test such a beast our description will be hardly better than what an implementer will be able to figure out in actual testing/use, so why try to describe something where at best we can offer theoretical musings? Fine if the observations are either trivial or obvious (but in which case not making them should cause little harm), but what if we recommend something on purely theoretical grounds which then in practice fails to meet its goals? IMHO RFCs should try to not speculate too much and stick to what has been supported by data and facts. 

Regards
	Sebastian


> 
>    	[SM] The bigger issue is that L4S AQMs are not mandated to check at all whether any marked traffic actually fulfills the requirements. So honestly it matters little whether a flow uses NQB of L4S to gain access to L4S high-priority queue. Without actual policing/enforcement any requirements in RFC are reduced to "requirements".
> 
>    Kind Regards
>    	Sebastian
> 
>    P.S.: I am convinced that this draft is not (yet) ready and should not pass last call right now.
> 
> 
>> 
>> Regards,
>> 
>> Roland
>> 
>>> 
>>> Von: tsvwg <tsvwg-bounces@ietf.org> Im Auftrag von Black, David
>>> Gesendet: Mittwoch, 2. November 2022 04:47
>>> An: tsvwg IETF list <tsvwg@ietf.org>
>>> Betreff: [tsvwg] WGLC: draft-ietf-tsvwg-nqb-14, closes 21 November 
>>> 2022
>>> 
>>> This email announces a TSVWG Working Group Last Call (WGLC) on:
>>> 
>>> A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services
>>>                        draft-ietf-tsvwg-nqb-14 
>>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/
>>> 
>>> This draft is intended to become a Proposed Standard RFC.
>>> 
>>> This WGLC will run through the end of the day on Monday, November 21.
>>> The WG will meet in London on Monday, November 7, while this WGLC is 
>>> in progress.
>>> 
>>> Comments should be sent to the tsvwg@ietf.org list, although purely 
>>> editorial comments may be sent directly to the authors. Please cc: 
>>> the WG chairs at tsvwg-chairs@ietf.org  if you would like the chairs 
>>> to track such editorial comments as part of the WGLC process.
>>> 
>>> No IPR disclosures have been submitted directly on this draft.
>>> 
>>> Thanks,
>>> David, Gorry and Marten
>>> (TSVWG Co-Chairs)