[tsvwg] NQB recommendations for WiFi. [was: Qs on your 5G L4S slides]

Greg White <g.white@CableLabs.com> Tue, 16 March 2021 14:27 UTC

Return-Path: <g.white@CableLabs.com>
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 A7B543A0FCC for <tsvwg@ietfa.amsl.com>; Tue, 16 Mar 2021 07:27:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cablelabs.com
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 5Oe7iS1gPpN7 for <tsvwg@ietfa.amsl.com>; Tue, 16 Mar 2021 07:27:20 -0700 (PDT)
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2129.outbound.protection.outlook.com [40.107.244.129]) (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 CF1693A0FCB for <tsvwg@ietf.org>; Tue, 16 Mar 2021 07:27:20 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YhubssrfeeppbRrrWn2pWHcDGG8cAvCOui4eWFpbqJ5C7b6XsEDuUttZCFQzyRcoW4mFoPjt69MphR7rB/eosCX8xMisNnSF/dABhJBlHqrRSMRGWBpytXz1/z//hbZGEFkS4d/lxb/spev6a42RkZxUeIpx/kh5Ud5YPmqJzijhbC1n5QupL3iOIMwZaAiPo6jsA9mGvSNYkusx358i+hhNmEMQTqgctWCiJ0Kx0P7+4LIAJKizjkUhd7RfvTpAOkgMubofWMtq7Ias2A8eQft6g/MEFXXOnUhAs/uRZekN+kpZtPcVw99xqHy1hTfy91oe5EoIDXuHnG4ghVkwkg==
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-SenderADCheck; bh=92V/P/nF1ZDW31ZKo9o3lZUzu+KA05SputcaPuHYd/0=; b=LvzjYGvHQlBsQFsAJX46D1KJZovWjI0epESA/OhHXb2Z5iMpQumrX11CJQ6WAa1j72wLYqKgyCIvHa0eRGi1Oyz4E3l2Zu/VC0gQmENm6Dya2Unzi1VaKhdw8MK4jo8ZZyVVIbEGsPVfi2btCejFn9W3yiYATGXiCoEz5ZhrSXRIzLm/AkbDmMmy5WplDqutQLyuQ7hup++Rfr1EtMfSfJm1AzLyfeWKnWeYo/Hva0IRWmcAent2UMnhgGoZ7DxhxegzsmOLnbJoPmcF0NlbNJvEWoaMMZdzPbSblzLyIsk20o5HL0NOyamPPa/Re7SAtanKfwZZWT0wvaRctUfazg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cablelabs.com; dmarc=pass action=none header.from=cablelabs.com; dkim=pass header.d=cablelabs.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cablelabs.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=92V/P/nF1ZDW31ZKo9o3lZUzu+KA05SputcaPuHYd/0=; b=Ta1wHTgdnGbZWC+dbe22b5lMNu344+FCXiVGATLNqipMLiAnonu5Aj83s5E5TFvrHSQMF8q7fwjrDXUYwSEAAEQdwihmPaosDXm1kbrAhHrTvrqbz+z2e1JhuRo99INNL6XF/lrZdoT1k9+ZPWEMnc1MTHVpymVWZ3y/nduCIvEKqdlvn/II+gRPV9m5d6ZFzWbfGOjVD6fWA7TlLu+CHWFUzEAyi4n+54NbZvarHKTvpJZ1bYe1FjQi5SgVi0Wj0ORi+1nTsxm/DRZ+7ICon0RtBzS02NFaiHftgf8h9rk/sh4KFZixlgD7W6d3O9Z1Wnc3kA4vm37tqWu3NyyD6Q==
Received: from CY4PR06MB2821.namprd06.prod.outlook.com (2603:10b6:903:130::11) by CY4PR06MB2805.namprd06.prod.outlook.com (2603:10b6:903:132::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3933.32; Tue, 16 Mar 2021 14:27:17 +0000
Received: from CY4PR06MB2821.namprd06.prod.outlook.com ([fe80::fd1d:5577:b489:745c]) by CY4PR06MB2821.namprd06.prod.outlook.com ([fe80::fd1d:5577:b489:745c%10]) with mapi id 15.20.3933.032; Tue, 16 Mar 2021 14:27:17 +0000
From: Greg White <g.white@CableLabs.com>
To: Sebastian Moeller <moeller0@gmx.de>
CC: Bob Briscoe <ietf@bobbriscoe.net>, "Ruediger.Geib@telekom.de" <Ruediger.Geib@telekom.de>, "ingemar.s.johansson@ericsson.com" <ingemar.s.johansson@ericsson.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: NQB recommendations for WiFi. [was: Qs on your 5G L4S slides]
Thread-Index: AQHXGnB3iS8+lypwwUGeFNqnXB+nAA==
Date: Tue, 16 Mar 2021 14:27:17 +0000
Message-ID: <23FBC84F-FF44-439A-AB7B-40A4DA75AAB6@cablelabs.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.44.20121301
authentication-results: gmx.de; dkim=none (message not signed) header.d=none;gmx.de; dmarc=none action=none header.from=CableLabs.com;
x-originating-ip: [73.243.9.160]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6947e397-9b4a-426b-2b4b-08d8e8879a29
x-ms-traffictypediagnostic: CY4PR06MB2805:
x-microsoft-antispam-prvs: <CY4PR06MB2805B17A6B0CE74E3939A78CEE6B9@CY4PR06MB2805.namprd06.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: lrlUs1Xk6tDlpPSxWt+uWTInKB+PXbPcEcl9R6Tbmq86M13RYzb9g3wW8aQODOMUey10PvcL9off6xl2rouFgEbLUjvEZQv79xHQrGfMTt5XUA9qqiO2PTxEZWMoUglbHS08ZPt7YcVGFbG0BN+UQk8rnlGUHQUAYWvrwt00uGyV7YbBQXlgpkV1LOjPm/WDnqmY8oq6XgmJcOUJiU0k8ypX82KMoa8uyNYSeNB1c+sGWQ1ojGNXuM1hAuHnm7zXbETGEcaahfEzq7II6WTB0OYpCVg8e6bN7IalfAUO54c1o3XTFOnbMpy0K5xJLi3w12s6o6WwJdjMambN4smWP9hGJax1b8bJziqi69CAdriCeeFySU+xlZSHSUTB+n/rBCtmYU7jU7jS7UqxyW9HCPSOUwmQbUi/gm4THQdMML8mvbQ8Plu485NyeIYGayATMMI+0FOkJDwALWaa0DDny23f/vNs+EcOLRk4SWIXQ/lkoHJnHjfKb6wCruq4BQEWNoaqBV1oeg6IdB4GRjoh3k2CuDgNYTFwJQZpdNlPoQ1SDA1UnkG85PPeLVGBm/hVWyKI1cEZBdR0hNoxFgf+HOSF6XVG0nbEjf5UxM6J1zXa5tqecSQ8aawfZTrQgWcJV4Hhi24TxCNWiXoO+51Kbw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR06MB2821.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(6029001)(39830400003)(366004)(136003)(396003)(376002)(346002)(71200400001)(6506007)(6916009)(186003)(86362001)(53546011)(6486002)(26005)(33656002)(66946007)(4326008)(6512007)(76116006)(36756003)(66556008)(66446008)(2616005)(5660300002)(478600001)(8936002)(316002)(54906003)(2906002)(8676002)(83380400001)(66476007)(64756008)(66574015)(85282002)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: VbBfHGidJvjfSxdccHLIk0p/2gssO7VW4ta23ERf9JbASxWxB0dOEgcNUQJVAhMMZSWqiRlbgiDU7MC2+OJUFoZ8ZFijgCiQfElMUasYErNqI23s5fV3k3JSqDK/DAUCGVbZls7Gi/g514yNgjdkYS2ls8rrimgt2Par5fu+/Kk5ozvk3lc1wPmmzUH+AncYYj0ColceCHo9Oc9iBbmuV5RGDQ8ibO08pZR2VXrs/03SYhP0vp+3BgTacZHQuPOeb8/fmgHOYEiDF+vRIgFHMZm/YNMLJnMqpNnxVqSxtz/FC3KVQdmPCVHul6B57lTQVS49tLpsf8CeKTtcGWEZNp+gWJZxNlDeoOr3XUBHPkPDqrtCqLSRiojdDKudUY6Xwd01BRpuXfK8JzCi5pRHhRddcpyxNMi2lO9lE7IVEeIovouzmssz5hrITFAkP8huDTaiAftktwy4MgNCjpGZuhiDWPTPmispwjFYNrsWaMwZ+C6Alp5s8bHbd3uwXkWXZQHnjMV70mFQ9M5CAw4TEcXm5MNiCAoZDLaDwrjAplLkCLOU5SVsj9kpNIF5fQwvVtH9nPwjUFmBFwlIeUFk8mWUnXIhU6WAsrcIoHDho2ShMDnDPzhM3iG9WWLzoyEJTGntDT5tvWJ0kztE4oEJ8bBDWNjbRZaiOvU+pF+6+P4CzBnsMAyFS+Jgszc4EyNSaSCc86MieHe+6E+Vd5zxkfj1GgG+KlDe6A89BqHmF/m69P+JpygrqLkppM03JskX
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <A8D3726EC820FA449FD422E8C88FB95F@namprd06.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: cablelabs.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CY4PR06MB2821.namprd06.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6947e397-9b4a-426b-2b4b-08d8e8879a29
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2021 14:27:17.6204 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: ce4fbcd1-1d81-4af0-ad0b-2998c441e160
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: IEJ1B8i6G8+t5BmqJAZmPS403XreD2/T1aJpVNm6JDnfc8rXj2wWM4hGAoTbbh4zPV4F1QXZLRsUAC7FTNIA8w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR06MB2805
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/3por3k49hDIqXOsmAYA-aDNFoc0>
Subject: [tsvwg] NQB recommendations for WiFi. [was: Qs on your 5G L4S slides]
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 16 Mar 2021 14:27:23 -0000

Changing the subject line because this is no longer related to Ingemar's 5G L4S slides.

See [GW2].

On 3/15/21, 4:37 PM, "Sebastian Moeller" <moeller0@gmx.de> wrote:

    Hi Greg,

    see [SM] below.


    > On Mar 15, 2021, at 22:57, Greg White <g.white@CableLabs.com> wrote:
    > 
    > Inline [GW].
[snip]
    > [GW] The NQB draft does NOT make any recommendations on treatment of L4S-ECN marked traffic.  In addition, for NQB traffic it recommends to map it into a separate queue in the best effort access category (AC_BE).

    	[SM] Which is sweet, but for almost 100% of deployed APs that is not going to happen, not eve the tinker friendly opensource OpenWrt APs allow to change the weights of the ACs.

[GW2] What do you mean?  I've personally done it with multiple off-the-shelf consumer grade devices (using multiple chipsets), and measured per-AC throughput with the EDCA params configured as described in the draft.  There was only one model that I came across where setting the EDCA parameters was not possible, and that implementation was clearly broken because it gave BE higher priority than VI by default.  I sent you an email with this result a year ago.  Plus, I believe that the majority of broadband providers in the world either deploy an integrated gateway or provide a WiFI router to their customers so they (the provider) have the ability to set these params themselves.  

    >  It only utilizes the video access category as a way to interoperate with existing WiFi gear (including RFC8325 gear*), and in that case it recommends that the EDCA parameters be configured so that AC_VI gets the same bandwidth priority as AC_BE.

    	[SM] But we all know that this recommendation will not actually to changes in a noticeable number of already deployed APs. Let's not kid ourselves that the update problem magically disappears just because it would be nic; this does not work for safety fixes, why should it work any better for new features?

[GW2]  You are way out on a limb here.  The recommendations in the draft currently are that ISPs use a codepoint at interconnection that (if left unmodified) would map to AC_BE.  It then mandates that, by default, access network gear ensure that such a codepoint is used. It only recommends that an ISP re-mark with a codepoint that maps to AC_VI when appropriate safeguards are in place, which could be a combination of policing, EDCA configuration, or full NQB PHB compliance.  What is your remaining safety concern!?


    > 
    > *this has gotten me thinking that it would be worth further discussion on NQB recommendations for RFC8325 gear.  Since the recommendation in the NQB draft would amount to a change to the implementation, perhaps the draft should recommend that 8325 gear (if possible) maps NQB to a separate queue in AC_BE, and only provides the AC_VI option as a backstop in case the implementation can’t provide a separate queue.

    	[SM] Again sounds sane, unless we look at the deployed base.

[GW2] What do you mean? AFAIK there are no RFC8325 devices deployed currently.  Are you saying that it is insane for anyone to implement RFC8325?  Or are you saying that it is insane for us to provide recommendations to them?  Surely you don't think that all of the WiFi gear that will ever be deployed is already in the field.  

    > 
    > L4S is also walking into the WiFi environment as it finds it. With today's non-L4S products, I would also recommend that the L4S-ECN codepoints are mapped to the video access category, if possible. 
    > Nokia's latest WiFi products (in the 'Beacon' range) already include an L4S DualQ Coupled AQM. And as other L4S WiFi products come out, the coupling will introduce the recommended congestion signals that can be used as back-pressure against the priority scheduler. Users don't want to abuse scheduling priority at the expense of the balance between their own applications. But they have no choice until there's a mechanism that allows their applications to balance against other apps.
    > 
    > 
    > [GW] In my view the preferred option is for the dual-queue coupled AQM to be implemented within a single access category (e.g. AC_BE).  Utilizing AC_VI for L4S-ECN traffic would eliminate the ability to provide backpressure, since the BE queue in one STA can’t easily be coupled to the VI queue in another.

    [SM] Not that I want to defend ab-using AC_VI for L4S (as I said NQB with its aim for low rate flows has some justification for using AC_VI, assuming sufficiently strict admission control), but back-pessure in WiFI between all entities only happens via airtime access and that means you mainly compete with senders using the same AC, no?

[GW2] Well that statement isn't exactly true (unless I misunderstood you), but the point is that dual-q coupled AQM gives a scheduling weight to L4S traffic, but then subjects that traffic to CE marking driven by the classic queue (the backpressure).  If you wanted to use default-configured AC_VI for L4S in order to provide the scheduling weight part, you wouldn't be able to get the backpressure since there is no way in WiFi for the classic (i.e. BE) queue in one device to directly influence the CE marking of traffic in another device's VI queue.  So, the better approach would be to only give L4S traffic scheduling weight within the device (i.e. a separate queue in BE) where you can provide the backpressure.