Re: [tsvwg] TSVWG: WG adoption of draft-white-tsvwg-nqb!

Sebastian Moeller <moeller0@gmx.de> Thu, 12 September 2019 10:20 UTC

Return-Path: <moeller0@gmx.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 A782A120273 for <tsvwg@ietfa.amsl.com>; Thu, 12 Sep 2019 03:20:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.348
X-Spam-Level:
X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 (1024-bit key) header.d=gmx.net
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 hG_W0aJHB2o9 for <tsvwg@ietfa.amsl.com>; Thu, 12 Sep 2019 03:20:38 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 307B7120073 for <tsvwg@ietf.org>; Thu, 12 Sep 2019 03:20:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1568283631; bh=Txg3nXpbny/Pw7pba1mRmBm96Bm4N9VXopW/Xcag8Hg=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=K337zm5CgeGl3y4cQRFkHrp9bbPsVgjLvXKjhS9szURweE9VY2QQqC71YITcyn58C F2ZeqYHfqb5EJkc+EWTorHJYUVNpepT1J97WPnuSKXbSKZn2tNcpwSFAyKQvt3qnzW o/2d1u+UNhNf0D8RZf+0NCSjf/y5Jxyc+OObZWzY=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.11.12.32] ([134.76.241.253]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MOkQc-1i4UbB1FG2-0068xB; Thu, 12 Sep 2019 12:20:31 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <LEJPR01MB11788243F3902D2C024258189CB00@LEJPR01MB1178.DEUPRD01.PROD.OUTLOOK.DE>
Date: Thu, 12 Sep 2019 12:20:28 +0200
Cc: "<g.white@cablelabs.com>" <g.white@CableLabs.com>, tsvwg@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <F50F4375-FFE5-4322-82DD-6BD3650BCAE0@gmx.de>
References: <CE03DB3D7B45C245BCA0D24327794936306BBE54@MX307CL04.corp.emc.com> <AA4DBFC5-8D8F-4F43-80E4-BB9BA7F53486@cablelabs.com> <LEJPR01MB1178B6C102455F1F9886D49A9CBB0@LEJPR01MB1178.DEUPRD01.PROD.OUTLOOK.DE> <F351D86E-DCE4-45CD-9B08-2E0C11090BF1@cablelabs.com> <LEJPR01MB11789EE6D8B7C732393BD1439CB70@LEJPR01MB1178.DEUPRD01.PROD.OUTLOOK.DE> <B11AB47E-7E35-4599-A85B-DB0EF883E2B2@cablelabs.com> <LEJPR01MB1178D2DCD24874E8AE47202D9CB10@LEJPR01MB1178.DEUPRD01.PROD.OUTLOOK.DE> <864587C3-0A18-41A3-BFA7-00BD9CE56717@cablelabs.com> <LEJPR01MB1178C642457E9018459983999CB00@LEJPR01MB1178.DEUPRD01.PROD.OUTLOOK.DE> <9924D4FB-F5D8-49FE-8EC4-33A778F8ECFA@gmx.de> <LEJPR01MB11788243F3902D2C024258189CB00@LEJPR01MB1178.DEUPRD01.PROD.OUTLOOK.DE>
To: Ruediger.Geib@telekom.de
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:i9CJLqgtLRquxnbLm+DMtC4Fm/HSrUdFhwxe0HusOw6LP3mAIze bQY6zsY+3N7ID9FQjZmEYhY4eMCEbB0+g1ba9eGUkuwRFSXrwR1kzxb7KjR4NBzth/I9cPo HhdILsWFDmDvvsn5Fgf2vx50gGK5q9thJQCnBLxMD7zvoOpphXR77+wAJqVaxlXPYrXoSkb 0iMVGz42ESbogaylhxNzw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:0cU8iqziea0=:STs55ZsJgWA5mSUPLzT5/6 jcKs6ne/YMT6ue3zR+10loyNseP1CVKI9jmb6d4EFabuXPG4ws5JY9VRvotru3P7EyiUwz0Q+ 4a8R2fA1dtSYMAAXFxPA387Jr++BbDul1vOzeBDp02eelhNsZZhFDRqHdLkPvObfy12w0lbLF FmVHT7izIoxCYCP8NjUP4pm1SGI0cq0gNFDdj1oMalf2QOLPtWsD80r5qk85SJ5xggKrSYLVE 4q+Q8pduCgNVldYRDOR35RZ10wWVcqEmwTOxKV9PFBORYtdkqhisgk68bD9hmuft5RUOobOYM pUpPRXDUzNtTxULHhriGqUxrGCG5SBnCNuO3UGY+zD8WYYL/h6SVDZn+kRtpZLN3i25OWZyuY Nri2XvDUC6VcLCjzcYbCgvygIt5eXJ04IGF3kvwd1kZ+Jo0PjkQC+eLx6sNMiAbljQ1Dh+S5i je9YlXXZ7axo9odmfr2RatiMxHd/7zIebAChm7BXPM+OPN9Bue8Gsn2SJ7aHH1fWiFu+FPaBT aMXQ4CninWmXEcASQ9Omysh208oubWl63hCRsL1nNEUFbp5kXj4Mc3BtFfU10IJ5SeDVqZVc7 16LHKBks5aLkFImGKWmbHo97+fJ04guhPN9w9/5bHEOIab1H6lK237qHTkeysRVR79rr5Zafi lzlu0F+Wi+rggJ6kGTSmmhb+EJnZf9dnprHA7X3r4QhmpxAcPbAkkO3CJffFqlLWwaes48iz2 ZxR+0B+Ixr7Q0F8mI0H9esEcqT2V8MEQrSlD64jjNpi2ZmPzBCb7gFxZvxbDXem8SSbS2NMjj VpsH2t0w6MH8FklpJt82GNSpFOUUtnNEVAleAjbSn/H8HWSwS1QMcc7BM62xd4NZFoVDZh5Ge aYhbyy550v8/Q2OCwGOi9skXS2AiNmYtSnB++bGdsFZc/8kThxO/crl2p14ZUoY1S3Ju8D/WA 5OL+Pv+mXRM+XXs/d4XZn+Dl2jRoayC6Dy77SKyIpFJzsBBInhPH+curD3LxBHSJEo86MtDhH h75P/K30YZSv9PxgNtu70zYIQJj3tYF67NPF2n/nOikLwnsixDmEyfUsM7dCuUuqM1OJV9s2X LVvDmd/0iJNZJ9+GczVmqcCualv8/bmrf0cGl4/QIkcrNDiLTdEs0YmmSOx7f/msQdn71IIDS 2Rg480l7B8/+bfgk8CKqkcCyj8VmIYwQlf0+u9XHFyf+QI4OYTGZZT0RvT/u6IvcNiIYSIixQ 0sqV00B4MQBJyLxCq5xLbkpw1PHhXZp6pnD+nee58F+WtnDTutgq1jTZ59tw=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/Q_xH_1X9hjgVRa_dFTNK5GC-cPc>
Subject: Re: [tsvwg] TSVWG: WG adoption of draft-white-tsvwg-nqb!
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, 12 Sep 2019 10:20:44 -0000

Hi Ruediger,


> On Sep 12, 2019, at 11:30, Ruediger.Geib@telekom.de wrote:
> 
> Hi Sebastian,
> 
> thanks. My take is as described: if no SLA is required or desired and the DSCP is supposed to survive unchanged end-to-end or end-to-edge, 000xx1 seems a god way to go.
> 
> RFC 8100, "Diffserv-Interconnection Classes and Practice" https://datatracker.ietf.org/doc/rfc8100/ was written to describe and specify how to solve Diffserv related issues arising at interconnection.
> 
> I'm not sure whether a network provider supporting EF with a priority queue accepts NQB with a DSCP 101xxx at interconnection even with an SLA in place. As a minimum, I'd expect an incoming policer to be required (and the sender should configure NQB at the Gateway's sender interface with a bitrate set to shape this traffic to the policer rate). 


[TANGENT]
	Somewhat related question, how hard would it be, in your opinion, to convince operators to only bleach those 3 bits of the dscp field that I assume they only look at effectively (modulo EF which unfortunately does not exactly equal CS5)? What I would desire is to split the 6 bit DSCP field into 3 bits for immediate use, and 3 bits for the end points to signal intent. That way intermediate hops can re-mark the first 3 bits as they see fit, while AS/DSDs after that re-marking can still base their own treatment/re-marking/re-mapping on the intent of the endpoints. That way NQB could be completely ignored by intermediate hops and those that should care simply ignore the first bits and just look at the intent bits.
	Sure 8 << 63, but in the end what is the value of 63 code points if they do not carry interpretable information?
[/TANGENT]

Regards
	Sebastian


> 
> Regards,
> 
> Ruediger
> 
> -----Ursprüngliche Nachricht-----
> Von: Sebastian Moeller <moeller0@gmx.de> 
> Gesendet: Donnerstag, 12. September 2019 10:41
> An: Geib, Rüdiger <Ruediger.Geib@telekom.de>
> Cc: <g.white@cablelabs.com> <g.white@CableLabs.com>om>; tsvwg@ietf.org
> Betreff: Re: [tsvwg] TSVWG: WG adoption of draft-white-tsvwg-nqb!
> 
> Dear Ruediger,
> 
> this time to the list as well ;)
> 
> 
>> On Sep 12, 2019, at 08:54, Ruediger.Geib@telekom.de wrote:
>> 
>> Greg,
>> 
>> that’s not what I said. You’ll most likely see remarking to default PHB and forwarding as default PHB, unless there’s an SLA in place, if your desire is to mark NQB by a DSCP 101xxx. To preserve a DSCP clearly indicating NQB at interconnection without an SLA in place, I suggest a DSCP 000xx1.
> 
> [SM] +1; using 000xx1 will also effortlessly solve the wifi WMM issue with APs that do not explicitly support NQB (in essence all existing APs). But I believe Greg is also trying to put in a requirement that ASs should not re-mark NQB to something else (which in principle I support, at least a few of the dscp bits should be reliably e2e).
> 
> Best Regards
> 	Sebastian
> 
> 
>> 
>> RFC 8100 contains more information on the background (motivation of the above and how to deal with the issues arising).
>> https://datatracker.ietf.org/doc/rfc8100/
>> 
>> Regards,
>> 
>> Ruediger
>> 
>> 
>> 
>> Von: Greg White <g.white@CableLabs.com>
>> Gesendet: Mittwoch, 11. September 2019 19:14
>> An: Geib, Rüdiger <Ruediger.Geib@telekom.de>
>> Cc: tsvwg@ietf.org
>> Betreff: Re: [tsvwg] TSVWG: WG adoption of draft-white-tsvwg-nqb!
>> 
>> Agreed.  I think the most likely implementation in backbones is to allow NQB marking to survive the interconnection, but treat the traffic identically to default traffic until it reaches the edge (access network).
>> 
>> -Greg
>> 
>> From: "Ruediger.Geib@telekom.de" <Ruediger.Geib@telekom.de>
>> Date: Wednesday, September 11, 2019 at 6:30 AM
>> To: Greg White <g.white@CableLabs.com>
>> Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
>> Subject: AW: [tsvwg] TSVWG: WG adoption of draft-white-tsvwg-nqb!
>> 
>> Hi Greg,
>> 
>> backbone routers handle bulk traffic to the extent that I can tell. Finer grained traffic treatment may be found at network edges terminating consumer access. That is to say: a peer or a customer should agree which DSCPs are exchanged at interconnection or expect re-marking.
>> 
>> And to add (as that has been discussed too): don’t expect per flow treatment at a congested backbone link. That’s to say, that I don’t expect NQB support by a backbone router in the same way, as by an edge router. The next generation interfaces are n*100 Gbit/s and I’m not sure how these perform trying to identify the “least NQB like flow” in the case of congestion.
>> 
>> Regards, Ruediger
>> 
>> Von: Greg White <g.white@CableLabs.com>
>> Gesendet: Dienstag, 10. September 2019 20:30
>> An: Geib, Rüdiger <Ruediger.Geib@telekom.de>
>> Cc: tsvwg@ietf.org
>> Betreff: Re: [tsvwg] TSVWG: WG adoption of draft-white-tsvwg-nqb!
>> 
>> Hi Ruediger,
>> 
>> Yes, my focus (both from the perspective of the systems that I work on, and from the perspective of where I think NQB differentiation is most valuable) is on last mile and WiFi.  In terms of interconnection, there could be multiple ways to handle this.  My view is that the endpoint application has the best a priori knowledge of its sending behavior, so it is good to leverage that (and either validate it or not, depending on what is most appropriate for the situation).   This would argue for networks to adopt a policy of not bleaching the NQB value on traffic arriving from interconnections, and utilizing queue protection if necessary to validate NQB behavior.   That said, there are other ways that network operators can identify NQB traffic without solely relying on endpoint marking (and DSCP preservation across interconnects).  I know some operators are investigating such techniques.  
>> 
>> -Greg
>> 
>> From: "Ruediger.Geib@telekom.de" <Ruediger.Geib@telekom.de>
>> Date: Monday, September 9, 2019 at 12:57 AM
>> To: Greg White <g.white@CableLabs.com>
>> Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
>> Subject: AW: [tsvwg] TSVWG: WG adoption of draft-white-tsvwg-nqb!
>> 
>> Hi Greg,
>> 
>> to me that reads as if you are mainly interested in a specified NQB DSCP for the last mile. A packet received at interconnection with a DSCP which hasn’t been agreed between sending and receiving domain will be re-written (speaking for the part of the network I work with). 
>> 
>> That’s ok, as DiffServ involves policy management anyway.
>> 
>> Regards,
>> 
>> Ruediger
>> 
>> Von: Greg White <g.white@CableLabs.com>
>> Gesendet: Freitag, 6. September 2019 19:18
>> An: Geib, Rüdiger <Ruediger.Geib@telekom.de>
>> Cc: tsvwg@ietf.org
>> Betreff: Re: [tsvwg] TSVWG: WG adoption of draft-white-tsvwg-nqb!
>> 
>> Hi Ruediger,
>> 
>> Many networks can (and do) configure the DSCP to PHB mappings and policies in accordance with their own intended usage.  In particular, DOCSIS links and LTE links (likely others as well) can be configured in a manner that complies with the PHB definition.  In other cases, it may be either necessary or sufficient (or both) to support NQB traffic without fully complying with the PHB (of course this isn’t new with NQB).
>> 
>> One of the high level goals is to ensure that the benefits of differentiating NQB traffic are not lost when that traffic traverses a WiFi link (since in many of the target use cases it does).  WiFi gear will likely not support all of the aspects of the PHB definition (at least current equipment will not).  We are essentially limited to 4 queues (BK, BE, VI, VO) and their associated CSMA parameters.  An additional constraint that we’re faced with is that in many cases the mapping from DSCP to AC is essentially fixed – it is either operationally hard or impossible to change.
>> 
>> Of the WiFi APs that we’ve tested (a sample of current generation .11ac devices, covering several chipsets) 100% of them use the “default mapping” of DSCP to AC as follows.
>> 
>> DSCP
>> WMM Access Category
>> 001xxx, 010xxx
>> Background (AC_BK)
>> 000xxx, 011xxx
>> Best Effort (AC_BE)
>> 10xxxx
>> Video (AC_VI)
>> 11xxxx
>> Voice (AC_VO)
>> 
>> Living within this constraint, and trying to make the best of it, we’ve selected as a default DSCP the 0b101010 value, which would get mapped into the Video Access Category (along with CS4, AF41, AF42, AF43, CS5, VA, EF).  This would ensure that, in large part, NQB traffic is handled in a separate queue from the queue-building bulk data traffic (the vast majority of which uses AC_BE or AC_BK).
>> 
>> I would not expect that it would be important for NQB marked traffic to be differentiated in core network switches or routers, which in many cases do not provide deep (10’s to 100’s of ms) buffers.  So, in these switches NQB would likely be treated the same as Default (or whichever local use codepoint is used for best effort).
>> 
>> A characteristic of the NQB PHB as implemented in DOCSIS is that it provides low latency, low latency variation, and low loss for an NQB marked flow as long as the flow is “well behaved”.  If an NQB-marked flow is not well behaved then it experiences greater latency variation, greater loss, and potential re-ordering.   A well behaved flow is one that does not materially cause queue build-up in the network, i.e. its instantaneous rate does not materially exceed the instantaneous available bandwidth of the path.
>> 
>> In managed networks, or in cases where SLAs are provided, it seems to me that an operator should determine whether traffic that is already in a defined service class would benefit from being further differentiated based on QB vs NQB behavior (like, as you suggested using various AF marks), or whether certain existing service classes can be grouped into QB vs NQB meta-classes, depending on the technology limitations at each hop (MPLS, Ethernet, WiFi, LTE, DOCSIS, etc).  The result of this determination could require the use of non-default (i.e. non-standard) marking of NQB traffic in some cases.
>> 
>> -Greg
>> 
>> 
>> 
>> From: "Ruediger.Geib@telekom.de" <Ruediger.Geib@telekom.de>
>> Date: Thursday, September 5, 2019 at 2:03 AM
>> To: Greg White <g.white@CableLabs.com>
>> Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
>> Subject: AW: [tsvwg] TSVWG: WG adoption of draft-white-tsvwg-nqb!
>> 
>> Hi Greg,
>> 
>> the policy of the company I work for is: EF marked traffic received on a peering interface is remarked. DiffServ traffic destined to a retail access is subject to admission control, if that traffic is not expected to experience congestion. 
>> 
>> The latter might change with high-speed access links. If the users and the above traffic have a hard time congesting these access links, the admission control requirement may not be strictly required. 
>> 
>> If NQB traffic is supposed to be sent to third parties without an SLA at peering links being in place, proper selection of the DSCP matters. Without a deeper thought, a DSCP 000xx1 may be a proper choice in that case. Without an SLA being in place, the forwarding to be expected is default forwarding. If NQB is supposed to define a default-like behavior for a serious traffic share, it should be marked by a DSCP in the range 000 xxx at interconnection.
>> 
>> If an SLA is expected to be in place at peerings, any traffic without admission control should face a higher packet drop probability if destined to a retail access, than admission controlled traffic. If I assume the admission controlled traffic to be marked AFx1, NQB traffic in the same queue should be marked AFx2 (or AFx3). I’m open to discuss queue depths and expected traffic properties for a suitable AF class. RFC 8100 proposes to specify DSCPs only at interconnection. That may be a starting point, should SLAs on NQB at peerings be within commercial scope (that’s a non-technical issue, of course).
>> 
>> The choice of a DSCP for traffic which is created and terminated within a single domain doesn’t need to specified – here the PHB specification is important and the behavior of that traffic in the presence of traffic from other PHBs. I’d again opt for AFx2 or AFx3 (hoping that the NQB PHB specification allows for a useful implementation suiting AFx1 and NQB traffic in the same queue, expecting both to expect no congestion, AFx1 traffic to be admission controlled if present and NQB having features to reduce bandwidth if congestion is imminent).
>> 
>> I’m not sure what is expected from a backbone network supporting NQB (and other DiffServ PHBs). MPLS supports 8 traffic classes or codepoints, respectively. This coding space includes the codepoints required for ECN (codepoints, not bits).
>> 
>> I appreciate more standard DSCPs based on a clear and consented definition of the corresponding PHBs. Default marking, LE, EF and Network Management are good examples.
>> 
>> My take – sorry if I misunderstood some of your design aims, should that be the case.
>> 
>> Regards,
>> 
>> Ruediger
>> 
>> Von: tsvwg <tsvwg-bounces@ietf.org> Im Auftrag von Greg White
>> Gesendet: Donnerstag, 5. September 2019 01:02
>> An: Black, David <David.Black@dell.com>om>; tsvwg@ietf.org
>> Betreff: Re: [tsvwg] TSVWG: WG adoption of draft-white-tsvwg-nqb!
>> 
>> Thanks David.
>> 
>> On your item 3, could you clarify what you mean?   RFC 8325 does not discuss a “non queue building” service class, and so I don’t see a technical inconsistency between the NQB draft and RFC8325.  There has been some discussion on the list as to whether IETF should recommend that NQB be mapped to UP_6/AC_VO or UP_5/AC_VI, but in at least one of those cases where it was suggested to change the draft, the rationale for doing so was based on an incorrect assumption that NQB-marked traffic would by definition include capacity-seeking flows (e.g. L4S).  As I stated on list, I don’t have a problem with changing it to UP_5/AC_VI if that is the consensus.  But, the reason for mapping NQB to UP_6/AC_VO is so that both RFC8325 and “default mapping” 802.11 devices map EF, VA and NQB together to the same UP/AC, and so that both types of devices map these traffic types one AC level “higher” than elastic traffic sources (e.g. AF3x).  I’d like to see a more reasoned argument as to why NQB should be grouped with AF3x traffic as opposed to EF & VA before making a change.
>> 
>> -Greg
>> 
>> 
>> 
>> From: tsvwg <tsvwg-bounces@ietf.org> on behalf of David Black 
>> <David.Black@dell.com>
>> Date: Friday, August 30, 2019 at 9:41 AM
>> To: "tsvwg@ietf.org" <tsvwg@ietf.org>
>> Subject: [tsvwg] TSVWG: WG adoption of draft-white-tsvwg-nqb!
>> 
>> In the Montreal TSVWG meeting, there was a strong sense of the room that the TSVWG WG should adopt draft-white-tsvwg-nqb as a starting point for work on an NQB PHB.   The WG call for adoption on this list has been open for over a week, since August 21, and having seen only one objection on the list to adoption of the draft (from Dave Taht), the WG chairs (Gorry, Wes and David) have concluded that the WG rough consensus is to adopt this draft.  It’s important to emphasize that the draft is adopted as a *starting point* for TSVWG work, i.e., the current draft content does not represent the rough consensus of the WG.  Significant work will be required to produce an actual PHB spec that is suitable for implementation – see the recent RFC 8622 on the LE PHB (https://datatracker.ietf.org/doc/rfc8622/) for an example of what a PHB spec looks like.
>> 
>> There are a few items that will need attention before the initial -00 WG version of the NQB draft is submitted – these are to avoid confusion about what the WG intends to do:
>> 1)      The draft needs to be clear that the use of the 0x2A DSCP value as the default for this PHB is a *suggestion by the authors that is subject to change*.  Whether to use that DSCP or a different one is a WG decision; the plan is to discuss and select the default DSCP value starting (and hopefully concluding) in September.
>> 2)      The criticisms on this list of the “queue protection” requirement in the draft are largely accurate.   The draft needs at least an Editor’s Note that this material will be revised, as while the DOCSIS mechanism is an example of how to do queue protection, it is not appropriate to require implementation of that mechanism.   A plausible plan that I have discussed with the authors is to write a set of functional/behavioral requirements for NQB “traffic protection” that can be satisfied by a “queue protection” mechanism such as the DOCSIS mechanism, or by a suitably configured FQ AQM implementation.
>> 3)      RFC 8325 reflects the IETF consensus on how to map between Diffserv and WiFi QoS, hence the 8.3 section of the NQB draft needs to be modified to be consistent with RFC 8325.
>> 4)      Similarly, the 8.2 section of the NQB draft needs to be modified to reflect the conclusion of discussion on this topic in Montreal.
>> Those 4 changes are necessary in the -00 WG version of the NQB draft.
>> 
>> In addition, related to item 2), my expectation (which is open to further discussion) that “traffic protection” will be a “MUST” requirement, perhaps with some well-specified exceptions (including explanations of why the exceptions are ok).   This is because “traffic protection” (e.g., “queue protection” or a suitably configured FQ AQM) appears to be necessary in general to keep queue-building traffic out of the NQB traffic aggregate, as allowing such traffic degrades the properties of the NQB PHB.
>> 
>> Thanks, --David (TSVWG co-chair, will be shepherd for NQB draft).
>> ----------------------------------------------------------------
>> David L. Black, Senior Distinguished Engineer Dell EMC, 176 South St., 
>> Hopkinton, MA  01748
>> +1 (774) 350-9323 New    Mobile: +1 (978) 394-7754
>> David.Black@dell.com
>> ----------------------------------------------------------------
>