Subject: [tsvwg] NQB: Use of DSCP 45

From: "Black, David" <[email-masked]>
Date: Tue, 4 Jan 2022 16:14:40 +0000

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.
     *   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?

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: <[email-masked]>
Date: Wed, 5 Jan 2022 07:29:46 +0000

Hi David,

I agree to your proposal related to point [1].

Points [2] and [3]: I think to recall that there has been a discussion whether upcoming IETF transport standards should be built around out-of-date and never-to-be-updated WiFi HW related to some other issue in the past. I fail to recollect, whether and what consensus was reached.

Regards,

Ruediger

Von: tsvwg <[email-masked]> Im Auftrag von Black, David
Gesendet: Dienstag, 4. Januar 2022 17:15
An: [email-masked]
Betreff: [tsvwg] NQB: Use of DSCP 45

Thanks, --David

---

From: Sebastian Moeller <[email-masked]>
Date: Wed, 5 Jan 2022 09:38:32 +0100

Hi Ruediger, list

> On Jan 5, 2022, at 08:29, <[email-masked]> <[email-masked]> wrote:
> 
> Hi David,
>  

	[SM] Just to understand your point, do you consider the selection of DSCP decimal 45 (selected to exploit the default WMM DSCP to AC mapping) as building NQB around "out-of-date and never-to-be-updated WiFi HW" or as a clean way forward that would be selected in a non-legacy world as well?

Side-note: I believe that the WiFI fq_codel/airtime fairness patches in OpenWrt's Ath9K, Ath10k, ans mt76 drivers actually demonstrate how to properly implement something like the desired NQB behavior on existing devices. Equitable scheduling (ES) seems to fulfill NQB's desired network treatment much better than any flavor of prioritization, and in a way that is based on observed behavior instead of arbitrary classifiers that can and will be gamed.

Regards
	Sebastian

> 	• 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.
> 		• 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.
>  
> mobile +1 978-394-7754 [email-masked]

---

From: <[email-masked]>
Date: Wed, 5 Jan 2022 09:16:54 +0000

Hi Sebastian,

I don't favour new standards making design choices _mainly_ to deal with out-of-date gear. Out-of-gate to me is something, which no longer dominates by the time of standardisation and is definitely slowly diminishing, but may be present with ever shrinking numbers for years to come. I don't say, ignore such gear, but I also don't want to make such gear main focus for design choices of a new standard.

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: Sebastian Moeller <[email-masked]> 
Gesendet: Mittwoch, 5. Januar 2022 09:39
An: Geib, Rüdiger <[email-masked]>
Cc: Black, David <[email-masked]>; [email-masked]
Betreff: Re: [tsvwg] NQB: Use of DSCP 45

Hi Ruediger, list

Regards
	Sebastian

> Infrastructure Solutions Group, Dell Technologies mobile +1 
> 978-394-7754 [email-masked]

---

From: Sebastian Moeller <[email-masked]>
Date: Wed, 5 Jan 2022 10:25:26 +0100

Dear Ruediger,

> On Jan 5, 2022, at 10:16, <[email-masked]> <[email-masked]> wrote:
> 
> Hi Sebastian,
> 

	[SM] Thanks for elaborating on your general position. 
	But what does that mean in the context of the NQB draft; do you oppose the use of DSCP 45 locally as that is explicitly tailored to old equipment behaviour (although WMM and the described default mappings still seem to be the default even for new WiFi gear). Or do you agree to using DSCP 45 as new equipment could implement an NQB compliant treatment of that DSCP (which it arguably also could for DSCP 5)? 
	I do not want to argue with you here or convince you one way or the other, I am really just trying to understand clearly what your position on that aspect of the NQB draft is.

Regards
	Sebastian

---

From: <[email-masked]>
Date: Wed, 5 Jan 2022 09:55:04 +0000

Hi Sebastian,

That's the same for legacy ECN as for legacy WiFi: I offer a general philosophy. But I'm not expert in these areas, my expertise is with backbone gear. As I'm sometimes unhappy to discuss with people who are having views but aren't experts on the focus of my work, I try to be careful in areas, where I am aware that I don't have the full picture. I rely on experts on the subject to propose suitable choices.

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: Sebastian Moeller <[email-masked]> 
Gesendet: Mittwoch, 5. Januar 2022 10:25
An: Geib, Rüdiger <[email-masked]>
Cc: [email-masked]
Betreff: Re: [tsvwg] NQB: Use of DSCP 45

Dear Ruediger,

Regards
	Sebastian

---

From: Sebastian Moeller <[email-masked]>
Date: Thu, 6 Jan 2022 09:57:52 +0100

Dear Ruediger,

I contemplated whether to respond at all (and some will argue I should have), but more below prefixed [SM]...

> On Jan 5, 2022, at 10:55, <[email-masked]> <[email-masked]> wrote:
> 
> Hi Sebastian,
> 
> That's the same for legacy ECN as for legacy WiFi: I offer a general philosophy.

	[SM] This is appreciated, but should such a philosophy not also end up with actionable inputs to the standardization process? As it stands your comment(s) upon David's points 2) and 3) are quite mercurial since you did not even seem to commit in what way your question would affect the NQB draft's way forward.

> But I'm not expert in these areas, my expertise is with backbone gear. As I'm sometimes unhappy to discuss with people who are having views but aren't experts

	[SM] I take that as (partly) justified complaint about my relative frequent posts about issues where I am clearly not an expert. I consider myself open to be convinced otherwise should my views conflict with reality, but I expect honest arguments, preferably data driven and not purely theoretical considerations.

> on the focus of my work, I try to be careful in areas, where I am aware that I don't have the full picture.

	[SM] My take on this is that if experts exist in this mailing list and I write gibberish, they will set me straight and with the relevant facts and arguments; which rarely happens here, unfortunately. And honestly, this seems not the optimal list to expect much WiFi expertise to begin with. 
	Side-note: I am clearly no expert in encrypted protocols either and yet I brought the point to the lists attention that L4S' cavalier approach to re-ordering might interfere with common IPsec implementations and RFCs, so even non-expert input can have merit and be actionable. I also have discussed the idea to split the NQB into two DSCPs one safe and one potentially with side-effects, though I do not remember who introduced that idea to the list, and I also brought up the fact that DSCPs with the top three bits set to zero are more likely to pass over the internet intact (again I do not claim I originated that idea in the first place).

> I rely on experts on the subject to propose suitable choices.

	[SM] Yes I would agree, I am all for respecting expertise. But I expect those experts to be able to explain and justify their decisions. Since we are not taking the absence of expert input as cause to drop a draft, I guess the list will need to live with my non-expert input (or ban me).

Regards
	Sebastian

---

From: "Black, David" <[email-masked]>
Date: Thu, 6 Jan 2022 14:21:03 +0000

Sebastian,

> [SM] This is appreciated, but should such a philosophy not also end up with actionable inputs to the standardization process?
> As it stands your comment(s) upon David's points 2) and 3) are quite mercurial since you did not even seem to commit in what way your question would affect the NQB draft's way forward.

Could you tone it down a bit, please?  Admitting lack of knowledge is a good thing, if for no other reason than I started off on points 2) and 3) in exactly that fashion ;-).

If we (WG as a whole) can't figure out how to make DSCP 45 work for NQB (even as a "local use" DSCP), it may need to be removed from the draft.  I'm not ready to jump to that conclusion until there's an opportunity for others to chime in, although I do agree with you that recommending EDCA parameter adjustment is not realistic (particularly for equipment that's not managed by the ISP).

Thanks, --David

-----Original Message-----
From: tsvwg <[email-masked]> On Behalf Of Sebastian Moeller
Sent: Thursday, January 6, 2022 3:58 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [tsvwg] NQB: Use of DSCP 45

[EXTERNAL EMAIL] 

Dear Ruediger,

Regards
	Sebastian

---

From: "Jerome Henry (jerhenry)" <[email-masked]>
Date: Thu, 6 Jan 2022 22:13:54 +0000

As this thread suggest that Wi-Fi people are not weighing in, well, weighing in...

I also agree that the sentence "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" is not realistic. It is also a bad idea, unless qualified further. Its effect would be to destroy the Video queue, putting all video (that is multimedia conferencing, real-time interactive, multimedia streaming, broadcast video, but also signaling, and NQB, if I understand correctly) into a sort of double-stack BE queue. From an implementation standpoint, I do not know how an existing system (if it were to be configurable for this) would be able to address conflicts between 2 queues (getting down to 0 at the same point in time for example) that have the same parameters (thus no hierarchy). From a prioritization standpoint, many things have been said about Wi-Fi being too complex to really be modelable, but most of the works we Wi-Fi folks tend to accept as valid lean to show that if one queue has a better statistical priority and a more generous TXOP, it will globally provide better / smoother traffic flows. Degrading video performance for the sake of one traffic (that is not even building queue) does not sound like an idea any WiFi guy would accept any time soon, until the volume of paper modeling the behaviors show that it is innocuous, and that all these papers published over a decade and a half that show differentiation (basic multi-scenarios experiments like this guy and many others for example https://arxiv.org/pdf/1910.07743.pdf, or queue modeling studies like this https://ieeexplore.ieee.org/document/6822614 with legacy traffic or this https://ieeexplore.ieee.org/document/8891575 with the effect of the new MU methods on the performances, etc.)

I understand that we should not build future protocols based on the past, but it may take more than a line in a document to change 18 years of practice and shared views on a topic like this one....

My 2 cents

Jerome 

On 1/6/22, 3:58 AM, "tsvwg on behalf of Sebastian Moeller" <[email-masked] on behalf of [email-masked]> wrote:

    Dear Ruediger,

    Regards
    	Sebastian

---

From: Sebastian Moeller <[email-masked]>
Date: Fri, 7 Jan 2022 10:16:18 +0100

Hi Jerome,

thanks for your insight an expertise. Sorry for having been rude and impolite (I clearly still do not understand how the WG/IETF operates and misread apparent silence for full agreement with a draft).

Regards
	Sebastian

> On Jan 6, 2022, at 23:13, Jerome Henry (jerhenry) <[email-masked]> wrote:
>

---

From: "Jerome Henry (jerhenry)" <[email-masked]>
Date: Fri, 7 Jan 2022 13:48:39 +0000

Thank you Sebastian, 
And no offense taken! You are perfectly right, I had reached out to the authors directly, but should have reflected our exchange on the list. Commenting once on the list and not anymore there was not the best way to keep the dialog going on this  particular point. Your comment was a useful reminder.

Take care

Jerome 

On 1/7/22, 4:16 AM, "Sebastian Moeller" <[email-masked]> wrote:

    Hi Jerome,

    Regards
    	Sebastian

    > As this thread suggests that Wi-Fi people are not weighing in, well, weighing in...
    >

---

From: Greg White <[email-masked]>
Date: Wed, 12 Jan 2022 01:05:11 +0000

Hi Jerome,

On your implementation question, the 802.11 spec is clear on this.  Section 10.23.2.4 in 802.11-2020 describes the situation. The tie always goes to the higher UP, regardless of EDCA parameters, so there is still a very slight difference in priority in favor of AC_VI, but they are for all intents the same priority.   A couple of years ago, I built a MATLAB model of the EDCA algorithm to predict the behavior, and then conducted experiments with a handful of retail .11ac wave2 APs doing just this, and it had the expected result (aside from 2 APs that were not spec compliant, one of which had a priority inversion to begin with (AC_BE got higher priority than AC_VI) and would not accept the settings and always reverted back to defaults, the other of which gave significantly higher priority to AC_VI than would be predicted by the EDCA parameters, and adjusting the params to match BE didn't make them equal, though it did make them closer). So I don't believe there is any general implementation issue here.

The concern about giving up a high priority queue in order to reconfigure it to be equal priority to BE is a valid one (although your language, "destroy the Video queue" is a real exaggeration in my opinion).  This approach supposes that the network operator considers the latency benefit provided by NQB to be of greater value than providing high priority to all of the traffic marked with a DSCP 32 - 47 (including CS4, AF41, AF42, AF43, CS5, NQB, VA & EF).  In my mind, it is debatable that all would agree that applications that mark their traffic with those codepoints should under all circumstances be given more bandwidth than those that use DSCPs 0-7 & 24-31, particularly in the residential environment where there is no real management of DSCP usage.  But, this is a decision to be made by the network operator.  Furthermore, if the value of the Video queue in traditionally configured networks is that it provides lower latency (perhaps for CS5 or EF traffic), I would argue that this reconfiguration of EDCA params might be pretty innocuous except in networks with a very large number of active STAs (and has the upside of preventing mismarked traffic from consuming the majority of the airtime).  We've not tried to test that extensively, but we've observed that with a fairly small number of active stations, it is the buffering delay in AC_BE that causes more of a latency problem than the media access, so it is the separate queue for AC_VI that provides the most benefit rather than the default EDCA params.

-Greg

On 1/6/22, 3:14 PM, "tsvwg on behalf of Jerome Henry (jerhenry)" <[email-masked] on behalf of jerhenry=[email-masked]> wrote:

    My 2 cents

    Jerome 

        Dear Ruediger,

        Regards
        	Sebastian

---

From: "Jerome Henry (jerhenry)" <[email-masked]>
Date: Fri, 14 Jan 2022 20:04:05 +0000

Thank you Greg,

Apologies if my term 'destroy the video queue' came out as offensive, I meant 'destroy' not as 'OMG, it is the end of the world for video' but as 'effectively, the video queue does not exist anymore independently, as it has now the same specs as the BE queue'. I ran an experiment in my lab (disclaimer, only one brand, 6 alike APs) and I find slightly different results than yours (when I configure the AIFSN/etc. on the AC_VI to be the same as AC_BE, I cannot find statistical differences between both ACs, it may be chipset-dependent... 

Take care

Jerome 

On 1/11/22, 8:05 PM, "Greg White" <[email-masked]> wrote:

    Hi Jerome,

    -Greg

        My 2 cents

        Jerome 

            Dear Ruediger,

            Regards
            	Sebastian