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

"Black, David" <David.Black@dell.com> Fri, 08 November 2019 19:42 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 60A2B1200D8 for <tsvwg@ietfa.amsl.com>; Fri, 8 Nov 2019 11:42:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=YMARVYsB; dkim=pass (1024-bit key) header.d=dell.onmicrosoft.com header.b=kftS/oih
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 E-QnUfx1BCVs for <tsvwg@ietfa.amsl.com>; Fri, 8 Nov 2019 11:42:17 -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 CBD4A120892 for <tsvwg@ietf.org>; Fri, 8 Nov 2019 11:42:16 -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 xA8Jdsen009895; Fri, 8 Nov 2019 14:42:09 -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=br9NgQro9Plv0m+A3fKywLE2T44radKZeSsT+BIiC9E=; b=YMARVYsBh8jJIBP5LFZE06X8UV9qauKlgVU1oCeVPDMj0G0NQxIk14KLe77J4OuGvvdZ Gqj+Q/x1j+JshIoMnSHRuClQrFwgiSJ03Cyj1dt7OdegKYXbV58nzkktc1Dyn1W1Vyhw lB8d/3wg+CrfP4qmRMlD5QWfF3znjhaKSn5lznQZnmNgqAOBnKHWNgqxEigKWu4F2/sy 1tcJ0H8LZCMFTyDEAOK/RGioOmNVMUGmci9AfuytvOHXzpU/wdhb914SAKNsxee7C0kg 6DBq4nA19HcDKXEFQgK0itCQzimWrMgwHMFzrn8u8HadN12vB+ZsLpEKvjy5/Mlm13Q5 Pw==
Received: from mx0a-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0b-00154904.pphosted.com with ESMTP id 2w41uwv3dr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 08 Nov 2019 14:42:09 -0500
Received: from pps.filterd (m0089484.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xA8JcLxr024143; Fri, 8 Nov 2019 14:42:08 -0500
Received: from nam03-co1-obe.outbound.protection.outlook.com (mail-co1nam03lp2055.outbound.protection.outlook.com [104.47.40.55]) by mx0b-00154901.pphosted.com with ESMTP id 2w4tef1tuf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 08 Nov 2019 14:42:08 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A742I3tcn3fb1+VjOcmTAfA+Crw4LjPdIZrgNIhlR1aORwlsUPp/bcCr5eWs84KGssEiXY9+kk3Pv7E2c3L3n+Dl47lyPdltv2MWjimnginVvfG3PK2X+cI6+j4+iITzhySkbuRlSeGx2Mq2bidEMjazHTvxqmJCNpkn0wFiQUwqIiqWrrU6LCIJefVSLPRCaelB76eBLLfEXhVPqcfH5Kdq0RPzO7Pkkei+pqKTHZKSooMefEqs9dujZW1VktqZmGK4+VCvhXYz4xFxuhB/9TevTZ7sdIx5bdZyqKxIZrFbCD+Xi9fJGh453x4SwJ8nDDZMp16U38U+B96h3D1F+g==
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=br9NgQro9Plv0m+A3fKywLE2T44radKZeSsT+BIiC9E=; b=JCv9ouODKBezYxrUjmwNOQIvj9sBTgjo3Ef2cDFP3nkhDail5W7B8ITohufbME6jJqB7IFH4tMt9ewPi9UJYEDZ0kUsPpje/5HXl5r3TZp2HdKl1PQeeAM8GZIUiijzxYbj+JFmfNm9mcRry0fo7cFxeh59JCziuUPxN3XNiH3R4SR54GCJK6CLzVHkvtri9/SdJVktEfVsXy0XSJ0WGhN+GNS3yr65fvtlAa0fzq7cE+QtFV2qZqYw9TVcq+4s6yVN1YjBZPrbLpC8ddO9Eji3L8PSZK2KlpSeYy4rClC4W7uxk1jWf0smsXadPVvX0If9CDqjHla4UCA8VYe50kw==
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=br9NgQro9Plv0m+A3fKywLE2T44radKZeSsT+BIiC9E=; b=kftS/oihsGExdinjlnCHQTw63O58Oln8b247UnSLRSRNIGPEcTlLdZapsz6OIjJduMODpVFuvhqzLo/klyPY65mOp0JeN5l53nfUsi1z4no7/YuO+MrWQ5a1HuFzEYM7qVejvKA4mU6/MChWcM37gdcSj+aoo0x5afhsyN9fwZA=
Received: from MN2PR19MB4045.namprd19.prod.outlook.com (10.186.145.137) by MN2PR19MB3405.namprd19.prod.outlook.com (20.179.151.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.24; Fri, 8 Nov 2019 19:42:00 +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.023; Fri, 8 Nov 2019 19:42:00 +0000
From: "Black, David" <David.Black@dell.com>
To: Sebastian Moeller <moeller0@gmx.de>
CC: Greg White <g.white@CableLabs.com>, tsvwg IETF list <tsvwg@ietf.org>, "Black, David" <David.Black@dell.com>
Thread-Topic: [tsvwg] draft-ietf-tsvwg-nqb, more questions
Thread-Index: AQHVk168g4JkWCsXvkKSWKsK//1LrKd7uScAgACOhICAA90NQIAACrEAgAAEdgCAAAHnQIAAKJyAgAFQyuA=
Date: Fri, 8 Nov 2019 19:41:59 +0000
Message-ID: <MN2PR19MB4045E609BF51DC41A5D4E26E837B0@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> <MN2PR19MB4045003442DB1E7643C96DD083780@MN2PR19MB4045.namprd19.prod.outlook.com> <B5BE8F47-9B0D-456E-8804-1D159875AA53@cablelabs.com> <4E3EC8B5-6A0B-46A8-A273-943FAB389E7D@gmx.de> <MN2PR19MB4045169789DF1C145D4EE57983780@MN2PR19MB4045.namprd19.prod.outlook.com> <B245975C-5173-4C1D-881A-9C1077BB448E@gmx.de>
In-Reply-To: <B245975C-5173-4C1D-881A-9C1077BB448E@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-08T19:30:37.9394197Z; 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: 53dd0219-7e6c-4b6c-15ca-08d76483b8e7
x-ms-traffictypediagnostic: MN2PR19MB3405:
x-ms-exchange-purlcount: 1
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MN2PR19MB340598D62D7DB885AE1C0738837B0@MN2PR19MB3405.namprd19.prod.outlook.com>
x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4
x-ms-oob-tlc-oobclassifiers: OLM:7219;
x-forefront-prvs: 0215D7173F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(396003)(39860400002)(136003)(346002)(52314003)(7502003)(13464003)(189003)(199004)(66574012)(52536014)(76176011)(11346002)(4326008)(7696005)(9686003)(446003)(81156014)(26005)(561944003)(8676002)(8936002)(86362001)(478600001)(6506007)(81166006)(6306002)(102836004)(30864003)(54906003)(316002)(786003)(229853002)(6436002)(5660300002)(55016002)(14454004)(186003)(486006)(107886003)(6246003)(7736002)(66556008)(66946007)(76116006)(66446008)(64756008)(66476007)(256004)(14444005)(25786009)(305945005)(53546011)(74316002)(71200400001)(3846002)(71190400001)(99286004)(66066001)(33656002)(6116002)(2906002)(6916009)(966005)(476003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR19MB3405; 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: gxz2sL5WfQk52XhDHoQLn7/+UthnB8Ni6m6PmcByM+qPys+mEm36WAcJfE4+TMW0j3EL4oI2OnrowiJm6I63E+BoJI1wcLBDmWXDHzet1zYoRZNT4jFum4FDTIlgJkfIcT8IBHjrPW6tFamjx0kaO++yQ54hptmpX6Ih1kPBoG3Ddl1L1a0y+tCScCPLR15UAlvPD3xhG/J3ljWyKjogYIwpn82wkuXULoT4Nidnvdj70s9sRG/T+Ehvq01IlKYxN7zSDg2wv4gGPtB/yAoOnbHABgFRLu1Y4DDE4FJ/m9EhJwem8x6L9SgAuDoMWZYNYX1VWO1WzaLdKvVxteHYNEuiwnPnQxkb7c0OPFx1tKbSmZxwu3Rua0O7UMei+OTUbJ7cCKHVez7pLvKuzYC4IG8EZOL8taSDnIDZ64ASNKLJSsFxjGEQBTrlC8sPBddReNOo0QbtFk7p8YC2DUsaxIvyhfZDLcyt7mlv19aCWfE=
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: 53dd0219-7e6c-4b6c-15ca-08d76483b8e7
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Nov 2019 19:41:59.9619 (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: cBjHfsF6LhNiy/VmEiBRe5uCgukPxHAxWVrdYzYy1LzM3mogfopkr0VZsuDIsysy4Renm4GrN1VzSbCZZBlSDQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR19MB3405
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-08_07:2019-11-08,2019-11-08 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 spamscore=0 lowpriorityscore=0 mlxlogscore=999 bulkscore=0 priorityscore=1501 phishscore=0 mlxscore=0 malwarescore=0 clxscore=1015 adultscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911080191
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-1911080191
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/ofLAzoe8YRD11rbu1_wgY5KUqhw>
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: Fri, 08 Nov 2019 19:42:21 -0000

> Question, does it really make sense to refer to rfc8325 and then to
> recommend to basically invalidate that RFC's assumptions?

Yes, RFC 8325 is rather new, so providing recommendations both for situations in which it is supported and for situations in which it is not supported does make sense.

There's recent relevant experience in what TSVWG went through to select a recommended DSCP for the LE PHB.  The network behavior (observed in the Internet) that was the primary cause of that consternation was bleaching (zeroing) the IP precedence field, whose bits were respecified to be part of the DSCP field by RFC 2474.  So, in that case, TSVWG was dealing with equipment that did not comply with RFC 2474 ... which is much older than RFC 8325. 

Thanks, --David

> -----Original Message-----
> From: Sebastian Moeller <moeller0@gmx.de>
> Sent: Thursday, November 7, 2019 6:25 PM
> To: Black, David
> Cc: Greg White; tsvwg IETF list
> Subject: Re: [tsvwg] draft-ietf-tsvwg-nqb, more questions
> 
> 
> [EXTERNAL EMAIL]
> 
> Hi David,
> 
> 
> 
> > On Nov 7, 2019, at 22:00, Black, David <David.Black@dell.com> wrote:
> >
> >>> BTW, just to avoid confusion, I'm reading your "strong +1" to be solely
> >> about adding warnings/advice in case the "final SHOULD" is not
> implemented
> >> (and similar, for other SHOULDs in the draft as well).
> >
> > That's correct.
> 
> 	[SM] Here is an attempt at doing this for the last paragraph in the wifi
> section:
> 
> 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.
> 
> Not doing this risks that sufficiently high rate NQB traffic completely starves
> out normal traffic in the AC_BE queue. Doing this on the other hand will
> violate the traffic prioritization that rfc8325-compliant applications might
> expect from using dscp's that normally map into the AC_VI priority queue.
> 
> 
> Question, does it really make sense to refer to rfc8325 and then to
> recommend to basically invalidate that RFC's assumptions?
> 
> 
> Sebastian
> 
> 
> 
> 
> >
> > Thanks, --David
> >
> >> -----Original Message-----
> >> From: Sebastian Moeller <moeller0@gmx.de>
> >> Sent: Thursday, November 7, 2019 3:53 PM
> >> To: Greg White
> >> Cc: Black, David; tsvwg IETF list
> >> Subject: Re: [tsvwg] draft-ietf-tsvwg-nqb, more questions
> >>
> >>
> >> [EXTERNAL EMAIL]
> >>
> >>
> >>
> >>> On Nov 7, 2019, at 21:36, Greg White <g.white@CableLabs.com> wrote:
> >>>
> >>> Noted, and I agree that it is important.  I'll write some appropriate
> warning
> >> text.
> >>>
> >>> BTW, just to avoid confusion, I'm reading your "strong +1" to be solely
> >> about adding warnings/advice in case the "final SHOULD" is not
> implemented
> >> (and similar, for other SHOULDs in the draft as well).   You also quoted
> some
> >> text from Sebastian which was factually incorrect (that an AP complying
> with
> >> the SHOULD is NQB aware).
> >>
> >> 	[SM] Are you talking about:
> >>
> >> "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."
> >>
> >> in the context of non NQB-aware APs? How feasible di you think it will be
> to
> >> expect all deployed APs to have the AC_VI EDCA parameters changed to
> >> comply with this recommendations, especially in the light that almost no
> APs
> >> actually offer to configure these parameters at all? Does it really make
> sense
> >> to propose a SHOULD that is known to be almost impossible to actually
> >> implement in virtually all existing APs?
> >> I guess I must be misunderstanding you here, because the remedy for
> >> (arguably) misusing a prioritization system can not really be "disable the
> >> priority system", color me confuzed.
> >>
> >> Best Regards
> >> 	Sebastian
> >>
> >>
> >>> I'm assuming you weren't "+1" on his conclusions from that, but correct
> me
> >> if I'm wrong.
> >>>
> >>> -Greg
> >>>
> >>>
> >>> ´╗┐On 11/7/19, 1:02 PM, "Black, David" <David.Black@dell.com> wrote:
> >>>
> >>>   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
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
> >