Re: [tsvwg] NQB: Use of DSCP 45

[Steven Blake <[e-mail]>]

On Fri, 2022-01-14 at 00:07 +0000, Greg White wrote:
> David,
> 
>  
> 
> I’ve been looking over RFCs 2474 & 2475 for a clear definition of
> “local use” and haven’t found one.  The mental model that I have is
> that local use in the context of Diffserv refers to PHBs or DSCPs
> that are defined by each network operator
>  for their internal usage.  

Your mental model is correct. That was the intended definition,
although nothing precluded two cooperating peering operators from using
a local use DSCP in a consistent fashion. There were two DSCP pools
defined for experimental/local use. Pool 3 which includes DSCP 45 was
moved to standards action (RFC 8436) and is no longer suitable for
local use as defined in RFC 2474.



> I didn’t find any text in those RFCs that led me to a different
> interpretation.  Further, 2474 refers to RFC 2434 when it mentions
> Local Use codepoints.  RFC 2434 also doesn’t directly have a
> definition, but it seems to equate “local
>  use” with “site specific” and with “private use”, which it defines
> as:
>  
> Private Use - For private or local use only, with the type and
>            purpose defined by the local site. No attempt is made to
>            prevent multiple sites from using the same value in
> different
>            (and incompatible) ways. There is no need for IANA to
> review
>            such assignments and assignments are not generally useful
> for
>            interoperability.
>  
>            Examples: Site-specific options in DHCP [DHCP] have
>            significance only within a single site.  "X-foo:" header
>            lines in email messages.
>  
> It doesn’t seem to me that this fits the bill.  The value 45 will be
> THE standard codepoint for any application developer and for any LAN
> equipment manufacturer, and so it should be labeled that way in the
> IANA registry. 
> 
>  
> -Greg
>  
>  
> 
> From:
> David Black <[e-mail]>
> 
> Date: Monday, January 10, 2022 at 5:31 PM
> 
> To: Greg White <[e-mail]>, "[e-mail]" <
> [e-mail]>
> 
> Cc: David Black <[e-mail]>
> 
> Subject: RE: [tsvwg] NQB: Use of DSCP 45
> 
> 
>  
> 
> Hi Greg,
>  
> > [GW]  I am not opposed to stronger language in principle, and I
> agree that your proposed approach does not depart from the intended
> usage and non-usage of 45.
> 
> > But, I had (perhaps mistakenly) understood that RFCs were only to
> provide recommendations on DSCP usage by applications and by
> networks, and they were not to
> > place requirements. So, (and my apologies if it is just me that
> didn’t fully understand) would this be starting a precedent? 
> 
>  
> It was not intended to – I left out the recommendation language
> mostly for clarity.  You're correct that RFCs provide recommendations
> for DSCP usage, as specified in the IANA Considerations
>  section of RFC 2474 (
> https://www.rfc-editor.org/rfc/rfc2474.html#section-6).
>  
> > Also, the decimal value 45 is in “Pool 3” which is designated for
> Standards Action by RFC8436.  RFC 8436 states that it “removes
> permission for experimental
> > and local use of the codepoints that form Pool 3 of the DSCP
> registry”.  So (and again I could be missing a subtlety here),
> wouldn’t it be inconsistent with RFC8436
> > to define 45 as “local use” in this draft?
>  
> Not a problem, Standards Action can assign DSCP 45 as the recommended
> default code point for NQB local use as specified in this RFC-to-be.
>  
> > This is all seems sort of tricky since (correct me if I’m wrong on
> this) the majority of the networks that you refer to (as common as
> they may be)
> > are interpreting the DiffServ field using the deprecated IP
> Precedence meaning. I’m personally not opposed to writing
> requirements for new
> > systems to ensure successful interoperation with older (or non-
> standards-compliant) networks and equipment, but it sounds like
> others might be less thrilled about that.
>  
> I'll observe that the entire discussion of DSCP 45 is about doing
> essentially that for older WiFi networks and equipment, so this
> change is in that same general area.
>  
> > As an alternative, we could write significantly stronger language
> around the recommendation to remap to DSCP 5, but leave it as a
> recommendation.
> > I’d be willing to take a stab at new text on that subject (and
> would invite help) if you think it is a workable alternative.
>  
> I think the use of the "local use" concept from RFC 2474 and 2475
> helps strongly discourage use of DSCP 45 for interconnection, but I'm
> happy to look at alternative new text.
>  
> 
> Thanks, --David
> 
>  
> 
> 
> From: Greg White <[e-mail]>
> 
> 
> Sent: Friday, January 7, 2022 6:23 PM
> 
> To: Black, David; [e-mail]
> 
> Subject: Re: [tsvwg] NQB: Use of DSCP 45
> 
> 
>  
> 
> [EXTERNAL EMAIL] 
> 
> Hi David,
>  
> Thanks for your review and summary of what you see as the remaining
> issues, and apologies for the delay in responding.
>  
> Response to item 1 below.  I’ll respond to the other items
> separately.
> 
>  
> -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.
>  
>  
> [GW]  I am not opposed to stronger language in principle, and I agree
> that your proposed approach does not depart from the intended usage
> and non-usage of 45.   But, I had (perhaps mistakenly) understood
> that RFCs
>  were only to provide recommendations on DSCP usage by applications
> and by networks, and they were not to place requirements. So, (and my
> apologies if it is just me that didn’t fully understand) would this
> be starting a precedent?  Also, the decimal value 45
>  is in “Pool 3” which is designated for Standards Action by RFC8436. 
> RFC 8436 states that it “removes permission for experimental and
> local use of the codepoints that form Pool 3 of the DSCP registry”. 
> So (and again I could be missing a subtlety here), wouldn’t
>  it be inconsistent with RFC8436 to define 45 as “local use” in this
> draft?
>  
> This is all seems sort of tricky since (correct me if I’m wrong on
> this) the majority of the networks that you refer to (as common as
> they may be) are interpreting the DiffServ field using the deprecated
> IP Precedence
>  meaning. I’m personally not opposed to writing requirements for new
> systems to ensure successful interoperation with older (or non-
> standards-compliant) networks and equipment, but it sounds like
> others might be less thrilled about that.
>  
> As an alternative, we could write significantly stronger language
> around the recommendation to remap to DSCP 5, but leave it as a
> recommendation. I’d be willing to take a stab at new text on that
> subject (and would
>  invite help) if you think it is a workable alternative.
>  
>  
>  
>  
>  
>  
>  
>  
>  
> [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?
>  
> 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.
>  
> 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.
>  
> 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.
>  
> [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.
>  
> 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.
>  
> Thanks, --David
>  
> David L. Black,
> Sr. Distinguished Engineer, Technology & Standards
> Infrastructure Solutions Group, Dell Technologies
> mobile [phone]
> [e-mail]
>  
> 
> 
> 



Regards,



  
  


// Steve