[tsvwg] Re: NQB WiFi issue - progress

["Black, David" <[e-mail]>]

> [SM] Now, NQB also offers a higher chance of e2e traversal (or NQB will have failed), here is the 64K question, from the perspective of a potential abuser, does this outway the small risk of degradation?

That's ultimately an engineering judgement call that I think ought to be noted in the draft.  I would expect that the higher likelihood of traversal is accompanied by a higher likelihood of full NQB support in the traversed networks, bringing traffic protection and shallow queues into play.  I'll post some proposed text changes to the list in the next day or so.

>> In the case of traffic originating outside of the Wi-Fi network, the prioritization of traffic marked with the NQB DSCP via the Video Access Category (if left unchanged)
>> could potentially erode the principle of alignment of incentives discussed in [Section 5]. In order to preserve the incentives principle for NQB, Wi-Fi systems MAY be
>> configured such that the EDCA parameters for the Video Access Category match those of the Best Effort Access Category, which will mean AC_VI is at the same priority
>> level as AC_BE. These changes might not be possible on all Access Points,
> 
>[SM] Or not desirable, if AC_VI's stochastic priority over AC_BE is desired beaviour for different traffic mapped to AC_VI... This ideally would be written explicitly in this section.

My preference continues to be to delete the EDCA text (i.e., the second sentence quoted above, which starts with "In order to ...") as a matter better left to IEEE 802, although I can live with the existing text, especially as it's now a "MAY" requirement.

Thanks, --David

-----Original Message-----
From: Sebastian Moeller <[e-mail]> 
Sent: Tuesday, October 22, 2024 9:01 AM
To: Greg White <g.white=[e-mail]>
Cc: Livingood, Jason <[e-mail]>; Black, David <David.Black=[e-mail]>; tsvwg IETF list <[e-mail]>; Black, David <[e-mail]>
Subject: Re: [tsvwg] NQB WiFi issue - progress


[EXTERNAL EMAIL] 



> On 21. Oct 2024, at 23:10, Greg White <g.white=[e-mail]> wrote:
> 
> Thanks Jason for providing that proposal. I would prefer if we could avoid referencing trademarked names and specific applications, lest we need to get permissions to use those names. Also, things can change and what might be correct today could become incorrect tomorrow. 
> I actually don’t think we need to include them anyway to address David’s request, and instead we could add a couple of sentences that explain why the uplink risk of abuse of the value 45 is more likely *reduced* by assigning it to NQB rather than being increased. 

[SM] I would really like to see the numerical risk/harm analysis for this claim.

> I did pick up on some of the simplifications you made to the text, and also changed the EDCA configuration recommendation to a MAY - in the spirit of compromise, since David seems particularly concerned with that recommendation.  Finally, I rephrased the last SHOULD in the section to make it align better with the Updates to RFC 8325 section.
>  ===========================
> As stated above, the use of DSCP 45 (decimal) for NQB is not expected to create incentives for abuse by non-compliant applications in the Wi-Fi uplink direction.

[SM] This is not incorrect, the autgors clearly do not expect that, but alas, that is a statement more about the authors and less about observable reality. Initially I thought thinking in terms of incentives might be fruitful, but realistically that ends up as everybody assuming their priors to be correct and no means to decide.

>  The fact that the NQB DSCP brings with it the potential for degradation of non-compliant applications (traffic protection and/or a shallow queue resulting in reordering and/or packet loss) plus the existence of multiple other DSCP values that don't carry the risk of degradation, and which could be readily used to obtain prioritization (AC_VI or even AC_VO), leads to the conclusion that NQB non-compliant applications that are seeking prioritization in the Wi-Fi uplink would be better off selecting one of those other DSCPs.

[SM] Now, NQB also offers a higher chance of e2e traversal (or NQB will have failed), here is the 64K question, from the perspective of a potential abuser, does this outway the small risk of degradation?


>  In the case of traffic originating outside of the Wi-Fi network, the prioritization of traffic marked with the NQB DSCP via the Video Access Category (if left unchanged) could potentially erode the principle of alignment of incentives discussed in [Section 5]. In order to preserve the incentives principle for NQB, Wi-Fi systems MAY be configured such that the EDCA parameters for the Video Access Category match those of the Best Effort Access Category, which will mean AC_VI is at the same priority level as AC_BE. These changes might not be possible on all Access Points,

[SM] Or not desirable, if AC_VI's stochastic priority over AC_BE is desired beaviour for different traffic mapped to AC_VI... This ideally would be written explicitly in this section.

> and in any case the requirements and recommendations in [Section 4.4.1] would apply in this situation.
>  Similarly, systems that utilize [RFC8325] but cannot provide a separate AC_BE queue for NQB traffic, SHOULD map the recommended NQB DSCP 45 (decimal) (or the locally determined alternative) to UP_5 in the "Video" Access Category (see [Section 7.3.2]).
> =========================
>  These three paragraphs would replace the text in the two paragraphs at the end of Section 7.3.1:
> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-25.html*section-7.3.1-7__;Iw!!LpKI!hMfKvu4dkZBAepGf1cVdoLaidH1OzyfK1-Qd1U6XYmKTfk3Dl3Sx4IWiuL_ebvORpd47O189CXWgWdHg8w$ [ietf[.]org]
>  -Greg
>  From: Jason Livingood <[e-mail]>
> Date: Monday, October 7, 2024 at 8:55 AM
> To: "Black, David" <David.Black=[e-mail]>, Greg White <[e-mail]>, tsvwg IETF list <[e-mail]>
> Cc: David Black <[e-mail]>
> Subject: Re: [tsvwg] Re: NQB WiFi issue - progress
>  > The current version of the draft contains this text at the end of Section 7.3.1:
> > Please propose text modifications and/or additional text to explain why there’s no issue with WiFi endpoints that originate NQB traffic at UP 5 on pre-RFC8325 access points, or on RFC8325 access points that don’t fully support the NQB PHB.
>  Proposed new paragraph to simplify things & try to close this discussion:
>   In the default WMM configuration in most Access Points, traffic marked with the NQB DSCP will be mapped to the Video Access WMM Category (AC_VI), which will prioritize NQB traffic above the Best Effort WMM Category (AC_BE). Wi-Fi systems SHOULD be configured so that the EDCA parameters for the Video Access Category match those of the Best Effort Access Category, which will mean AC_VI is at the same priority level as AC_BE. Older Access Points may not support such a configuration, meaning NQB traffic marked as AC_VI will be prioritized above AC_BE. That should not have unexpected side effects on these older Access Points, given that there is already extensive use of the Voice and Video access categories (AC_VO and AC_VI) by applications used by billions of users over Wi-Fi networks today, such as Microsoft Teams, Microsoft Xbox, Zoom, Cisco WebEx, Apple Facetime, WhatsApp, Fortnite, and many others.
>   From: Greg White <[e-mail]>
> Sent: Thursday, October 3, 2024 8:45 PM
> To: Black, David <[e-mail]>; tsvwg IETF list <[e-mail]>
> Subject: Re: [tsvwg] NQB WiFi issue - progress
>  [EXTERNAL EMAIL] David,
> Thanks for your reply. I’ll reiterate that I believe firmly that this is a non-issue.
> See responses [GW3] below. -Greg
>   From: David Black <[e-mail]>
> Date: Thursday, October 3, 2024 at 3:18 AM
> To: Greg White <[e-mail]>, tsvwg IETF list <[e-mail]>
> Cc: David Black <[e-mail]>
> Subject: RE: [tsvwg] NQB WiFi issue - progress
>  On the remaining open issue:
>  > >> C. For outbound NQB traffic where the ISP is unable to manage the AP, NQB traffic at UP_5 and its impacts cannot be prevented, although the impacts could be tolerable …
> > > [GW] This should say “… the impacts should be tolerable, since the NQB traffic behaves in accordance with the NQB sender requirements.” The draft does not recommend that
> > > non-compliant traffic use DSCP 45.
> > > In the absence of incentives for NQB-compliant sender behavior, expecting senders to conform with that behavior is a heroic assumption, especially given the draft’s extensive discussion
> > of sender behavior incentives provided by networks that support NQB.  The open issue is: Why will bad sender behavior not be a problem in practice?
> > > I don’t view a “sender could have done even more damage with a different UP_5 DSCP” response as sufficient by itself because the IETF does not recommend sending best effort traffic with that DSCP.
> > > [GW2] I don’t follow your logic. You’ve identified the open issue as being a practical one (as opposed to a philosophical one). Yet it seems that you are discounting the practical response
> > on philosophical grounds.  To borrow a well-worn phrase – “Just because you can doesn’t mean you should.” … or in this case, “… doesn’t mean you SHOULD.”
>  The “bad sender” discussion falls under “Just because you can” and I agree that malicious usage of UP_5 is already possible via a number of DSCPs, a situation that using DSCP 45 won’t change.  What NQB does change is that NQB deployment is expected to enable DSCP 45 to pass through quite a bit more network infrastructure, which might (or might not) increase that DSCP’s attractiveness to a bad sender.
>  [GW3] To what end? A DSCP passing though infrastructure doesn’t provide any advantage unless it is treated differently.  Networks that pass 45 but don’t pass other AC_VI DSCPs would presumably be “NQB-aware” and hence treating it the same as Default and/or implementing traffic protection or shallow buffers which would turn this into a disadvantage for the “bad sender”.  If such a network isn’t “NQB-aware” and is only passing 45 and not other AC_VI DSCPs, then that is not a situation created by the NQB draft.  So, the corner case where there is an advantage created by the NQB draft is an improperly implemented NQB network, and all other cases it is a disadvantage and would require active probing of the path to avoid degradation.  Is there another scenario?
>  If the “bad sender” was all that needed to be dealt with, this would likely be headed for a paragraph or two of additional security considerations material.  I do think some additional security considerations material is needed on this topic, but (as noted above) I don’t think that’s sufficient on its own.
>  [GW3] This topic is already sufficiently covered in the security considerations section.
>  We need to also be concerned with “good senders” who attempt to follow the draft’s “SHOULD” requirements for NQB sender behavior but don’t get that right, initially and/or due to drift over time.  That’s understandable, e.g., for an app developer who is far more concerned with the app doing something useful for its users than whether the app complies with the NQB sender requirements.  The draft has gone to significant efforts to make sure that networks that support NQB provide incentives (traffic protection, shallow queues) for NQB senders to comply with those requirements, e.g., those incentives are able to cause an app that seriously violates the NQB sender requirements to degrade in a fashion that is likely to be visible to users of the app.
>  [GW3] It doesn’t matter whether the sender in question is a “bad sender” or a “good sender” who has drifted to the bad side.  If they are non-compliant, then they are non-compliant.  In our earlier exchanges we’ve agreed that there isn’t an issue with compliant senders, nor is there an issue with non-compliant senders that make static decisions about the use of DSCP 45 (where the incentives for good behavior only need to be present on some links). So, the remaining concern of yours that we’ve been debating is your “dynamic probing” case.  For that case, my previous arguments all apply.  The “good sender gone bad” would either need to switch to a different AC_VI DSCP (and their life would be good), or implement dynamic probing (and likely suffer because of it), or they would suffer degradations in NQB-aware networks. 
>  Turning to networks that don’t support NQB, this comment appears to be arguing that such incentives are not necessary to obtain sender compliance with NQB sender requirements:
>  > [GW2] From a philosophical perspective, the IETF guidance in the draft is only for low-data-rate, non-bursty traffic. There is no recommendation that non-compliant
> > traffic should use DSCP 45, in fact the guidance in the draft is the opposite!  [rest of paragraph about “bad senders” snipped]
>  I read that as effectively saying that the IETF is issuing an edict that traffic that does not comply with NQB sender requirements is not to use DSCP 45, and that edict is all that needed to resolve this matter for networks that don’t support NQB.  As I wrote earlier in this thread, that’s a heroic assumption – I’m not willing to accept it without significant additional explanation and justification. 
>  [GW3] This was a response to the philosophical part of your comment: “I don’t view a “sender could have done even more damage with a different UP_5 DSCP” response as sufficient by itself because the IETF does not recommend sending best effort traffic with that DSCP.” In which you were saying that the practical arguments (about other UP_5 DSCPs and the folly of dynamic probing) don’t solve the philosophical problem of the IETF giving applications the green light to send best effort traffic with DSCP 45.  I was pointing out that the IETF green light is only for low data rate traffic, not for traffic that would potentially cause problems, so I think your philosophical argument doesn’t hold water.
>  In more detail, what I don’t understand is why all those incentives are crucial to obtaining NQB sender compliance with the NQB sender requirements in networks that support NQB but are somehow not needed to obtain the exact same NQB sender compliance in networks that don’t support NQB.  What have I missed?
>  [GW3] Just that the practicality of determining whether those incentive-creating features (traffic protection, shallow buffers) are present or not is more trouble than using a different DSCP if you are non-compliant and trying to get high priority in upstream legacy Wi-Fi networks.   I went looking for that explanation and justification in the last paragraph of your comments, but its opening sentences make no sense to me:
>  > [GW2] Also, in the intersection of philosophy and practice, don’t forget, the scenario we’re discussing here is not a DiffServ compliant one
> > (neither in terms of DSCP usage compliance, nor in network PHB implementation).  So, *all* traffic is effectively “best effort” from a network policy perspective.
>  That appears to be arguing that EF and VOICE-ADMIT traffic is “best effort” on pre-RFC8325 WiFi APs, which I think is simply wrong.  The rest of the paragraph goes on to speculate about an interpretation of IETF standards wrt WiFi traffic that neither you nor I agree with, so I’m again confused - what was the point that this paragraph was intended to make?
>  [GW3] But it isn’t wrong! In the scenario we’re discussing, there’s no such thing as EF and VOICE-ADMIT traffic.  There could be traffic that marks itself with the DSCP 44 or 46, but that doesn’t make it EF or VOICE-ADMIT. Any application on a Wi-Fi host is completely free to mark its traffic with whichever DSCP it wants.  It could just as easily be a malware program as opposed to a voice application.  Just because it unilaterally chooses to mark its packets 46 doesn’t mean that the operator of the network has agreed that it is allowed to get expedited forwarding.  There has been no policy agreement that this application should be given priority, hence from a network policy perspective an EF mark doesn’t convey anything! All applications, regardless of which DSCP they choose to mark their traffic with, should be effectively considered “best effort” from a network policy perspective.  So, when you say that your concern (which you’ve been clear is specific to this scenario) arises because the IETF would be recommending that “best effort” traffic get UP_5, my point was that *all* traffic is effectively best effort here, so that concern is meaningless.  Additionally, I was pointing out that existing IETF guidance on DSCP marking of application types (even if it were magically followed) shouldn’t – in my opinion – be interpreted as the IETF granting exclusive rights for those application types to use AC_VI on all unmanaged legacy Wi-Fi networks in the world, with all other application types being mandated to use AC_BE or AC_BK. So, if you say that you have a philosophical problem with the IETF recommending that a class of “best effort” traffic get access to AC_VI as a result of the legacy DSCP mapping, I would say “and who gave the IETF the right to dictate otherwise?”.  Some that I’ve spoken to in the WFA have said “NQB traffic *belongs* in AC_VI!”
>    Thanks, --David
>  From: Greg White <[e-mail]>
> Sent: Wednesday, October 2, 2024 12:37 PM
> To: Black, David <[e-mail]>; Black, David <David.Black=[e-mail]>; tsvwg IETF list <[e-mail]>
> Subject: Re: [tsvwg] NQB WiFi issue - progress
>  [EXTERNAL EMAIL] Thanks for the response.  Please see replies below [GW2].
>  From: David Black <[e-mail]>
> Date: Wednesday, October 2, 2024 at 1:27 AM
> To: Greg White <[e-mail]>, "Black, David" <David.Black=[e-mail]>, tsvwg IETF list <[e-mail]>
> Cc: David Black <[e-mail]>
> Subject: RE: [tsvwg] NQB WiFi issue - progress
>  Greg,
>  Sorry for the delay – I had not realized that you had put both process and technical discussion into the same message.  On the technical matters, I think 2 out of 3 are no longer open issues:
>  >> A. For inbound NQB traffic, the ISP has available tools (e.g., bleaching DSCP 45 to zero) to control the impacts of DSCP 45, as Greg has explained. 
>  The two of us agree on the technical aspects, namely that the ISP has available tools.  What remains is how to discuss those available tools, which is editorial.  It would be helpful if the edits provided some rationale for why it’s reasonable to expect the ISP to use those tools even though the ISP does not support NQB – part of the rationale is likely to be that some use of those tools is already required in practice, e.g., to prevent large amounts of CS6 and CS7 traffic from being sent into customer networks.
>  [GW2] Ok.  I can work up some editorial changes.
>  >> B. For outbound NQB traffic where the ISP is able to manage the AP, the draft strongly suggests (SHOULD) configuring “the EDCA parameters for the
> >> Video Access Category [to] match those of the Best Effort Access Category”. 
>  In the interest of making progress, I’m not going to pursue this concern any further, although I thought we’d agreed privately to change that “SHOULD” to a “MAY”.  That said, I can live with the “SHOULD” as-is because an ISP that fouls up the EDCA parameter configuration in an AP managed by that ISP has only itself to blame … and will have no lack of incentive to get that configuration right.
>  So, that’s 2 out of 3 dealt with, leaving …
>  >> C. For outbound NQB traffic where the ISP is unable to manage the AP, NQB traffic at UP_5 and its impacts cannot be prevented, although the impacts could be tolerable …
> > [GW] This should say “… the impacts should be tolerable, since the NQB traffic behaves in accordance with the NQB sender requirements.” The draft does not recommend that
> > non-compliant traffic use DSCP 45.
>  In the absence of incentives for NQB-compliant sender behavior, expecting senders to conform with that behavior is a heroic assumption, especially given the draft’s extensive discussion of sender behavior incentives provided by networks that support NQB.  The open issue is: Why will bad sender behavior not be a problem in practice?
>  I don’t view a “sender could have done even more damage with a different UP_5 DSCP” response as sufficient by itself because the IETF does not recommend sending best effort traffic with that DSCP.
>  [GW2] I don’t follow your logic. You’ve identified the open issue as being a practical one (as opposed to a philosophical one). Yet it seems that you are discounting the practical response on philosophical grounds.
>  [GW2] From a practical perspective, let me reiterate:  the NQB draft doesn’t create the DSCP value 45, nor does it create the historical mapping to UP_5. Those have existed and will continue to exist if NQB never becomes an RFC.  I can’t see any reason why a “bad sender” would want to put themselves through the pain of trying to use NQB 45, when they have 15 other DSCPs to choose from that don’t cause that pain. Moreover, if (per Sebastian’s want) we were to change the DSCP to 5, that wouldn’t prevent a bad sender from using 45, in fact it would open up that 16th DSCP for them!  So, I’ll ask you again: why would a non-NQB-compliant application choose to suffer the pain and difficulty of dynamically probing for the presence of traffic protection or shallow queues, as opposed to using one of the other DSCPs?
>  [GW2] From a philosophical perspective, the IETF guidance in the draft is only for low-data-rate, non-bursty traffic. There is no recommendation that non-compliant traffic should use DSCP 45, in fact the guidance in the draft is the opposite!  It seems as if you are saying that a “bad sender” would somehow prefer to violate this guidance, rather than use a different DSCP.  Why would they?  Is your theory that they wouldn’t choose a different DSCP because doing so wouldn’t align with IETF guidance? Say the application isn’t an H.323/V2 video conference, so they certainly can’t abuse AF41, but abusing NQB is totally fine?! 
>  [GW2] Also, in the intersection of philosophy and practice, don’t forget, the scenario we’re discussing here is not a DiffServ compliant one (neither in terms of DSCP usage compliance, nor in network PHB implementation).  So, *all* traffic is effectively “best effort” from a network policy perspective. I can see no philosophical nor practical reason why we should interpret the IETF guidance to be that applications that self-describe as video conferencing, interactive gaming and telephony are granted access to the Video Access Category in all unmanaged Wi-Fi networks worldwide, and all other applications are relegated to AC_BE or AC_BK. I certainly wouldn’t agree that the IETF has granted this exclusive right, and I imagine that there would be a lot of people in the IEEE802.11 and Wi-Fi Alliance that would similarly disagree.  I think this is the concept that Jason was alluding to in his post last week. 
>    Thanks, --David
>  From: Greg White <[e-mail]>
> Sent: Tuesday, October 1, 2024 11:20 AM
> To: Black, David <David.Black=[e-mail]>; tsvwg IETF list <[e-mail]>
> Cc: Black, David <[e-mail]>
> Subject: Re: [tsvwg] NQB WiFi issue - progress
>  [EXTERNAL EMAIL] David,
>  Have you had a chance to think about the questions that I asked and points I raised last week (below)?  If you still believe there is an issue to be solved in light of those points, could you explain your logic?
>  Thanks,
> Greg
>   From: Greg White <[e-mail]>
> Date: Tuesday, September 24, 2024 at 8:27 PM
> To: "Black, David" <David.Black=[e-mail]>, tsvwg IETF list <[e-mail]>
> Cc: David Black <[e-mail]>
> Subject: Re: [tsvwg] NQB WiFi issue - progress
>  David,
>  Thank you for summarizing your ideas on this thread, though you missed at least a few of the major points (noted below). 
>  I also think we need to take a step back and summarize where we are.  We completed a second WGLC and the chairs have declared that WG consensus is to publish the draft with DSCP 45.  This recent discussion started by you floating what you thought was an issue with the draft, and asking whether anyone else on the WG felt that it was an issue.  I’m not sure exactly how (rough) consensus works in this case, but you had three people respond that they felt it was not an issue.  Sebastian has made it clear that he will oppose publication of the NQB draft as RFC unless the DSCP is changed to a different value (a position that doesn’t align with WG consensus).
>  So, I think the tally is:
> 1 person thinks there is an issue
> 3 people think it is not an issue
> 1 person has essentially stated that they will oppose NQB regardless
>  Unless this is sufficient to close the discussion, I’d like to hear from others in the WG.   
>  -Greg
>  From: "Black, David" <David.Black=[e-mail]>
> Date: Monday, September 23, 2024 at 8:13 PM
> To: tsvwg IETF list <[e-mail]>
> Cc: David Black <[e-mail]>
> Subject: [tsvwg] NQB WiFi issue - progress
>  Reflecting on a week+ of discussion, I’ve learned a few things and have some suggestions for making progress on the NQB WiFi issue that I raised.
>  It appears that the underlying cause of that WiFi issue is that the NQB draft has not sufficiently considered the effects of DSCP 45 on older (pre-RFC8325) WiFi access points (APs) (which don’t support NQB) when such an AP is attached to a network (e.g., ISP network) that doesn’t support NQB (and hence doesn’t use either a shallow queue or traffic protection for NQB traffic).  This is important to cover because the NQB draft specifies that a subset of best-effort traffic be carried with a DSCP that causes better-than-best effort traffic handling at such APs – that is what distinguishes the NQB draft from RFCs that specify other PHBs that are not intended for best-effort traffic.
>  The considerations can be usefully divided between inbound NQB traffic (from network to AP) and outbound NQB traffic (originated by a WiFi endpoint) and depend whether the AP is managed by the ISP.   In more detail:
>  A.     For inbound NQB traffic, the ISP has available tools (e.g., bleaching DSCP 45 to zero) to control the impacts of DSCP 45, as Greg has explained.  I agree, although I’d like to see discussion on whether & why it’s reasonable to expect an ISP that does not support the NQB PHB to nonetheless have to use those tools to deal with inbound NQB traffic.  One possibility is that there’s nothing to be done because the tools are already in use (e.g., ISP already bleaches DSCP 45 to zero).
>  [GW] One point you missed is that an ISP that does not support the NQB PHB and does not bleach DSCP 45 to zero is exceedingly unlikely to *only* pass the value 45 through to their users.  They are very likely exposing their users to many or all other DSCPs (and similar outcomes, such as Sebastian’s statement that his ISP apparently passes all DSCPs, but with the 3 LSBs zeroed). So, DSCP 45 being used for NQB-compliant traffic doesn’t seem to me to introduce any new risk.
>  B.     For outbound NQB traffic where the ISP is able to manage the AP, the draft strongly suggests (SHOULD) configuring “the EDCA parameters for the Video Access Category [to] match those of the Best Effort Access Category”.  My initial reaction to that has been skepticism, as based on the relative amounts of traffic involved that “SHOULD” strikes me as the NQB traffic “tail” attempting to “wag” the Video traffic “dog”.  I emphasize that this is my *initial* reaction, and a well-reasoned discussion about why that is a bad analogy would be interesting.
>  [GW] In this situation of unpoliced upstream DSCP (AC) usage, what makes you think that traffic currently using the Video Access category is actually Video?  More importantly, what makes you think that an ISP would desire that any application that deems itself to deserve higher priority actually should be entitled to get it? Since there is no DSCP / AC policy enforcement possible in this situation, the SHOULD mentioned above actually seems to me to be a prudent recommendation in general (even without considering NQB).  C.    For outbound NQB traffic where the ISP is unable to manage the AP, NQB traffic at UP_5 and its impacts cannot be prevented, although the impacts could be tolerable if the NQB traffic behaves at least somewhat in accordance with the NQB sender requirements and/or there’s already significant UP_5 traffic on that AP to which the NQB traffic is a minor addition.  Discussion of existing use of the EF DSCP 46 suggests that there will often be other UP_5 traffic at that AP. 
>  [GW] This should say “… the impacts should be tolerable, since the NQB traffic behaves in accordance with the NQB sender requirements.” The draft does not recommend that non-compliant traffic use DSCP 45. Also, the tolerability of NQB traffic using UP_5 doesn’t depend on how much other (non-NQB) traffic is actually using UP_5 on the AP.
>  I also agree with Greg’s discussion that app developers who make static decisions about whether/how to use DSCP 45 are likely to be conservative based on not knowing whether or not a shallow queue or traffic protection will be encountered.  That leaves dynamic probing, as noted in my other message.
>  [GW] For your “dynamic probing” theory, you need to explain why the non-NQB-compliant prober would choose DSCP 45 over any of the other 15 DSCPs that map to AC_VI.  In my view they could simply pick one of the others and not need to implement this dynamic probing function.  For clarity, topics A-C above are intended as “places to dig” towards writing text for the draft to address the effects of DSCP 45 on older (pre-RFC8325) WiFi APs when such APs are attached to a network that doesn’t support NQB.  Ultimately, I would hope the draft will make the case for older WiFi APs that there’s an engineering tradeoff where the clear benefits of DSCP 45 for such APs attached to networks that support NQB (as described in section 7.3.1 of the draft) significantly outweigh the potential problems and effects for such APs attached to networks that don’t support NQB, and that the potential problems and effects are reasonable to deal with.
>  At least for me, this is progress from the Vancouver meeting where I was at a loss for how to go about addressing this WiFi issue.  Finally, this message should not be taken as dictating direction – how much of the above needs to be done is ultimately a WG decision on what is appropriate to cover in the NQB draft.  My current view is that all three topics (A-C) are appropriate to cover.
>  Thanks, --David
>  David L. Black, Sr. Distinguished Engineer, Technology & Standards
> Infrastructure Solutions Group, Dell Technologies
> mobile [phone] [e-mail]