Re: [tsvwg] draft-ietf-tsvwg-nqb, more questions

"Black, David" <David.Black@dell.com> Thu, 07 November 2019 20:02 UTC

Return-Path: <David.Black@dell.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 70225120D2E for <tsvwg@ietfa.amsl.com>; Thu, 7 Nov 2019 12:02:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=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=dell.com header.b=McF7FxZN; dkim=pass (1024-bit key) header.d=dell.onmicrosoft.com header.b=NY3DhCmj
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 H2cyiuVTtv_X for <tsvwg@ietfa.amsl.com>; Thu, 7 Nov 2019 12:02:55 -0800 (PST)
Received: from mx0b-00154904.pphosted.com (mx0b-00154904.pphosted.com [148.163.137.20]) (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 2BF6D120044 for <tsvwg@ietf.org>; Thu, 7 Nov 2019 12:02:55 -0800 (PST)
Received: from pps.filterd (m0170397.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xA7JsqlZ015652; Thu, 7 Nov 2019 15:02:50 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=smtpout1; bh=HwqWs9db3BZi+67qPcrA3OGqgswNqm2ZxEoa7jUQyvk=; b=McF7FxZNYLwWXfHkcOWAhKsDJthrXHFC2YN/Ot/jHsT3Su8sPwuuwUupJrF5PnvO2/1g 4eD1qZwj1BGEYww0V3tZJctIC1PDxSQ674ARMgPTItEVBfip1ofmx8DfDFZr681vA3de Me82dKtFDf7Z2T6V1YrEG9FbM4n66Nxr2rCE2Y0NGIqlFReeXxGDiPmbRE1ydTmAb93d vOTbGGVfqcgOmBubEWf5A7vE8wPKddXU0GFVPgj2chb6s0VQ2Qmlj551yUXIf7UV//71 YRHtdKDOBRwdupmqm/0DEqHLEeXl54eC4yHnuehNIbfUmI93dYC9iAFTr7kL7a+oDaWp bw==
Received: from mx0a-00154901.pphosted.com (mx0a-00154901.pphosted.com [67.231.149.39]) by mx0b-00154904.pphosted.com with ESMTP id 2w41uwpp4q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 07 Nov 2019 15:02:50 -0500
Received: from pps.filterd (m0142699.ppops.net [127.0.0.1]) by mx0a-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xA7JriXU144808; Thu, 7 Nov 2019 15:02:49 -0500
Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp2053.outbound.protection.outlook.com [104.47.36.53]) by mx0a-00154901.pphosted.com with ESMTP id 2w41wnejyn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 07 Nov 2019 15:02:49 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BoYB57MNHqsXqePNjMRzABFk1xgRs9+axMDlL3t3yJaBTmRC7zAAZZvYjFHpHTVtnj8KFj6pwKixY6LOHN98cqKsu3/pzAqbChpyWOQCS4gK3C8yNOcmSnpNQbOZqB4RnjCVLk5KMZgXqdt3F+g7s/7JHKe9RbvVG5tG8YwKfCrJNfELNy047WygGH6lb6rpDJQTNBvsvaBF63DD1rrj6+IeUi87UEl2dhQrnYP7jnq5FYsn+E3F81ukBM5G4ZrUtVVQ0ZjwAKIWoFqHSGDi70EAoXMCpqX+WIgQNZmILXyhaMc7Jhi15p+2Lqf63aRuuIqM6TxsuxIQmI6aGkleuA==
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=HwqWs9db3BZi+67qPcrA3OGqgswNqm2ZxEoa7jUQyvk=; b=YpPAx+Vi7IgLL2aKWn/baJohMPwk/pJJx1a00KEdM5TVrWMz7wtlb9lXuGElNkP4hr1oVJMWPes6ftfJv/MJhCeTxdJLGj5fl55rY4f2z5iH6cqcaAOyI58tbpraxm8obdxIclq1zifs4/GhxIMWW3+TDC8bgRl9X30fsqIYrvwYyOq1CQvfYCgCFTFd5kMQhB07jEQZVAT4oxBaexH2nGDDYgO9y0Q27pyVJk5CpGwQJSGPraTCYa/J6rcdYZZRrvKWcrJLdZ3Di7dTKEX5vOqJtIVpQOskXyK9yvYPSrui+kjnytaPj35OstMSl953nuLCMPs9lTGNlanp5Pdvrg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dell.com; dmarc=pass action=none header.from=dell.com; dkim=pass header.d=dell.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Dell.onmicrosoft.com; s=selector1-Dell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HwqWs9db3BZi+67qPcrA3OGqgswNqm2ZxEoa7jUQyvk=; b=NY3DhCmjPOBef9Gm0jHIeMtibWA//w4h/xlwTpF49nTLAAtbUu2eeMw8Jia5Wj3TkPhKhvwaiF4WztxS7zB52YvebKhL8Yj54Bc0b0W4Av1Izhkkbsr96S9DQY/kWomEweo8/KR1lLqXMjgAbq2Y8/K7gOFF315GeN8FUv6BIfM=
Received: from MN2PR19MB4045.namprd19.prod.outlook.com (10.186.145.137) by MN2PR19MB3101.namprd19.prod.outlook.com (10.255.181.205) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2408.24; Thu, 7 Nov 2019 20:02:45 +0000
Received: from MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::8893:d435:ce32:3594]) by MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::8893:d435:ce32:3594%6]) with mapi id 15.20.2430.020; Thu, 7 Nov 2019 20:02:45 +0000
From: "Black, David" <David.Black@dell.com>
To: Sebastian Moeller <moeller0@gmx.de>, Greg White <g.white@CableLabs.com>
CC: tsvwg IETF list <tsvwg@ietf.org>, "Black, David" <David.Black@dell.com>
Thread-Topic: [tsvwg] draft-ietf-tsvwg-nqb, more questions
Thread-Index: AQHVk168g4JkWCsXvkKSWKsK//1LrKd7uScAgACOhICAA90NQA==
Date: Thu, 7 Nov 2019 20:02:45 +0000
Message-ID: <MN2PR19MB4045003442DB1E7643C96DD083780@MN2PR19MB4045.namprd19.prod.outlook.com>
References: <90ED003C-CC25-4ED4-90D8-BA572E39D852@gmx.de> <AC0FF00A-9AA7-4582-8F96-1E4E27AEB8D8@cablelabs.com> <20DE8A61-AD71-4C60-A90E-1CCB22E3C6BE@gmx.de>
In-Reply-To: <20DE8A61-AD71-4C60-A90E-1CCB22E3C6BE@gmx.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=david.black@emc.com; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2019-11-07T20:02:00.8916837Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual; aiplabel=External Public
x-originating-ip: [168.159.213.213]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 14cf2042-6152-4b5d-6796-08d763bd74c7
x-ms-traffictypediagnostic: MN2PR19MB3101:
x-ms-exchange-purlcount: 1
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MN2PR19MB31017F30367A65C20185237D83780@MN2PR19MB3101.namprd19.prod.outlook.com>
x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4
x-ms-oob-tlc-oobclassifiers: OLM:6790;
x-forefront-prvs: 0214EB3F68
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(136003)(376002)(346002)(39860400002)(13464003)(7502003)(52314003)(189003)(199004)(6506007)(76116006)(66574012)(446003)(66446008)(66066001)(25786009)(81166006)(3846002)(71200400001)(74316002)(305945005)(107886003)(99286004)(478600001)(9686003)(561944003)(52536014)(5660300002)(256004)(14454004)(4326008)(14444005)(33656002)(71190400001)(6306002)(26005)(486006)(64756008)(81156014)(102836004)(8676002)(55016002)(7696005)(76176011)(11346002)(6116002)(6246003)(966005)(30864003)(7736002)(2906002)(110136005)(53546011)(54906003)(316002)(86362001)(66556008)(66476007)(8936002)(66946007)(186003)(229853002)(786003)(476003)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR19MB3101; H:MN2PR19MB4045.namprd19.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: dell.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: FHWMl+s5/kW4a4ZR9+R6qFgztfig/XYlhFTxaKC3/KId6p9NseXqDYekif/lVuea6skRNBhIhfHAGDDP0II+ANC5Gw7aRZZrmesFscI19SF8bFWct012J4VQxcfA37NPHmx3vDf7sLBqpEulzG8j/Lxo4OKBj7FOpuI+g6S+yfTUgBNpHwfj/XOaRU21M1boGA/bpEHgq3kPpKCdtvGU3vfEsO1mff1YtYbqFxn0/2jfVicVBkEzuVU/gq5YPuSRNqzg1WrehyGRH2BjW5aPwIxMypq4DwQZM50YM34ggE71BmnoqUYCb5BnEC3y5Dn3q81T9Kb++KuIwhkVTHGsVvKS3B2YN4/A7AhOecWrvrFHlrhCMIf394vUjepbrbtH1SItWENcNfsyQn8D0mGIcPnF8ViQx209l+OpBRFBI+22UkuO5kWBgs7uX04HXYeAnXJGMnwDJZ6mV0WrxW+rNdzH4wMhkeqLUIYtFPe6KUM=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: Dell.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 14cf2042-6152-4b5d-6796-08d763bd74c7
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2019 20:02:45.3098 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 945c199a-83a2-4e80-9f8c-5a91be5752dd
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: YUgywOASJCIDCLMFxiWNmW9xDkCyD15NbuTLdyXpt3qqioOUaPrbZSJkgf0lROFrMjkZDFC7INEW+iDs6/oePA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR19MB3101
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-07_06:2019-11-07,2019-11-07 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 lowpriorityscore=0 impostorscore=0 mlxlogscore=999 phishscore=0 mlxscore=0 malwarescore=0 bulkscore=0 suspectscore=0 clxscore=1015 priorityscore=1501 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911070188
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 phishscore=0 spamscore=0 impostorscore=0 malwarescore=0 lowpriorityscore=0 priorityscore=1501 bulkscore=0 mlxlogscore=999 mlxscore=0 clxscore=1015 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911070188
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/TQRw8at50Mb4WO48iOwbMI2-YUQ>
Subject: Re: [tsvwg] draft-ietf-tsvwg-nqb, more questions
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: Thu, 07 Nov 2019 20:02:59 -0000

I wanted to strongly +1 this portion of the discussion:

> > The final SHOULD is intended to address your concern about prioritization
> (since it results in segregation without prioritization).
> 
> 	[SM] Ah, in that case the AP needs to be be NQB aware anyway,
> would it then not be better to use an appropriate scheduler/AQM in front of
> the AC_BE queue and keep all traffic in the same priority class? The
> disadvantage of setting AC_VI to the same EDCA values as AC_BE is then that
> applications that expect an airtime access boost from using AC_VI will not get
> it any more (not necessarily a deal-breaker but certainly unexpected enough
> to merit clear communication of that side-effect).
> 
> > Absent this requirement (or the ability to comply with it operationally), the
> operator would need to consider (and perhaps limit) which applications are
> allowed to be marked as NQB.  This aspect isn't discussed in the draft, but I
> will add it based on your input.
> 
> 	[SM] Great! I would guess the safest would be to have the NQB-
> aware scheduler in an AP apply some (proportional) rate-limiting if NQB
> traffic is getting preferential air-time access.

This is an example of a good thing to do with all uses of "SHOULD" - at least warn about the risks and/or consequences of not following the "SHOULD" (or "SHOULD NOT"), and (even better) provide some advice on staying out of serious trouble in that case (as will be done here).  

Thanks!, --David

> -----Original Message-----
> From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of Sebastian Moeller
> Sent: Tuesday, November 5, 2019 3:59 AM
> To: Greg White
> Cc: tsvwg IETF list
> Subject: Re: [tsvwg] draft-ietf-tsvwg-nqb, more questions
> 
> 
> [EXTERNAL EMAIL]
> 
> Hi Greg,
> 
> 
> > On Nov 5, 2019, at 01:28, Greg White <g.white@CableLabs.com> wrote:
> >
> > Hi Sebastian,
> >
> > Interoperability with existing WiFi equipment is an important aspect, since
> WiFi latency can be considerable. By default, many existing APs only support
> 4 priority queues, and thus it is not possible to meet all of the requirements
> of the NQB PHB (at least in this default configuration).
> 
> 	[SM] I agree the question is how to deal with that "impedance
> mismatch".
> 
> >  Nonetheless, it is possible to utilize two of the four queues in order to
> meet some of the requirements, and thus provide some of the benefits of
> the NQB PHB.
> 
> 	[SM] Unless you opt for selecting AC_BK for the NQB traffic, for most
> users the value of NQB will be mostly in the priority boost on wifi and the
> resulting air-time access advantage (which results in both lower latency and
> potentially higher bandwidth).
> 
> > With proper configuration and/or policies, this can be done safely.
> 
> 	[SM] Sure, I am concerned about the status quo wich does not entail
> "proper configuration and/or policies", and hence I believe the NQB special
> treatment on WIFI should be opt-in and not "opt-out" (in quotes as most
> endusers will not be able to opt-out). For thid reaon I believe that the
> proposal to use a code point that by default is mapped to AC_BK is the only
> correct solution (as a bonus it seems that such a code point also has a better
> chance to survive transit over the internet). NQB-aware APs then simply
> treat that NQB-codepoint however they want. If for example a priority boost
> is desired such an AP can easily implement the required rate-limiting so that
> AC_BE traffic does not get starved out. In short, I fully agree that special
> treatment requires "proper configuration and/or policies" and the desirable
> strategy if that can not guaranteed should be "do no harm".
> 
> > The final SHOULD is intended to address your concern about prioritization
> (since it results in segregation without prioritization).
> 
> 	[SM] Ah, in that case the AP needs to be be NQB aware anyway,
> would it then not be better to use an appropriate scheduler/AQM in front of
> the AC_BE queue and keep all traffic in the same priority class? The
> disadvantage of setting AC_VI to the same EDCA values as AC_BE is then that
> applicatons that expect an airtime access boost from using AC_VI will not get
> it any more (not necessarily a deal-breaker but certainly unexpected enough
> to merit clear communication of that side-effect).
> 
> > Absent this requirement (or the ability to comply with it operationally), the
> operator would need to consider (and perhaps limit) which applications are
> allowed to be marked as NQB.  This aspect isn't discussed in the draft, but I
> will add it based on your input.
> 
> 	[SM] Great! I would guess the safest would be to have the NQB-
> aware scheduler in an AP apply some (proportional) rate-limiting if NQB
> traffic is getting preferential air-time access.
> 
> >
> > Network operators understand the value of segregating NQB traffic on WiFi
> links, and will almost certainly select a DSCP in practice that achieves that
> goal.
> 
> 	[SM] That is exactly part of my concern with the default mapping to
> AC_VI approach, I expect that very quickly a lot of traffic will utilize the AC_VI
> queue potentially starving normal AC_BE traffic in the process.
> 
> > Assigning a different DSCP in this draft would do nothing to prevent them
> from doing so.
> 
> 	[SM] Sure, but is that really a good justification for proposing a DSCP
> with known side-effects? As far as I am concerned an RFC should propose
> sane defaults and hope for the best.
> 
> >  Instead, what we need to do is clearly articulate how to make best use of
> the existing WiFi tools, and how to avoid conflicts.
> 
> 	[SM] I believe the last two are mutually exclusive...
> 
> >
> > In existing RFCs, the IETF already recommends that video conferencing
> applications mark their traffic as either AF4x or CS4, all of which get mapped
> to AC_VI.  The remaining language in the NQB draft describes sparser flows
> than these.
> 
> 	[SM] as an implementer I read "relatively low data rates", without
> further guidance I have very little intuition what to use as reference. Could
> this be made more explicit? This is orthogonal to the question whether such
> a limit should be enforced in any way, here the question really is about
> getting a feel what is considered acceptable for NQB treatment.
> 
> >
> > Based on your comments, I attempted to remove all text that could be
> interpreted as recommending that high-data-rate traffic be marked NQB.
> 
> 	[SM] Thanks, as long as the aggregate NQB traffic is relative sparse
> compared to the available WiFi bandwidth (or the number of tx_ops) most of
> my WiFi concerns get less and less relevant. To be explicit, I do not object on
> principle to using AC_VI or even AC_VO as long as this does not eat
> significantly into the tx_ops for AC_BE, the current draft improves  in that
> direction. Would it be possible to make this point even stronger?
> 
> > It appears that I missed one instance (in the Introduction it gives
> "interactive voice and video" as an example). Aside from this (which I can
> correct), I think the draft currently recommends that NQB only be used for
> sparse traffic.  That said, the section where this guidance is intended to be
> given is still lacking in specificity, and poses some open questions that may
> need to be addressed in a subsequent revision.
> 
> 	[SM] Sounds great. Now this then cycles back to one of the other
> open topics, "enforcement". Ideally NQB-aware APs should monitor both
> queues and re-assign flows between them based on flow-behavior in
> relation to time-variant bandwidth experienced by that flow.
> 
> Best Regards
> 	Sebastian
> 
> >
> > Best Regards,
> > Greg
> >
> >
> > ´╗┐On 11/4/19, 3:25 PM, "tsvwg on behalf of Sebastian Moeller" <tsvwg-
> bounces@ietf.org on behalf of moeller0@gmx.de> wrote:
> >
> >    Regarding https://datatracker.ietf.org/doc/draft-ietf-tsvwg-
> nqb/?include_text=1
> >
> >    7.3.  WiFi Networks
> >
> >       WiFi networking equipment compliant with 802.11e generally supports
> >       either four or eight transmit queues and four sets of associated EDCA
> >       parameters (corresponding to the four WiFi Multimedia Access
> >       Categories) that are used to enable differentiated media access
> >       characteristics.  Implementations typically utilize the IP DSCP field
> >       to select a transmit queue, but should be considered as Non-
> >       Differentiated Services-Compliant Nodes as described in Section 4 of
> >       [RFC2475].  As a result this document discusses interoperability with
> >       WiFi networks, as opposed to PHB compliance.
> >
> >       As discussed in [RFC8325], most existing implementations use a
> >       default DSCP to User Priority mapping that utilizes the most
> >       significant three bits of the DiffServ Field to select "User
> >       Priority" which is then mapped to the four WMM Access Categories.  In
> >       order to increase the likelihood that NQB traffic is provided a
> >       separate queue from QB traffic in existing WiFi equipment, the 0x2A
> >       codepoint is preferred for NQB.  This would map NQB to UP_5 which is
> >       in the "Video" Access Category.
> >
> >       Systems that utilize [RFC8325], SHOULD map the NQB codepoint to
> UP_5
> >       in the "Video" Access Category.
> >
> >       In order to preserve the incentives principle, WiFi systems SHOULD
> >       configure the EDCA parameters for the Video Access Category to match
> >       those of the Best Effort Access Category.
> >
> >
> >    [SM] This last section is puzzling: if the wifi system configures AC_VI with
> EDCA parameters that match the AC_BE parameters, AC_VI ceases to be
> different from AC_BE, in that case picking a codepoint that automatically
> maps to CS0 and hence to AC_BE  seems much safer, simpler and straight
> forward to me.
> >    Especially since essentially none of the millions deployed WiFi APs out
> there will a) have this configured like proposed already and b) none of the
> consumer APs I know actually allow to easily adjust EDCA parameters at all. I
> guess I must be missing something and would be delighted to be shown why
> the proposed text is the right thing.
> >    My take on this still is, if NQB traffic is sufficiently sparse using AC_VI can
> be justified, but without any rate limits this has the potential of being quite
> unfair to concurrent APs on the same channel (as well as the neighboring
> channels that overlap with the selected).
> >    I do not want to sound alarmist, but given the number of cable-ISP WiFi-
> APs (as indicated by a SSID containing the ISPs name) in my city, I believe
> making sure that those APs will not basically start hogging most airtime
> seems the prudent thing to do. If there are sufficient backstops in place (like
> rate limiting or automatic down-marking if the traffic is not sparse enough) to
> avoid the described situation, I am all for it.
> >
> >    The text probably should also openly discuss that in WiFi/WMM the four
> available queues by design have different priorities, and by moving NQB out
> of the default AC_BE while leaving QB flows in there, this effectively runs
> against  the following text in the draft: "The NQB queue SHOULD be given
> equal priority compared to queue-building traffic of equivalent importance."
> (leaving alone the question how an AP or a station is supposed to measure
> importance)
> >
> >
> >    Sebastian
> >
> >