Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-08.txt

From: [email-masked]
Date: Mon, 25 Oct 2021 16:05:17 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group WG of the IETF.

        Title           : A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services
        Authors         : Greg White
                          Thomas Fossati
	Filename        : draft-ietf-tsvwg-nqb-08.txt
	Pages           : 20
	Date            : 2021-10-25

Abstract:
   This document specifies properties and characteristics of a Non-
   Queue-Building Per-Hop Behavior (NQB PHB).  The purpose of this NQB
   PHB is to provide a separate queue that enables smooth, low-data-
   rate, application-limited traffic flows, which would ordinarily share
   a queue with bursty and capacity-seeking traffic, to avoid the
   latency, latency variation and loss caused by such traffic.  This PHB
   is implemented without prioritization and without rate policing,
   making it suitable for environments where the use of either these
   features may be restricted.  The NQB PHB has been developed primarily
   for use by access network segments, where queuing delays and queuing
   loss caused by Queue-Building protocols are manifested, but its use
   is not limited to such segments.  In particular, applications to
   cable broadband links, Wi-Fi links, and mobile network radio and core
   segments are discussed.  This document recommends a specific
   Differentiated Services Code Point (DSCP) to identify Non-Queue-
   Building flows.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-08.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-nqb-08

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Greg White <[email-masked]>
Date: Mon, 25 Oct 2021 23:50:17 +0000

All,

In addition to a couple of minor wordsmithing edits, this update includes the following changes:

1. Indicates that it "Updates: rfc8325"
2. Includes a clarification that one of the SHOULD statements applies to RFC8325 equipment
3. Moves the text on safeguards for legacy WiFi up into a new subsection that is generalized to also cover unmanaged networks that happen to implement IP Precedence.

In looking back at the mailing list just now, I realized that I did not address Bob Briscoe's comment: 
https://mailarchive.ietf.org/arch/msg/tsvwg/ntGanYqcGP8GqlgzCPSQ1W6rg1U/

Apologies for that. 

His suggestion was to replace:

"If the application's traffic exceeds more than a few packets per RTT, or exceeds approximately 1 Mbps on an instantaneous (inter-packet) basis, the application SHOULD NOT mark its traffic with the NQB DSCP."

With something along the lines of:

"If the application's traffic exceeds a single digit percentage of the global average access link capacity at the time, the application SHOULD NOT mark its traffic with the NQB DSCP.  At the time of writing this document, the global average access link capacity is 63 Mbps down and 13 Mbps up for mobile networks, 113 Mbps down and 62 Mbps up for fixed networks [REF https://www.speedtest.net/global-index or some other reference]."

His rationale can be found in the mailing list posting linked above.

I'm interested in opinions on this, as well as suggestions on the wording.

-Greg

On 10/25/21, 5:09 PM, "tsvwg on behalf of [email-masked]" <[email-masked] on behalf of [email-masked]> wrote:

    Abstract:

---

From: <[email-masked]>
Date: Tue, 26 Oct 2021 07:10:24 +0000

Hi Greg,

[RG] - Bob suggests 10% of the access bandwidth as a limit, so to say. A rule of thumb says the resource demand for flows below 10% interface bandwidth can be characterized by their average bandwidth, whereas above 10%, the peak bandwidth better characterizes the flows required resources. So above this boundary burstiness of such a flow impacts other flows (and therefore peak bandwidth should be used to define the required resources).

To me the suggestion of Bob makes sense. In my recollection, I've read this rule of thumb in a publication of Gunnar Karlsson, a researcher who's been working on measurement based admission control.

Regards,

Ruediger

 ######### you wrote ###########  

Apologies for that. 

-Greg

---

From: Sebastian Moeller <[email-masked]>
Date: Tue, 26 Oct 2021 11:29:41 +0200

Hi Ruediger,

10% of which rate exactly? WiFi is variable rate and the upstream side really has no idea about the instantaneous capacity....

The NQB rate limiting really needs to be performed by nodes in control of variable rate links, which in turn means that the NQB wifi side-effect should be opt-in instead of the current opt-out approach. A point I have made pretty consistently. As long as the default NQB dscp maps to AC_VI/O NQB is unsafe for deployment, ni ifs and no buts. As long as active intervention is required to keep NQBs side effects under control there is an obvious safety failure mode right there.

Regards
        Sebastian

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Sebastian Moeller <[email-masked]>
Date: Tue, 26 Oct 2021 12:07:16 +0200

Hi Greg,

> On Oct 26, 2021, at 01:50, Greg White <[email-masked]> wrote:
> 
> All,
> 

	[SM] As far as I can see the issue is pretty much exclusively about safety of NQB marking in un-supervised "default" WiFi networks. I do not believe that any fixed fraction of "of the global average access link capacity" (FFOTGAAC) will match the realities on the ground in existing WiFi leaf networks. So my point here is not that FFOTGAAC might not still be useful to estimate some upper bound, but it really seems not solving the hard issue.... of amicable coexistence with existing WiFi networks.
	I am still convinced that the only robust solution is going to be to define a DSCP pattern that by default maps to AC_BE and make NQB aware APs implement a differential treatment for such packets, be it rate-limited mapping to AC_VI/AC_VO (by e.g. using hostapd's qos_map feature), be it by implementing a whole new AC_NQB and using that... At least in Germany the big DOCSIS-ISPs all by default distribute their own WiFi-router's to their customers, for which they control the firmware distribution, so there is a clear path forward to deploy NQB-compatible WiFi components to endpoints, so I still fail to see why we should reject the obviously safe opt-in to NQB side-effects approach and stick to the currently proposed un-safe by default design (that essentially tasks non-participating entities to make NQG safe). Yes, not having to opt-in actively will help NQB marking by endpoints, but it risks to squander the IETF's excellent technical reputation if the side-effets of that choice become noticeable.

Regards
	Sebastian

---

From: Greg White <[email-masked]>
Date: Tue, 26 Oct 2021 15:47:33 +0000

Hi Ruediger,

Thanks for this. I wasn't aware of that rule of thumb.  But, I think I would probably want to be more cautious here and have this limit apply to the instantaneous (peak) rate as opposed to the average rate.  Given that there will be many networks that have bandwidth that is less than the 'global average access link capacity', I think it is warranted.

So, maybe it's better as:

    "If the application's traffic on an instantaneous (inter-packet) basis exceeds 10% of the global average access link capacity at the time, the application SHOULD NOT mark its traffic with the NQB DSCP.  At the time of writing this document, the global average access link capacity is 63 Mbps down and 13 Mbps up for mobile networks, 113 Mbps down and 62 Mbps up for fixed networks [REF https://www.speedtest.net/global-index or some other reference]."

-Greg

On 10/26/21, 1:10 AM, "[email-masked]" <[email-masked]> wrote:

    Hi Greg,

    Regards,

    Ruediger

    Apologies for that. 

    -Greg

---

From: Sebastian Moeller <[email-masked]>
Date: Tue, 26 Oct 2021 19:53:48 +0200

Dear list,

to be explicit here the new "safety for innocent bystanders" section :

"4.3.1.  Unmanaged Networks

   In cases where a network operator is delivering traffic into an
   unmanaged network outside of their control (e.g. a residential ISP
   delivering traffic to a customer's home network), the network
   operator should presume that the existing network equipment in the
   user network supports the WiFi default DSCP mapping (see Section 8.3)
   and/or IP Precedence, and does not support the safeguards that are
   provided by the NQB PHB requirements.  As a result, the network
   operator should take precautions to prevent issues.  

[SM] This ignores the most likely scenario to beginn with an NQB-unaware leaf network that buys internet access from an NQB-unaware ISP. Show me how you can guarantee that no ISP (world-wide) will stay NQB-aware you might have an argument, but can you gurantee that and by what time?

When the data
   rate of the access network segment is less than the expected data
   rate of the user network, this is unlikely to be an issue. 

[SM] As expanded upon below, it is quite hard to estimate which rates will be achievable/expected in a leaf network's WiFi network... but I note it is such WiF networks that require the rate limiting safety mechanism most.

 However,
   if the access network rate exceeds the expected rate of the user
   network, the operator SHOULD deploy a policing function on NQB marked
   traffic that minimizes the potential for negative impacts on traffic
   marked Default, for example by limiting the rate of such traffic to a
   set fraction of the customer's service rate, with excess traffic
   either dropped or re-marked as Default.

[SM] Which again does not help much, if say my AP-station link only achieves 100Mbps, but my access link is a full gigabit... (both conditions are IMHO not unrealistic).

   As an additional safeguard, and to prevent the inadvertent
   introduction of problematic traffic into unmanaged user networks,
   network equipment that is intended to deliver traffic into unmanaged
   user networks (e.g. an access network gateway for a residential ISP)
   MUST by default ensure that NQB traffic is marked with a DSCP that
   selects the WiFi "Best Effort" Access Category and the "Routine" IP
   Precedence level (i.e.  DSCP 0-7).  Such equipment MUST support the
   ability to configure the remapping, so that (when appropriate
   safeguards are in place) traffic can be delivered as NQB-marked."

[SM] Sweet, except for the inconvenient fact that almost 100% of deployed network equipment does not do this, and the likelihood of gear being exchanged just to enable NQB seems pretty slim*. I have no objections to hoping for such a replacement strategy, but consider it to be overly optimistic to call something as unlikely to happen a "safeguard"....

In short all is moot, because it requires 
A) existence of a benevolent NQB-aware operator to gate all access to end user networks

B) knowledge by the operator about the available bandwidth/rate/capacity in the leaf network.

which both are not realistic assumptions, sorry.

B) is especially relevant, because the expected negative side-effects only materialize on WiFi links, but WiFi is a variable rate link technology to beginn with and achievable rates depends on variables like distance between station and AP, RF noise in the selected channel, ... In short there is no way an operator can set an NQB rate that is guaranteed not to cause the unwanted side effects.

As I stated in the past there is a simple solution to this conundrum, select a DSCP for NQB that by default maps to AC_BE so legacy NQB-unaware leaf networks will continue to work as well or as badly as today, while new gear ca opt-in to NQB's promises and gain its advantages.

Insisting on using an DSCP that maps by default to AC_VI or AC_VO invalidates all apparent "safety" considerations in the draft as "safety theater"; there is a clear path forward that is safe by design, I fail to see why this draft still insists on proposing a path forward which clearly treats safety as a matter of wording in the RFC text and not in the engineering behind it.

Regards
	Sebastian

*) As an example when ISPs in Germany introduced Vectoring on their VDSL2 links they did not go and replaced legacy ADSL gear with vectoring-capable or vectoring-friendly devices, but they simply exempted the 2.2 MHz of spectrum used by ADSL from vectoring (in spite of vectoring actually could/should have been an improvement for the ADSL links); I expect the same approach for something much more obscure like NQB.

P.S.: I have made similar arguments in the past, but as long as new revisions have the same obvious deficit I am going to object to them.

> On Oct 26, 2021, at 01:05, [email-masked] wrote:
> 
>

---

From: Sebastian Moeller <[email-masked]>
Date: Tue, 26 Oct 2021 22:20:00 +0200

Dear list,

https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-08#section-8.3.1:
"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."

Does claim "statistical prioritization", but the default values for EDCA channel access functions (eg https://www.ieee802.org/1/files/public/docs2008/avb-gs-802-11-qos-tutorial-1108.pdf slide 8) are selected
so that AC_VI will be guaranteed earlier airtime access than AC=BE and AC_BK, and AC_VO earlier than AC_VI, as long as no traffic from other stations is involved this will result in more or less strict prioritization where higher ACs can effectively starve other traffic. So I do not think calling this "statistical prioritization" is a useful description here (since it seems to imply some level of slack between the priority levels which only seems applicable for AC_BE and AC_BK).

Regards
	Sebastian

---

From: Greg White <[email-masked]>
Date: Wed, 27 Oct 2021 21:00:36 +0000

Sorry Sebastian, but that is not how Wi-Fi EDCA works, so I don't think you can manufacture a controversy on this one.

If two stations begin EDCA at the same time, one with a frame to send on AC_BE and the other on AC_VI (and no other stations contending), with the default parameters:

AC_VI
- CWmin = 7
- CWmax = 15
- AIFSN = 2

AC_BE
- CWmin = 15
- CWmax = 1023
- AIFSN = 3

The AC_BE station will transmit first 18% of the time.  This is not strict priority or starvation.  It is statistical priority.
 
Even within a single station, if it simultaneously has a frame to send on AC_BE and another on AC_VI, it will transmit the AC_BE frame first 16% of the time.  Also not strict priority.

These numbers I calculated with a little knowledge and a simple spreadsheet.  You could probably do the same.

There are all sorts of explanations on the web as to how EDCA works.  In case you can't locate one readily, this one is concise and looks fairly good:
https://www.ideals.illinois.edu/bitstream/handle/2142/11220/A%20Comprehensive%20Study%20of%20the%20Enhanced%20Distributed%20Control%20Access%20(EDCA)%20Function.pdf?sequence=2

-Greg

On 10/26/21, 2:20 PM, "tsvwg on behalf of Sebastian Moeller" <[email-masked] on behalf of [email-masked]> wrote:

    Dear list,

    Regards
    	Sebastian

---

From: Sebastian Moeller <[email-masked]>
Date: Thu, 28 Oct 2021 13:19:56 +0200

Hi Greg,

> On Oct 27, 2021, at 23:00, Greg White <[email-masked]> wrote:
> 

	[SM] I do not claim to be the resident WiFI expert, but I am similarly unconvinced that you are. So how about we try to untangle/clarify this, without resorting to unhelpful claims like "manufacture a controversy", okay?

> If two stations begin EDCA at the same time, one with a frame to send on AC_BE and the other on AC_VI (and no other stations contending), with the default parameters:

	[SM] A station/AP will begin transmission at ~ AIFSN + randint(CWmin, CWmax), but 
2 + 15 = 17

while 
3  +15 = 18

so AC_BE should wait at least for 18 units, while AC_VI will wait at most for 17 units...
Now, I accept that I had not considered that a station that did not acquire the TX op will not reset its back-off timer once the competing transmit has finished, but will continue from the last state.

> The AC_BE station will transmit first 18% of the time.  This is not strict priority or starvation.  It is statistical priority.

But looking at Figure 8 b and c of your cited paper clearly shows that AC_BE will get severely pummeled, even if not fully starved. As I said "where higher ACs can effectively starve other traffic" (and both AC_VO and AC_VI apparently manage to starve AC_BE and AC_BK, while keeping some level of sharing between themselves). I accept that my proposal to talk of strict priority is technically wrong and retract it, but I maintain that the statistical in "statistical prioritization" is not a helpful qualification. But I understand you disagree.

	See Figure 8 b)c), do you still claim that this is not "starvation"? So, what constitutes starvation according to your definition then?

> Even within a single station, if it simultaneously has a frame to send on AC_BE and another on AC_VI, it will transmit the AC_BE frame first 16% of the time.  Also not strict priority.

	[SM] How does that rhyme with the relative throughput graphs in the cited figure? AC_BK does not get 18 or 16% of the throughput.... what I see in the plots I would still describe as "more or less strict prioritization where higher ACs can effectively starve other traffic". Note the qualifiers "more or less" and "effectively"?

> These numbers I calculated with a little knowledge and a simple spreadsheet.  You could probably do the same.

	[SM] Well, I actually planned to run an experiment instead, because a spreadsheet exercise will just be as good as the "model" of the process you incude in the calculation, while a real experiment will also cover all the parts not included in a simplistic model. But it turned out your reference (thanks) contains data covering exactly that point that, sorry to keep insisting, seem pretty compatible with "more or less strict prioritization where higher ACs can effectively starve other traffic".

> https://www.ideals.illinois.edu/bitstream/handle/2142/11220/A%20Comprehensive%20Study%20of%20the%20Enhanced%20Distributed%20Control%20Access%20(EDCA)%20Function.pdf?sequence=2

	[SM] I am at a loss here. Thank you for posting that reference, but did you actually look inside to confirm that it actually contradicts my statement/position before posting?

Sebastian

P.S.: My intuition about AC-dependent starvation in WiFI WMM comes from running actual experiments and seeing starvation in action, including effects where a single station effectively also managed to starve the AP, even though both entities used 2 flows in each AC, so this is not only a theoretical issue, but also one about quality of implementation.

P.P.S.: Since the safety mechanisms for non NQB-aware WiFi networks seem neither robust nor reliably, I would prefer these section could be ripped out and replaced by a simple description of how NQB can cause fairness issues in non NQB-aware WiFi networks. Maybe followed by a section describing how thhis potential unfairness is counter-balanced/justified by improving the (theoretical) deployability of NQB in the field. Because IMHO that is the relevant trade-off, and you clearly opt for accepting that risk (to third parties) by of not proposing NQB code-point that by default is WMM-safe. As it stands we have these incomplete/impossible safeguards, where an entity that does not know it needs to act, is supposed to rate-limit some traffic for an unknown and unknowable rate target. Where the rate-limiting proposal immediately drags in questions to what degree an ISP can, without first asking for consent, start limiting end-user traffic based on DSCPs.

---

From: "Jerome Henry (jerhenry)" <[email-masked]>
Date: Thu, 28 Oct 2021 15:07:32 +0000

Dear all,

Maybe some additional input would be useful. This doc (https://ieee802.org/1/files/public/docs2008/avb-gs-802-11-qos-tutorial-1108.pdf) may help too, as it turns out that, since 802.11e was introduced 17 years ago, some people indeed thought of checking if one queue would starve the other (spoiler alert: my web browsing is still fine, even when other applications perform real-time cat video exchanges on the same or other clients).
The table in here (https://www.rfwireless-world.com/Terminology/WiFi-QoS.html) also provides the various values for the various queues.

The CWMin and CWMax values are ranges. And indeed 15+2 < 15+3. But the AP also sends for each traffic TXOP limits, that determine the max transmission time for each queue. This prevents my AC_VI transmission from taking all the air. And indeed if a payload in AC_VI gets 17 slots, a payload in AC_BE gets (say) 28 slots, AC_VI will start sending when AC_BE is still at 11. TXOP limit will prevent AC_VI from eating all the time, then the next AC_VI packet will need to pick a number. It may pick as small as (7+2) or as large as (15+2), so it may go down the queue and send before our AC_BE friend gets to 0, or it may be stop on the way down by AC_BE transmission coming first.
The first packet indeed has a reliable chance of getting an ordered transmission, but Wi-Fi networks are typically a bunch of packets, this is why we all speak of statistical advantage (the term does not shock me, I have heard it and used it for 17 years).

Hope this helps

Jerome 

On 10/28/21, 7:20 AM, "tsvwg on behalf of Sebastian Moeller" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Greg,

    while 
    3  +15 = 18

    Sebastian

---

From: Greg White <[email-masked]>
Date: Thu, 28 Oct 2021 22:09:19 +0000

[GW] see below.

On 10/28/21, 5:20 AM, "Sebastian Moeller" <[email-masked]> wrote:

    Hi Greg,

    while 
    3  +15 = 18

[GW] I sent a link to a paper that has a concise description of EDCA.  Apparently you decided not to read that description. On page 3 you will find:  "Similarly to DCF, CW determines the number of backoff slots (which is uniformly distributed in [0, CW-1]) a station has to count down before a transmission is made."  They both start at CWmin, so the AC_BE station will uniformly select an initial backoff value between 0 - 15, and add 3 slots for AIFSN, whereas the AC_VI station will uniformly select an initial backoff value between 0 - 7 and add 2 slots for AIFSN.  So, in our case of two stations starting EDCA at the same time, after the SIFS interval, the AC_BE station will wait some value 3 - 18 slots, and the AC_VI station will wait some value 2 - 9 slots. These ranges overlap. There is a 16% chance that the BE station will get a better dice roll than the VI station, and a 5% chance that they roll the same value and collide.  If they collide, they will both double their CW and try again (so 3 - 34 for BE and 2 - 17 for VI), if you work it all out, the BE station has an 18% chance of transmitting first. In the single station case, there is no collision and ties go to VI, so BE wins 16%.  In the experiments that I've done with multiple Wi-Fi devices using different chipsets, the default params result in VI getting ~78% of the capacity and BE getting ~22%.  Note that "chance of transmitting first" and "capacity" are two different things, but this seems consistent.

    [SM] Now, I accept that I had not considered that a station that did not acquire the TX op will not reset its back-off timer once the competing transmit has finished, but will continue from the last state.

[GW] Thanks for retracting your incorrect comment, and I do think that "statistical prioritization" is an accurate term to reflect the above.  The process involves each station independently generating a random number, and statistically one AC will get preferential access to the channel over the other.

[GW] None of those graphs exactly represent the case we are discussing, but, if you examine the EDCA parameters they used, 8a is the closest. In that case it looks to me like Class 1 gets about 75% of the total capacity and Class 2 gets about 25%. That's not strict priority (even "more or less").

[GW] I actually referenced that paper for its concise description of the EDCA algorithm. But, in examining the graphs, they also (as expected) refute your statement. Your position was that EDCA with default parameters was more or less strict priority and that the draft was incorrect to use the term "statistical prioritization" to describe it. If those graphs showed that "Class 1" gets 100% of the total throughput, and all of the other classes get 0, then that would be strict priority.  

    Sebastian

---

From: Sebastian Moeller <[email-masked]>
Date: Fri, 29 Oct 2021 15:50:37 +0200

> On Oct 29, 2021, at 00:09, Greg White <[email-masked]> wrote:
> 
> [GW] see below.
> 
> [GW] I sent a link to a paper that has a concise description of EDCA.  Apparently you decided not to read that description. On page 3 you will find: "Similarly to DCF, CW determines the number of backoff slots (which is uniformly distributed in [0, CW-1]) a station has to count down before a transmission is made."  They both start at CWmin, so the AC_BE station will uniformly select an initial backoff value between 0 - 15, and add 3 slots for AIFSN, whereas the AC_VI station will uniformly select an initial backoff value between 0 - 7 and add 2 slots for AIFSN.  So, in our case of two stations starting EDCA at the same time, after the SIFS interval, the AC_BE station will wait some value 3 - 18 slots, and the AC_VI station will wait some value 2 - 9 slots.

	[SM] Thanks for spelling this out, I had misread/misinterpreted the selection process as picking a zero-based index and using that to select from the range between CWmin and CWmax, again thanks for persistently explaining this.

> These ranges overlap. There is a 16% chance that the BE station will get a better dice roll than the VI station, and a 5% chance that they roll the same value and collide.  If they collide, they will both double their CW and try again (so 3 - 34 for BE and 2 - 17 for VI), if you work it all out, the BE station has an 18% chance of transmitting first. In the single station case, there is no collision and ties go to VI, so BE wins 16%.  In the experiments that I've done with multiple Wi-Fi devices using different chipsets, the default params result in VI getting ~78% of the capacity and BE getting ~22%.

	[SM] When I try to run the numbers (for the default EDCA numbers), I get to 20.178% for BE versus VI for transmitting first (accumulating over 6 collision cycles):
Percent BE first: 20.507812500000
Percent BE first: 21.173000335693
Percent BE first: 21.178034716286
Percent BE first: 21.178053767287
Percent BE first: 21.178053803333
Percent BE first: 21.178053803367
Percent BE first: 21.178053803367

(Collisions after collisions get unlikely quite quickly)

This is from brute-forcing all backoff window combinations for two flows (with adjusted collision probabilities per iteration) which seems to be the right approach... close enough to your 22%. 

>  Note that "chance of transmitting first" and "capacity" are two different things, but this seems consistent.

	[SM] Yes, I agree now with your ~20% number, and I also agree that it is decidedly different from capacity. I just happen to be more interested in the effect of rate/throughput (and I bet tat most users are also less concerned about "chance of transmitting first" in the quite network condition than then how is capacity shared in a busy network case).

> [GW] Thanks for retracting your incorrect comment, and I do think that "statistical prioritization" is an accurate term to reflect the above.  The process involves each station independently genera…

	[SM] You realize that by that logic even the strictest of strict prioritization is just a special case of "statistical prioritization" with a probability of preferential access of 1.0... my point was the "statistical" does not really add to the draft.

> [GW] None of those graphs exactly represent the case we are discussing,

	[SM] Why, if you look at the EDCA parameters in the figure legend you will see that AC1 is AC_VO, AC2 is AC_VI, AC3 is AC_BE and AC4 is AC_BK. IMHO the relevant case for NQB is exactly competition between AC_VI/VO and AC_BE.

> but, if you examine the EDCA parameters they used, 8a is the closest.

	[SM] Closest to what? Our above example was BE (so AC3) versus VI (so AC2), but 8a) compares AC_VO (AC1) with AC_VI (AC2).

> In that case it looks to me like Class 1 gets about 75% of the total capacity and Class 2 gets about 25%. That's not strict priority (even "more or less").

	[SM] Sure, but that is not the situation of WMM that is relevant for NQB, is it? And hence basing the description of WiFi priority on that case seems unhelpful in the NQB draft (which explicitly addresses the AC_VI versus AC_BE case). Because in the relevant case AC_VI versus AC_BE VI essentially starves BE "more or less". And that is not my subjective opinion only, but cofirmed by the paper you cited, as well as a number of others like 	• Engelstad, Paal E., and Olav N. Osterbo. "Delay and throughput analysis of IEEE 802.11 e EDCA with starvation prediction." Local Computer Networks, 2005. 30th Anniversary. The IEEE Conference on. IEEE, 2005.

Your text: "that result in statistical prioritization of the "Video" Access Category above the "Best Effort" Access Category." sounds much less severe than what users are going to experience, effective starvation of flows in AC_BE if NQB traffic rate equals the WiFi link rate*. Where in the draft is that potential side-effect of NQB explicitly addressed?

*) Which is variable and hence can not be easily worked-around by rate-limiting NQB traffic upstream (let alone the question whether an ISP actually should rate limit end-user traffic unless explicitly tasked by the end-user to do so)...

> [GW] I actually referenced that paper for its concise description of the EDCA algorithm. But, in examining the graphs, they also (as expected) refute your statement.

	[SM] Except ony partially, because they do show that AC_VO & AC_VO (at least together) effectively starve AC_BE (& AC_BK) to cite from the paper:
"All the observations made in the studies of varying either the contention window size or the AIFS value are observed (although in a mixed manner). In particular, in the presence of stations with the smallest AIFS (AIFSN=2), stations of all the other classes (AC3 and AC4) attain very little (close to zero) throughput."

> Your position was that EDCA with default parameters was more or less strict priority and that the draft was incorrect to use the term "statistical prioritization" to describe it. 

	[SM] Almost, "unhelpful" was my qualification not "incorrect".

> If those graphs showed that "Class 1" gets 100% of the total throughput, and all of the other classes get 0, then that would be strict priority.  

	[SM] True, but also not terribly relevant for NQB, unless we expect all traffic currently using AC_BE to up-prioritize to AC_VI or even AV_VO... But I get it, I was obviously being incorrect and hence get the deserved criticism, conveniently also allowing to ignore the gist of my argument.