Re: [tsvwg] NQB: Use of DSCP 45

[Greg White <[e-mail]>]

Sebastian,

We've discussed this multiple times in the past, but I will try again.

The goal of writing this draft is develop a technology that will be successfully deployed.  In order to do that, we need to consider the state of the Internet today, and understand the parties that would be involved in NQB being a success, as well as what their motivations & incentives are.   It is easy to develop a new networking technology that can be demonstrated to have significant benefits, but if the path to deployment is unclear, for example, if it depends on multiple independent decision makers all making the same decision in lockstep (i.e. a flag-day), or if interim stages on the path to deployment result in degraded performance, then success can be difficult.  Some refer to this as the "you can't get there from here" problem.  Whereas if each party that needs to implement a component of the technology can do so on their own timeline and they realize a benefit in doing so (or at least no degradation), then barriers to deployment fall away, and the technology has the potential to succeed.  Some refer to this as having a good "incremental deployment" strategy.

In this case, the parties involved are:  application developers, operating system developers, network equipment developers, & network operators.  Among these groups, the ones that probably think about networking the least are application developers. 

In the residential context, application developers don't (in general) build custom applications for specific networks.  Nor is there an API for an application or operating system to query the network to find out which DSCPs/PHBs are supported and which aren't.   There are many applications that are compatible with the definition of NQB that today send their traffic in the WMM voice or video access category, and in most cases they DSCP mark that traffic as CS5, EF, or CS7. If we were to select DSCP 5 as the end-to-end recommended value for NQB with the goal that the traffic is sent in AC_BE everwhere, then these application developers would be faced with a dilemma. Perhaps they understand the benefit offered by NQB (a protected low-latency queue), and would like to take advantage of it, but if today there are no (or very few) WiFi networks that support it, and marking their traffic as DSCP 5 (instead of CS5, EF or CS7) results in degraded performance on ALL of the other networks out there, why would they take the step to adopt NQB marking?  They might choose to wait until at least 50% of networks support it before changing.  On the network equipment side, if no applications mark their packets as NQB, then what incentive is there to implement the PHB?  

On the other hand, if we select the DSCP 45 (which maps into AC_VI by default in a lot of consumer WiFi gear) then the application developer isn't faced with that dilemma. They can switch to using NQB marking, and see *zero* difference in behavior (assuming they were using CS5 or EF previously) on networks that are NQB-unaware, and they will give up EDCA priority in exchange for a protected low latency queue in networks that are NQB-aware. Certainly not all CS5 or EF marked applications would make that decision, perhaps they're not interested in low latency alone, and instead think that they deserve higher-priority in the network. That's fine.  But the applications that were selecting VI simply because the BE queue causes too much latency and latency variation, would have a nice alternative. 

For NQB-unaware ISPs, as we've discussed, most (if not all) residential ISPs *do* understand that they bear some responsibility in managing the DSCP marks on traffic that they send into their customers' networks. The vast majority of residential ISPs currently bleach ALL DSCPs to zero. There may be some ISPs somewhere that do not understand this (and thus don't perform any policing or bleaching), but the choice of DSCP 45 for NQB does NOT increase the attack surface created by those ISPs.  

For ISPs that are NQB-aware, I think the draft provides the right level of guidance.  Do not send traffic marked 45 across network interconnects, re-mark to 5 at those interconnects, allow traffic marked 5 into your core network without bleaching it (and don't give it priority over default traffic), bleach NQB to zero prior to an unmanaged network, unless suitable safeguards are in place. 

So, in my view the current draft creates NO additional risk, and has a good incremental deployment strategy, whereas the approach you've suggested creates a "can't get there from here" situation and would be doomed to failure.

-Greg






On 2/9/22, 1:06 AM, "Sebastian Moeller" <[e-mail]> wrote:

    Dear Greg,



    > On Feb 9, 2022, at 02:38, Greg White <[e-mail]> wrote:
    > 
    > Hi David,
    >  
    > Thanks for the response (and you aren’t the only one guilty of an occasional delay on this topic, unfortunately I’ve had more than my fair share).
    >  
    > I agree with your suggestion to add a note in 8.3.1 about the presumed limited applicability of that *safeguard*.   I can go ahead and make that change. 
    >  
    > I don’t see this as limiting the scope of applicability for the value 45 itself. There has not been a view that there are issues needing remedying for local traffic (e.g. generated by WiFi devices in the network) since the priority conveyed by 45 in legacy/unmanaged networks (including WiFi and IPP) isn’t unique to 45, and the guidance on appropriate use of 45 is not inconsistent with existing guidance for the other DSCPs in that category.

    	[SM] Greg, one of the more recent RFCs of the IETF on that matter https://datatracker.ietf.org/doc/html/rfc8325 explicitly recommends under "8.2.  Security Recommendations for WLAN QoS":
    "Therefore, to mitigate such an attack, it is RECOMMENDED that all
       packets marked to Diffserv Codepoints not authorized or explicitly
       provisioned for use over the wireless network by the network
       administrator be mapped to UP 0; this recommendation applies both at
       the AP (in the downstream direction) and within the operating system
       of the wireless endpoint device (in the upstream direction)."

    I would argue that this explicitly tackles the issue you raised, but comes to a somewhat different conclusion. Personally, I consider the re-map to something harmless a much better policy than saying that we have ignored these side-effects in the past so should continue ignoring them into the future. If we recommend well-managed WiFi networks to re-map to harmless, can we at the same time still argue that DSCPs with known WiFi-priority-side-effects are a non-issue?




    > So in regards to recommendations for end-hosts on the internet, I think 45 is appropriate.  
    >  
    > I think the concern rather was around situations where a network operator could (and maybe even does) police DSCP usage today, and what recommendations should be made for managing/marking NQB traffic, particularly in cases where legacy equipment could be present.  In the residential ISP case, the ISP appears to bear some de facto responsibility to manage the DSCPs that it sends into user networks, because consumer-grade routers generally do not provide DSCP manipulation features.

    	[SM] I think we all agree on that point, good.


    >  Historically this “management” has been implemented as bleaching (AFAIK, although exceptions could certainly exist).

    > Consistent with this, the draft mandates that ISP equipment (effectively) bleach the NQB marking by default.   

    	[SM] The safe by default alternative to this active "neutering" required approach would be the reverse, where a NQB-aware ISP would actively re-map a safe-by-default DSCP value to something else if the ISP is confident that the leaf network can/should handle that (see below for alternatives to DSCP re-marking).

    > We’d like for the draft to chart a path forward where ISPs can enable NQB support for downstream traffic in their customers’ networks if they choose to.  Here, multiple options are included (though it re-reading it, they are a bit scattered in the document).  
    >  
    > In my view, the best option would be for the home router equipment to support NQB.

    	[SM] What does that entail? Do you envision something like a rate-limiter here that assures that NQB's "sparseness" requirement is policed, or what exactly would the home router need to do to make NQB supported?


    >  Fallback options include configuring the EDCA parameters as discussed, or implementing a policing function on NQB-marked traffic (details left for the ISP, but an example given). That first option and the first fallback option are mainly applicable in the case that the ISP provides the home router (though certainly an end-user wouldn’t be precluded from purchasing a router that could implement either of those options) because it would be challenging for the ISP to know whether or not customer-owned equipment supported either option. The second fallback option (while probably not perfect) could be implemented regardless of whether the ISP or the end-user provides the home router.  I think it is important that support for NQB can be offered even to end-users that choose to purchase their own router,

    	[SM] Yeah, but that essentially is already the case independent of the chosen DSCP, most home APs and routers will not touch DSCPs at all, so even in this situations applications using NQB can/will signal their intent to the rest of the network-path, which IMHO is the most important part of NQB.


    > though I realize that this is where most of the concern has been raised, and where ISPs will need to tread more carefully. 

    	[SM] So looking at IEEE 802.11u seems to imply that as part of interworking/hotspot2.0 there are methods to affect AP and client DSCP to AC mapping (called QoS mapping, see e.g. https://www.commscope.com/globalassets/digizuite/1528-1358-wp-how-interworking-works.pdf for a high-level description). With these techniques an NQB-aware ISP can simply configure APs under its control to treat DSCP decimal 5 to any desired AC (and potentially also change the EDCA parameters, but I have not looked into that). The consequence of that is IMHO obvious, participating ISPs already have the tools available to give any DSCP the desired AC treatment (for APs and stations) so why even bother to deploy something with known undesired side-effects in unaware networks like DSCP decimal 45, given that all the safety mechanisms described in the NQB draft require active intervention by a NQB-aware party along the path, so will fail if no such party exists?


    > So, to be clear, I think 45 is still applicable for endpoint applications, and it is applicable for ISPs to deliver traffic so marked into their customers’ networks as long as they deploy home network equipment that supports NQB and/or they implement one of the safeguards listed in the draft.

    	[SM] As shown above the only use-case for 45 is basically leaf networks that are not willingly participating/NQB-aware (others can simply get the desired WiFi treatment for any arbitrary DSCP value), my reading of rfc8325 seems to imply that in such situations we should not use DSCPs with known side effects.

    > Admittedly, my mindset is fairly entrenched in the residential ISP use-case, so I might be missing concerns that apply to other use-cases, but let me know if you think there are gaps that still need to be filled.   

    	[SM] I would argue that the current recommendations might work OK in the case of an NQB-aware residential ISP, but it will be considerably less self-contained in what I consider to be the more likely/relevant case of NQB-unaware leaf networks (at least initially essentially all leaf networks will be NQB-unaware). And as I implied for some time WiFI standards already have all the tools (for over a decade) that allow to combine both giving NQB-aware WiFi networks a way to give NQB the desired special treatment as well as keeping NQB side-effect free in NQB-unaware WiFi networks. Could you please take the time to explain, why these standards are not applicable for NQB's use-case?


    Regards
    	Sebastian

    P.S.: @Jerome, if I misrepresented what 802.11u allows or if that approach (while apparently standard-conform) is impractical for different reasons, I would appreciate if you could set the record straight on these technical details. 



    >  
    > Greg
    >  
    >  
    > From: David Black <[e-mail]>
    > Date: Monday, February 7, 2022 at 7:49 AM
    > To: Greg White <[e-mail]>, "[e-mail]" <[e-mail]>
    > Cc: David Black <[e-mail]>
    > Subject: RE: [tsvwg] NQB: Use of DSCP 45
    >  
    > Hi Greg,
    >  
    > Sorry for the delayed response – somehow this NQB topic got classified into a very-high-latency queue … yes … that was a lousy joke of an excuse ;-) … snarky ripostes, dead cats, and rotten tomatoes should be sent to /dev/null, please.
    >  
    > Seriously, I think this sentence on WiFi AP EDCA parameters from your response is a good point of focus towards finding a way forward:
    >  
    > > [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.
    >  
    > Please revise Section 8.3.1 of the draft to explicitly state this limited scope of applicability of DSCP 45, i.e., it only applies to operators who choose to configure an NQB service in operator-controlled and managed WiFi equipment.
    >  
    > I think that scope of applicability has a couple of consequences:
    > ·         It may well make the EDCA configuration recommendation viable within that limited scope of applicability.
    > ·         It raises concerns about whether the entire Internet ought to use DSCP 45 to indicate NQB at endpoints, when that DSCP has a limited scope of applicability.
    >  
    > Thanks, --David
    >  
    > From: Greg White <[e-mail]> 
    > Sent: Monday, January 10, 2022 7:51 PM
    > To: Black, David; [e-mail]
    > Subject: Re: [tsvwg] NQB: Use of DSCP 45
    >  
    > [EXTERNAL EMAIL] 
    > 
    > 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]