Subject: Re: [tsvwg] NQB: Use of DSCP 45

From: Greg White <[email-masked]>
Date: Fri, 7 Jan 2022 23:22:40 +0000

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 <[email-masked]> on behalf of David Black <[email-masked]>
Date: Tuesday, January 4, 2022 at 9:15 AM
To: "[email-masked]" <[email-masked]>
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 +1 978-394-7754 [email-masked]<mailto:[email-masked]>

---

From: "Black, David" <[email-masked]>
Date: Tue, 11 Jan 2022 00:31:13 +0000

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 <[email-masked]>
Sent: Friday, January 7, 2022 6:23 PM
To: Black, David; [email-masked]
Subject: Re: [tsvwg] NQB: Use of DSCP 45

[EXTERNAL EMAIL]
Hi David,

-Greg

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

Thanks, --David

---

From: Greg White <[email-masked]>
Date: Fri, 14 Jan 2022 00:07:44 +0000

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.  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 <[email-masked]>
Date: Monday, January 10, 2022 at 5:31 PM
To: Greg White <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: David Black <[email-masked]>
Subject: RE: [tsvwg] NQB: Use of DSCP 45

Hi Greg,

Thanks, --David

[EXTERNAL EMAIL]
Hi David,

-Greg

Thanks, --David

---

From: Steven Blake <[email-masked]>
Date: Fri, 14 Jan 2022 02:09:18 -0500

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:
>  
> 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:
> > [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
> 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
> 
>  
> 
> 
> Thanks for your review and summary of what you see as the remaining
> issues, and apologies for the delay in responding.
>  
> From:
> tsvwg <[email-masked]> on behalf of David Black <
> [email-masked]>
> 
> 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.
>  
> 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.
>  
>  
>  
>  
>  
>  
>  
>  
>  
> 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?
>  
> 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.
>  
> 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
> mobile +1 978-394-7754
> [email-masked]

Regards,

// Steve