Re: [tsvwg] NQB - a non-Default approach

[Sebastian Moeller <[e-mail]>]

Hi David,


> On Aug 11, 2022, at 21:03, Black, David <David.Black=[e-mail]> wrote:
> 
> Setting aside the rest of the discussion to focus on the core concern:
>  
> > There is a difference between having the draft say “the purpose of NQB is to provide a high priority service for a subset of traffic” and saying “the purpose of the NQB is to provide
> > a separate queue at equal priority, but there are certain cases where this isn’t easy to implement, and for some of those cases, having NQB get higher priority is something that we can live with”.
>  
> fine, starting from the latter and attempting to state it crisply … the problem is not “where this isn’t easy to implement,” – the problem is “where this simply won’t work,”
> e.g., use of AC_BE in deployed WiFi gear.

	[SM] This has been claimed so far, but not supported by data showing that this is truly worse than the alternative. There are IMHO two conditions worth disambiguating here:
a) the WiFi link is not the current bottleneck. At that point does the selected queue actually matter significantly?
b) the non-NQB-enabled/aware WiFi-link is the bottleneck, will using AC_VI actually be closer in performance to the draft's stated goals than all in AC_BE, and at what cost to traffic in AC_BE? Especially since none of the mitigating factors for NQB like a rate limiter will be available at the node in question. Next question would be to estimate, how common are the cases a) and b) going to be.


>  
> Saying that something “won’t work” in some cases and describing what “we can live” with in those cases is a fine thing to do, e.g.:
> 	• SHOULD NOT prioritize NQB traffic over Default traffic,
> 	• unless absence of prioritization would result in NQB traffic and Default traffic sharing the same queue.
> There’s plenty of material already in the draft that explains the negative consequences of NQB traffic and Default traffic sharing the same queue. 
>  
> That latter “unless” bullet sounds like a good characterization of where things go wrong if NQB is sent over WiFi using AC_BE, which in turn justifies doing something that results in prioritization (e.g., use DSCP 45) to prevent NQB and Default from sharing the same queue.  If that is done, the draft will need to avoid blanket statements that don’t allow for the “unless” e.g., “the NQB traffic is to be given a separate queue with priority equal to default traffic.”

	[SM] This approach would, I admit, fix up the current self-contradiction I see in the current draft. (Modulo the fact that all low-latency providers, be it LL-DOCSIS or L4S seem to depend on priority scheduling of some kind or another themselves, albeit one with heuristics to "hide" that priority scheduling in some common cases, but that is a different discussion).


Regards
	Sebastian


>  
> Thanks, --David
>  
> From: Greg White <[e-mail]> 
> Sent: Tuesday, August 9, 2022 6:20 PM
> To: Black, David; [e-mail]
> Subject: Re: [tsvwg] NQB - a non-Default approach
>  
> [EXTERNAL EMAIL] 
> 
> Hi David,
>  
> See responses below [GW].
>  
> -Greg
>  
> From: David Black <[e-mail]>
> Date: Monday, August 8, 2022 at 4:08 PM
> To: Greg White <[e-mail]>, "[e-mail]" <[e-mail]>
> Cc: David Black <[e-mail]>
> Subject: RE: [tsvwg] NQB - a non-Default approach
>  
> Hi Greg,
>  
> We may be using different notions of what the word priority means.  I'm using "priority" as shorthand for the concept of "probability of timely forwarding" found in RFC 2474, section 4.2.2.2, e.g., higher priority means higher "probability of timely forwarding … under reasonable operating conditions and traffic loads."  See the first paragraph of RFC 2474 section 4.2.2.2 for the full context (https://datatracker.ietf.org/doc/html/rfc2474#section-4.2.2.2 [datatracker.ietf.org]).
> [GW] I’ve generally been using the term priority to refer to situations where a scheduler preferentially forwards packets from one class of traffic over another. This is the case with WMM in its default configuration.
>  
> Under that notion of priority, I see a clear contradiction between "NQB would similarly be doomed to failure IMO if it were defined as a high priority service." and the explanation in https://mailarchive.ietf.org/arch/msg/tsvwg/fBcm6eUfv9egmlo-TX8N3OAFM_A/ [mailarchive.ietf.org] that NQB deployment on WiFi requires AC_VI, which *is* a high priority service (e.g., seehttps://en.wikipedia.org/wiki/Wireless_Multimedia_Extensions [en.wikipedia.org]).
>  
> [GW] In the notion of priority that’s relevant here (i.e. WMM), there’s not a contradiction.  There is a difference between having the draft say “the purpose of NQB is to provide a high priority service for a subset of traffic” and saying “the purpose of the NQB is to provide a separate queue at equal priority, but there are certain cases where this isn’t easy to implement, and for some of those cases, having NQB get higher priority is something that we can live with”.  The benefits of NQB are provided by segregating NQB traffic from QB traffic. When these two classes are scheduled at equal priority, NQB gets a benefit without negatively impacting QB traffic. Would it get an additional benefit if it were scheduled with higher priority? Of course it would, but this additional benefit would come at the expense of the QB traffic. If we were to define NQB as high priority, and recommend that it be given high priority in networks that support the PHB, then IMO the result would be that applications that wish to be given a greater share of network resources (whether they comply with the NQB definition or not) would be tempted to mark their traffic as NQB, and ISPs would (like today) decide that they need to bleach the codepoint because it would be impractical (both technically and from a public policy perspective) for them to police its use. Moreover, it would be building into the architecture an unnecessary subjective judgement that sparse traffic is more important than bulk traffic.  There are already far too many (in my opinion) cases where these sorts of value judgements have been enshrined in the “old school” concepts of Quality of Service.   
>  
> [GW] If most existing Wi-Fi gear had an unused queue available that is scheduled with the same priority as AC_BE, then we’d be using that. In fact the recommendations are that existing Wi-Fi gear be configured to make this the case, and for future Wi-Fi gear to do this by design.  But, we simply have to work with the gear that is out there now (much of which likely won’t be reconfigured any time soon), which (by virtue of the choice of 45) meets some of the PHB requirements, and we can live with the fact that it doesn’t meet all of them.   
>  
> To put this more bluntly, I fully agree with Sebastian's objection to "gaming the default WiFi DSCP to AC mapping for a PHB that goes a long way arguing why it is not a priority based mechanism."  I can see the point of taking advantage of that mapping to improve NQB traffic behavior over AC_BE, but to claim that the result is not prioritization is simply not credible.
>  
> [GW] You (and Sebastian) are mischaracterizing it. The draft does NOT claim that this result is not prioritization, and it also does NOT claim that this fully complies with the PHB requirements. Please re-read section 8.3 and point to where it claims either of those things.  If you find language that is confusing on that point, we can fix it.  The choice of 45 is motivated by the pragmatic desires to: a) provide NQB traffic with a separate queue from QB traffic in existing Wi-Fi, and b) not put application developers in an untenable position. Yes, this does, in many cases, result in NQB being prioritized on existing Wi-Fi, but I argue that in the upstream direction, the downside (risk) of this is nearly zero, since there is no policy enforcement point between the application and the Wi-Fi link, and any QB application that is wishing to simply get more throughput could already select AC_VI or AC_VO to get high priority by using one of the 31 other DSCPs that provide this (and selecting one of those other DSCPs would circumvent any NQB Traffic Protection in place in the network). In the downstream direction, I have agreed with Sebastian that there is some risk here, and have added safeguards in the draft. I believe that risk is minimized by those recommendations in the draft (and existing common safety practices for ISPs that aren’t aware of NQB), whereas I think Sebastian may be less convinced on that point.
>  
> Moving on, to this question: "Furthermore, why would we need 45 if we already have CS5 and EF that request higher priority?"  We've been about here before, and the result was VOICE-ADMIT (RFC 5865, https://datatracker.ietf.org/doc/html/rfc5865 [datatracker.ietf.org]), which dealt with the lack of admission control in EF.  I view NQB as having an analogous traffic behavior/governance difference with existing PHBs.  An important element of that viewpoint is my overall sense is that traffic protection mechanisms such as queue protection are likely to be crucial to successful deployment of NQB, as recommended in Section 5.2 of the NQB draft.
> 
> I believe core of the argument against DSCP 45 being associated with higher priority ("Your comment that 45 “naturally” requests higher priority is not something that is supported in the Standards Track RFCs.")is seriously flawed for several reasons:
> [GW] I disagree. I think there was a historical definition and use of the bits 0-2 of the DSCP field (IP Precedence), under which the value 45 would encode higher priority. I think the RFCs since then have attempted to move away from that historical definition, while trying to maintain some limited backward compatibility with it.
>  
> ·        RFC 2474 (Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers), which is a Standards Track RFC contains this text in section 4.2.2.3: " the vendor or the network administrator MAY configure the network node to map codepoints to PHBs irrespective of bits 3-5 of the DSCP field to yield a network that is compatible with historical IP Precedence use.  Thus, for example, codepoint '011010' would map to the same PHB as codepoint '011000'."  That doesn't use the word "naturally" but it does support the attention paid to bits 0-2 of the DSCP field.
> [GW] You and I are reading that sentence differently.  The section (4.2) where it is found seems to be concerned with incremental deployability of DiffServ. It leads with:
>    Further, IP systems today understand the
>    location of the IP Precedence field, and thus if these bits are used
>    in a similar manner as DS-compliant equipment is deployed,
>    significant failures are not likely during early deployment.  In
>    other words, strict DS-compliance need not be ubiquitous even within
>    a single service provider's network if bits 0-2 of the DSCP field are
>    employed in a manner similar to, or subsuming, the deployed uses of
>    the IP Precedence field.
> In that context, the sentence you quoted describes how, at the time, *new* DiffServ gear could be incorporated into a network that was still using the “historical” IP Precedence concept.   That section (4.2.2.3) in particular is titled “Using the Class Selector PHB Requirements for IP Precedence Compatibility”.   Section 4.2.2.1 defines *only* the values DSCP = ‘xxx000’ to be the class selector codepoints.
>  
> ·        Limiting the scope of discussion to Standards Track RFCs excludes RFC 2475 (An Architecture for Differentiated Services), which is an Informational RFC.  I hope that this exclusion was not intended …
> ·        RFC 4594 (Configuration Guidelines for DiffServ Service Classes) is about the best overall guide to the space of Diffserv PHBs and DSCPs – the influence of the RFC 2474 class selector framework (see above on bits 0-2 of the DSCP field) on DSCP usage is clear from reading the RFC as a whole.  The one obvious exception is use of CS1 for low-priority service, which has been changed by RFC 8622 (A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services).
>  
> [GW] I think the upshot of all of this is that the RFCs provide recommendations and hints at the intentions of the IETF participants at the time, but leave a lot of room for differing implementations and interpretations. As part of the discussion on NQB over the past 4 years, it has become apparent to me that some folks have very strong (and sometimes strongly differing) opinions on what *should* be done with DSCPs in the Internet.  Of equal importance is what networks actually do, and what they might be willing and able to do in the future.   I believe that there are networks which have chosen to aggregate ranges of DSCPs into treatment aggregates along the lines of IP Precedence (but with perhaps a bit more flexibility), and there are others that bleach all (or nearly all) DSCPs at ingress and use the field for their own internal purposes, entirely unconstrained by the historic numerical orderings and the IANA assignments, and there are all of the legacy Wi-Fi networks that aggregate 001xxx & 010xxx as Background, 000xxx & 011xxx as Best Effort, 10xxxx as Video, 11xxxx as Voice (which isn’t exactly IP Precedence), and Standards Track RFC 8325 which tells Wi-Fi implementers to map only two (optionally 4) specific DSCPs to Voice, five DSCPs to Video, and two DSCPs to Background, with the remaining 55 (or 53) DSCPs treated as Best Effort. I’d also point out that RFC 8325 (Section 2) specifically discusses the fact that IEEE 802.11 is not able to support many of the DiffServ PHBs, including EF and AF, and only loosely supports Default and Lower Effort. So, the fact that it doesn’t *by default* support all of the NQB PHB requirements shouldn’t cause us to have to redefine NQB.  These intersections are not architecturally perfect, and they don’t need to be.
>  
> > The fact that 45 will end up with high priority in some networks today is a deficiency that I think we have to live with in the near term
> > in order for NQB to be successful (this is summarized in the mailarchive link you provided below). But, our goal should be to minimize this deficiency, rather than embrace it.
>  
> We've been fighting to minimize that for quite some time now … and it's not going well … so, perhaps we should do something different … and to that end, I think this is a good initial step:
>  
> > As written, these statements do not refer to the value 5 at all. Perhaps that addresses your (and Sebastian’s) concern about IANA
> > assigning two DSCPs for a single purpose. I also think this is consistent with the discussion in the TSVWG session regarding the “local-use” terminology.
>  
> [GW] Ok, thanks for that.  I’d characterize it as trying to find recommendations (and specific wordings of recommendations) that provide the most benefit while stepping on the fewest toes.  Along the lines of the “flexibility” in potential interpretations of RFC 2474, this will probably involve loosening the language some. My hope is that we can avoid loosening it so much that we’ve not made any improvement over the current state of DiffServ deployment in the Internet.
>  
> [GW] I’ll work on writing up an update to the draft that incorporates this change, as well as summarizing (finally) some of the other off-list comments that I’ve received.
>  
> Thanks, --David
>  
> From: Greg White <[e-mail]> 
> Sent: Thursday, August 4, 2022 12:15 PM
> To: Black, David; [e-mail]
> Subject: Re: [tsvwg] NQB - a non-Default approach                        
>  
> [EXTERNAL EMAIL] 
> 
> Hi David,
>  
> This strikes me as throwing the baby out with the bathwater.  I fail to see how that major change would be helpful.  Yes, superficially I can see that it may be easier for some if the value 45 is “officially” blessed by the IETF as being a high priority DSCP.  But I don’t see how it helps matters to say that NQB traffic is intended to be given higher priority and more resources than default. From an architectural perspective, I think that’s entirely the wrong direction.  In my opinion, end-to-end QoS for user traffic has largely failed at Internet scale because of the focus on prioritization as the main (in some cases only) tool in the toolbox, and NQB would similarly be doomed to failure IMO if it were defined as a high priority service.  Furthermore, why would we need 45 if we already have CS5 and EF that request higher priority? 
>  
> Your comment that 45 “naturally” requests higher priority is not something that is supported in the Standards Track RFCs.  By my read, the Standards Track RFC 2474 (and the associated Informational 2475) never imply that 45 should be high priority, and furthermore they don’t contain the more general notion that higher DSCP means higher priority. That notion appears to come from the IP Precedence definition that was officially deprecated 20+ years ago.  In fact, RFC2474 Section 3 and 4.1 recommends that any unrecognized DSCP (e.g. 45 today) be aggregated with Default, but have its DSCP preserved, which is precisely the treatment that the NQB draft recommends for networks that don’t support the PHB. 
>  
> In any case, it seems that in the real world there are some networks that (in effect) implement IP Precedence and there are others that don’t, and we’re trying to standardize a PHB and recommend a DSCP in a pragmatic way to try to make support for NQB as easy as possible for as many applications and networks as possible.  The fact that some existing networks don’t already support the NQB PHB requirements (in one way or another) shouldn’t be cause for us to abandon the goal.  In fact, we should expect that any new DSCP definition will run into similar issues in trying to take into account and interwork as best as possible with the various existing treatments of unallocated DSCPs in place in the Internet, as well as with the DiffServ RFCs.   
>  
> The fact that 45 will end up with high priority in some networks today is a deficiency that I think we have to live with in the near term in order for NQB to be successful (this is summarized in the mailarchive link you provided below). But, our goal should be to minimize this deficiency, rather than embrace it.
>  
> In offline discussions with Ruediger, we’d come to an agreement to recommend that applications use the value 45, but include the following statements:
> “There may exist networks that internally use DSCP 45 for a local use, and thus classify traffic marked by DSCP 45 to another PHB within their domain. When receiving traffic marked by DSCP 45 at an interconnection, such a domain should be expected to re-mark this traffic. To ensure reliable end-to-end NQB PHB forwarding, a Traffic Conditioning Agreement determining a suitable DSCP at interconnection should be negotiated.”
>  
> As written, these statements do not refer to the value 5 at all. Perhaps that addresses your (and Sebastian’s) concern about IANA assigning two DSCPs for a single purpose. I also think this is consistent with the discussion in the TSVWG session regarding the “local-use” terminology.
>  
> -Greg
>  
> From: tsvwg <[e-mail]> on behalf of "Black, David" <David.Black=[e-mail]>
> Date: Tuesday, August 2, 2022 at 12:03 PM
> To: "[e-mail]" <[e-mail]>
> Subject: [tsvwg] NQB - a non-Default approach
>  
> Picking up from the draft Philadelphia meeting minutes, and Sebastian's initial comments (this is written as an individual – no hats):
>  
> > > David (no hats): As one of the authors of the Diffserv RFCs, using two codepoints annoys me.
> > > Application guidance to choose 5 or 45 based on consultation with provider is unacceptable.
> > > A single code point would work if it was not for WIFI. Would it be clearer to choose something
> > > that would work on WIFI. Could we choose 45 and only use it and work through the implications of that?
> > > Greg: NQB treated as default is still the preferred behavior. But, it is maybe OK to treat as higher priority? The point of this is not to create a priority class.
> > > David: We should take to the list. This does not work on WiFi without high priority; maybe it’s OK to be high priority?
> > > Greg: Some Wifi access points can treat 45 as best effort.
> > > Gorry (no hat): This is much better than what we have last time we discussed this. Looks promising. Have we heard from Ruediger?
> > > Greg: I can’t comment, but he’s not yet totally happy.
> > > David(No hat): Something Gorry said may give us a way out. Maybe we can recommend DSCP 45 and
> > > say that DSCP 5 could be a code point for local use. That would fit into the Diffserv architecture.
> > > Gorry: Lets continue to discuss this, and if you have interest in Diffserv use, please join this discussion.
> > > Jason Livingood commented in chat +1 on local use.
> > 
> > [SM] I fully agree that using two DSCPs with the same content appears quite wasteful*.
> > I argued for DSCP 5 for one reason only, and that is for unmodified WMM WiFi deployments
> > (aka almost all current home WiFi deployments with little chance of getting the behaviour
> > changed any time soon) DSCP 5 will not have the undesired priority side-effect of DSCP 45.
> > 
> > Because the NQB draft spends a lot of focus and attention on how to make NQB safe for the
> > network and how NQB is NOT a prioritization technique, only to not care about all of that
> > rationale for class f devices where it will has the potential for the most pronounced side-effects.
>  
> It may be time for a serious change direction.  To summarize my view of how we've gotten to this point:
> ·        NQB was originally intended to be a peer traffic treatment to Default (e.g., no priority difference).
> ·        That won't work on existing WiFi gear, e.g., see https://mailarchive.ietf.org/arch/msg/tsvwg/fBcm6eUfv9egmlo-TX8N3OAFM_A/ [mailarchive.ietf.org]
> o   TL;DR summary – must use AC_VI, which has priority over AC_BE, choose DSCP accordingly, and 45 has been chosen
> o   The need to use AC_VI will not change anytime in the foreseeable future.
> ·        That chosen DSCP (45) will be the global value for all applications/nodes to request NQB treatment from the network.
>  
> Therein lies the problem that we're doing battle with - in isolation from NQB context, DSCP 45 is much closer to CS5 (DSCP 40)
> than CS0 (DSCP 0), so DSCP 45 "naturally" requests a service with higher priority and more resources than Default (peer to EF and
> Voice-Admit) … and we've been battling to get NQB service to behave like Default except for the queuing (Sebastian's two
> paragraphs that I've quoted above are the latest installment of many).
>  
> Perhaps it's time to stop doing that …
>  
> … specifically, abandon the notion that NQB is a peer to Default and treat NQB as a higher priority service with concomitant
> forwarding resources.  If that is done, then DSCP 45 becomes the appropriate default DSCP for NQB globally, the concerns
> that motivated use of DSCP 5 on backbones (which stem from NQB being a peer to Default) largely vanish, the NQB draft
> does not need to say one word about 45 <-> 5 remarking, and DSCP 5 remains available to any network operator as a
> codepoint for local use inside that operator's network.  That feels like a good set of outcomes …
>  
> … or we can continue to try to pound the NQB-with-DSCP-45 "square peg" into the peer-to-Default "round hole" … which
> is no longer my preferred course of action.
>  
> The anvil (not straw) that broke the proverbial camel's back for me is the requirement to use DSCP 45 everywhere to
> request NQB treatment, not just on existing WiFi networks, which strongly suggests to me that the non-Default character
> of NQB will extend well beyond existing WiFi networks.
>  
> Thanks, --David (reminder: written as an individual, no hats)
>  
> David L. Black, Sr. Distinguished Engineer, Technology & Standards
> Infrastructure Solutions Group, Dell Technologies
> mobile [phone] [e-mail]