Re: [tsvwg] NQB: Use of DSCP 45

[Greg White <[e-mail]>]

Hi David,

Responding to points 2 & 3 below.

-Greg


From: tsvwg <[e-mail]> on behalf of David Black <[e-mail]>
Date: Tuesday, January 4, 2022 at 9:15 AM
To: "[e-mail]" <[e-mail]>
Subject: [tsvwg] NQB: Use of DSCP 45

In catching up on emails, I've reviewed the discussion of NQB usage of DSCP 45 (0x2D), mostly between Greg and Sebastian.  Writing as draft shepherd, I think that there are several issues in that discussion that deserve broader WG attention, one of which I think I understand and two that I definitely do not fully understand.

[1] Use of DSCP 45 (0x2D) for NQB at network interconnections (the one that I understand).

There are a number of things that could go wrong if DSCP 45 is used for NQB traffic at network interconnections because DSCP 45 results in better forwarding treatment than DSCP 0 for Default (best effort) traffic in many networks.

The draft currently says that DSCP 45 SHOULD NOT be used at network interconnects via SHOULD requirements to remap it to DSCP 5.  I don't think that's sufficient, and hence suggest strengthening that text based on the Diffserv Architecture (RFC 2475):

·         Define DSCP 45 for NQB as a "local use" codepoint, based on the definition of "local use" in RFC 2474 and RFC 2475.

·         Explicitly prohibit use of DSCP 45 at network interconnects unless that usage is explicitly documented in the TCA (Traffic Conditioning Agreement, see RFC 2475) for that interconnection.

o   The change here would be from the current "SHOULD remap for interconnection" to "MUST NOT use for interconnection unless explicitly allowed by the TCA for that interconnection."
This would also help clarify the IANA considerations for NQB DSCPs– DSCP 5 would be the single default DSCP for NQB, with a note added to the IANA registry that DSCP 45 is available for local use under the conditions specified in the NQB PHB RFC.

Overall, I don't think this proposed approach departs significantly from the intended usage (mostly non-usage) of DSCP 45 for network interconnection, and I think it results in significantly clearer text in both the draft and the IANA registry.

[2] Interaction of DSCP 45 with standards-compliant vs. legacy WiFi equipment.

The crucial rationale for use of DSCP 45 for NQB is this sentence in Section 8.3.1 of the NQB draft:

   In order to increase the likelihood that NQB traffic is provided a
   separate queue from QB traffic in existing WiFi equipment that uses
   the default mapping, the 45 code point is recommended for NQB.

I don't understand the long-term intent here.  Is it that DSCP 45 will be used for WiFi for the foreseeable future or that DSCP 45 will be supplanted by DSCP 5 as WiFi gear gets upgraded?  If the latter, there are a plethora of problems in figuring out whether or not the WiFi gear is upgraded or not.  What's the intent here?

[GW] The intent is that endpoints would use DSCP 45 for the foreseeable future. I agree that the other alternative you mention would be problematic.

On a related note, I agree with Sebastian that this paragraph in Section 8.3.1 is unrealistic:



   Furthermore, in their default configuration, existing WiFi devices

   utilize EDCA parameters that result in statistical prioritization of

   the "Video" Access Category above the "Best Effort" Access Category.

   If left unchanged, this would violate the NQB PHB requirement for

   equal prioritization, and could erode the principle of alignment of

   incentives.  In order to preserve the incentives principle for NQB,

   WiFi systems SHOULD configure the EDCA parameters for the Video

   Access Category to match those of the Best Effort Access Category.

I'm not even sure that IETF ought to be standardizing requirements on WiFi EDCA parameters, as those would seem to be for IEEE 802 to prescribe, not IETF.

[GW] This is recommending a configuration, rather than standardizing requirements on equipment.  Would it read better as: “… WiFi systems SHOULD be configured such that the EDCA parameters ….”?  Or, otherwise written as guidance?

FWIW, I have a worked example of that paragraph being unrealistic, as I recently bought a couple of basic WiFi APs off of eBay to solve some local problems (e.g., wife's tablet was not reliably connecting to WiFi from the other end of the house), and those APs don't have a consumer-accessible interface for configuring EDCA parameters.

[GW] I agree that most consumer-purchased Wi-Fi APs do not expose interfaces for this (and even if they did, not many users are likely to read the draft/RFC and change their configuration).  So, this recommendation is primarily for network operators (i.e. ISPs) that provide a Wi-Fi gateway to their customers, and thus could specify that this setting be used by default and/or that an appropriate management interface be provided. It is one of several options that are intended to minimize any incentive for a QB application to mark itself NQB. Note that there are two concerns that we’ve been trying to address here. One is the incentives aspect (where it’s likely that the solution doesn’t need to see 100% deployment to be effective, but the closer the better) and the other is the potential for starvation of QB traffic if uncontrolled amounts of NQB traffic is given higher priority than default.

As has been discussed, for Wi-Fi, both of these concerns are essentially moot in the upstream direction, since there are 31 other codepoints that an application could choose from that today would provide them higher priority than default without the possibility of being subjected to Traffic Protection, and furthermore the recommendations on usage of NQB are not inconsistent with recommendations for other DSCPs that map to these higher priorities.  So, the realistic concern is downstream, where an ISP is wishing to provide NQB isolation in their customers’ LANs (if they are not wishing to do so, they can leave the DSCP as 5, or bleach it to 0, one or the other of which seem also to be highly likely possibilities for an ISP that is unaware of the existence of NQB).  If such an ISP can set the EDCA parameters of their managed Wi-Fi APs, then problem solved in that case.   If they can’t – for whatever reason – then the other remedies discussed in 4.3.1 apply.  This solution isn’t perfect. For example, if a user purchases their own WiFi AP that fully supports the NQB functionality, then how is the ISP to know that they can turn off bleaching or throttling for that customer?  But, the choice of 45 at least allows users of customer-owned APs to achieve isolation of NQB traffic from the majority of QB traffic in the upstream direction.

I suspect that the above 8.3.1 paragraph needs to be bit-bucketed, but I don't understand what to do about WiFi and DSCP 45 in general.

[GW] I disagree for the reasons stated above.


[3] End-system use of DSCP 45

Section 4.1 of the draft says:



   Applications that align with the description of NQB behavior in the

   preceding paragraphs SHOULD identify themselves to the network using

   a Diffserv Code Point (DSCP) of 45 (decimal) so that their packets

   can be queued separately from QB flows.

That strikes me as just plain wrong, as it inflicts DSCP 45 on non-WiFi gear.

[GW] What’s so wrong with that?  If it NQB-aware gear, then great!   If it is NQB-unaware DiffServ gear then it would treat 45 as an unknown DSCP and give it the default PHB.  If it is IP Precedence gear, then all of the arguments above for upstream traffic over WiFi apply.


OTOH, I don't know what to do here, as this sort of simple guidance (always do <X>) is crucial to get application developers to use this sort of new functionality.

[GW] Simple, consistent guidance is key.  As is no regressions in performance.  Several of the existing applications that are NQB-compatible already mark their traffic as CS5 or EF.  Given the text of the draft currently, they can choose to migrate to NQB if they wish.  On existing Wi-Fi or IPP networks, there would be no change in performance.  On upgraded WiFi networks, they would give up EDCA priority in exchange for an isolated and protected queue (there could be regressions in some situations, but benefits in others). On upgraded BE networks (i.e. support for BE and NQB) they would gain isolation and protection.


Thanks, --David

David L. Black, Sr. Distinguished Engineer, Technology & Standards
Infrastructure Solutions Group, Dell Technologies
mobile [phone] [e-mail]<mailto:[e-mail]>