Subject: [tsvwg] draft-ietf-tsvwg-nqb, more questions

From: Sebastian Moeller <[email-masked]>
Date: Mon, 4 Nov 2019 23:11:58 +0100

Regarding https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/?include_text=1

7.3.  WiFi Networks

   WiFi networking equipment compliant with 802.11e generally supports
   either four or eight transmit queues and four sets of associated EDCA
   parameters (corresponding to the four WiFi Multimedia Access
   Categories) that are used to enable differentiated media access
   characteristics.  Implementations typically utilize the IP DSCP field
   to select a transmit queue, but should be considered as Non-
   Differentiated Services-Compliant Nodes as described in Section 4 of
   [RFC2475].  As a result this document discusses interoperability with
   WiFi networks, as opposed to PHB compliance.

   As discussed in [RFC8325], most existing implementations use a
   default DSCP to User Priority mapping that utilizes the most
   significant three bits of the DiffServ Field to select "User
   Priority" which is then mapped to the four WMM Access Categories.  In
   order to increase the likelihood that NQB traffic is provided a
   separate queue from QB traffic in existing WiFi equipment, the 0x2A
   codepoint is preferred for NQB.  This would map NQB to UP_5 which is
   in the "Video" Access Category.

   Systems that utilize [RFC8325], SHOULD map the NQB codepoint to UP_5
   in the "Video" Access Category.

   In order to preserve the incentives principle, WiFi systems SHOULD
   configure the EDCA parameters for the Video Access Category to match
   those of the Best Effort Access Category.

[SM] This last section is puzzling: if the wifi system configures AC_VI with EDCA parameters that match the AC_BE parameters, AC_VI ceases to be different from AC_BE, in that case picking a codepoint that automatically maps to CS0 and hence to AC_BE  seems much safer, simpler and straight forward to me. 
Especially since essentially none of the millions deployed WiFi APs out there will a) have this configured like proposed already and b) none of the consumer APs I know actually allow to easily adjust EDCA parameters at all. I guess I must be missing something and would be delighted to be shown why the proposed text is the right thing.
My take on this still is, if NQB traffic is sufficiently sparse using AC_VI can be justified, but without any rate limits this has the potential of being quite unfair to concurrent APs on the same channel (as well as the neighboring channels that overlap with the selected). 
I do not want to sound alarmist, but given the number of cable-ISP WiFi-APs (as indicated by a SSID containing the ISPs name) in my city, I believe making sure that those APs will not basically start hogging most airtime seems the prudent thing to do. If there are sufficient backstops in place (like rate limiting or automatic down-marking if the traffic is not sparse enough) to avoid the described situation, I am all for it.

The text probably should also openly discuss that in WiFi/WMM the four available queues by design have different priorities, and by moving NQB out of the default AC_BE while leaving QB flows in there, this effectively runs against  the following text in the draft: "The NQB queue SHOULD be given equal priority compared to queue-building traffic of equivalent importance." (leaving alone the question how an AP or a station is supposed to measure importance)

Sebastian

---

From: Greg White <[email-masked]>
Date: Tue, 5 Nov 2019 00:28:30 +0000

Hi Sebastian,

Interoperability with existing WiFi equipment is an important aspect, since WiFi latency can be considerable. By default, many existing APs only support 4 priority queues, and thus it is not possible to meet all of the requirements of the NQB PHB (at least in this default configuration).  Nonetheless, it is possible to utilize two of the four queues in order to meet some of the requirements, and thus provide some of the benefits of the NQB PHB.  With proper configuration and/or policies, this can be done safely.  The final SHOULD is intended to address your concern about prioritization (since it results in segregation without prioritization). Absent this requirement (or the ability to comply with it operationally), the operator would need to consider (and perhaps limit) which applications are allowed to be marked as NQB.  This aspect isn't discussed in the draft, but I will add it based on your input.

Network operators understand the value of segregating NQB traffic on WiFi links, and will almost certainly select a DSCP in practice that achieves that goal.  Assigning a different DSCP in this draft would do nothing to prevent them from doing so.  Instead, what we need to do is clearly articulate how to make best use of the existing WiFi tools, and how to avoid conflicts. 

In existing RFCs, the IETF already recommends that video conferencing applications mark their traffic as either AF4x or CS4, all of which get mapped to AC_VI.  The remaining language in the NQB draft describes sparser flows than these.

Based on your comments, I attempted to remove all text that could be interpreted as recommending that high-data-rate traffic be marked NQB.  It appears that I missed one instance (in the Introduction it gives "interactive voice and video" as an example). Aside from this (which I can correct), I think the draft currently recommends that NQB only be used for sparse traffic.  That said, the section where this guidance is intended to be given is still lacking in specificity, and poses some open questions that may need to be addressed in a subsequent revision.

Best Regards,
Greg

On 11/4/19, 3:25 PM, "tsvwg on behalf of Sebastian Moeller" <[email-masked] on behalf of [email-masked]> wrote:

    7.3.  WiFi Networks

    

    

    Sebastian

---

From: Sebastian Moeller <[email-masked]>
Date: Tue, 5 Nov 2019 09:58:35 +0100

Hi Greg,

> On Nov 5, 2019, at 01:28, Greg White <[email-masked]> wrote:
> 
> Hi Sebastian,
> 
> Interoperability with existing WiFi equipment is an important aspect, since WiFi latency can be considerable. By default, many existing APs only support 4 priority queues, and thus it is not possible to meet all of the requirements of the NQB PHB (at least in this default configuration).

	[SM] I agree the question is how to deal with that "impedance mismatch".

>  Nonetheless, it is possible to utilize two of the four queues in order to meet some of the requirements, and thus provide some of the benefits of the NQB PHB.  

	[SM] Unless you opt for selecting AC_BK for the NQB traffic, for most users the value of NQB will be mostly in the priority boost on wifi and the resulting air-time access advantage (which results in both lower latency and potentially higher bandwidth).

> With proper configuration and/or policies, this can be done safely.  

	[SM] Sure, I am concerned about the status quo wich does not entail "proper configuration and/or policies", and hence I believe the NQB special treatment on WIFI should be opt-in and not "opt-out" (in quotes as most endusers will not be able to opt-out). For thid reaon I believe that the proposal to use a code point that by default is mapped to AC_BK is the only correct solution (as a bonus it seems that such a code point also has a better chance to survive transit over the internet). NQB-aware APs then simply treat that NQB-codepoint however they want. If for example a priority boost is desired such an AP can easily implement the required rate-limiting so that AC_BE traffic does not get starved out. In short, I fully agree that special treatment requires "proper configuration and/or policies" and the desirable strategy if that can not guaranteed should be "do no harm".

> The final SHOULD is intended to address your concern about prioritization (since it results in segregation without prioritization).

	[SM] Ah, in that case the AP needs to be be NQB aware anyway, would it then not be better to use an appropriate scheduler/AQM in front of the AC_BE queue and keep all traffic in the same priority class? The disadvantage of setting AC_VI to the same EDCA values as AC_BE is then that applicatons that expect an airtime access boost from using AC_VI will not get it any more (not necessarily a deal-breaker but certainly unexpected enough to merit clear communication of that side-effect).

> Absent this requirement (or the ability to comply with it operationally), the operator would need to consider (and perhaps limit) which applications are allowed to be marked as NQB.  This aspect isn't discussed in the draft, but I will add it based on your input.

	[SM] Great! I would guess the safest would be to have the NQB-aware scheduler in an AP apply some (proportional) rate-limiting if NQB traffic is getting preferential air-time access.

> 
> Network operators understand the value of segregating NQB traffic on WiFi links, and will almost certainly select a DSCP in practice that achieves that goal.  

	[SM] That is exactly part of my concern with the default mapping to AC_VI approach, I expect that very quickly a lot of traffic will utilize the AC_VI queue potentially starving normal AC_BE traffic in the process.

> Assigning a different DSCP in this draft would do nothing to prevent them from doing so.
 
	[SM] Sure, but is that really a good justification for proposing a DSCP with known side-effects? As far as I am concerned an RFC should propose sane defaults and hope for the best.

>  Instead, what we need to do is clearly articulate how to make best use of the existing WiFi tools, and how to avoid conflicts. 

	[SM] I believe the last two are mutually exclusive...

> In existing RFCs, the IETF already recommends that video conferencing applications mark their traffic as either AF4x or CS4, all of which get mapped to AC_VI.  The remaining language in the NQB dra…

	[SM] as an implementer I read "relatively low data rates", without further guidance I have very little intuition what to use as reference. Could this be made more explicit? This is orthogonal to the question whether such a limit should be enforced in any way, here the question really is about getting a feel what is considered acceptable for NQB treatment.

> 
> Based on your comments, I attempted to remove all text that could be interpreted as recommending that high-data-rate traffic be marked NQB.  

	[SM] Thanks, as long as the aggregate NQB traffic is relative sparse compared to the available WiFi bandwidth (or the number of tx_ops) most of my WiFi concerns get less and less relevant. To be explicit, I do not object on principle to using AC_VI or even AC_VO as long as this does not eat significantly into the tx_ops for AC_BE, the current draft improves  in that direction. Would it be possible to make this point even stronger?

> It appears that I missed one instance (in the Introduction it gives "interactive voice and video" as an example). Aside from this (which I can correct), I think the draft currently recommends that NQB only be used for sparse traffic.  That said, the section where this guidance is intended to be given is still lacking in specificity, and poses some open questions that may need to be addressed in a subsequent revision.

	[SM] Sounds great. Now this then cycles back to one of the other open topics, "enforcement". Ideally NQB-aware APs should monitor both queues and re-assign flows between them based on flow-behavior in relation to time-variant bandwidth experienced by that flow. 

Best Regards
	Sebastian

---

From: "Black, David" <[email-masked]>
Date: Thu, 7 Nov 2019 20:02:45 +0000

I wanted to strongly +1 this portion of the discussion:

> > The final SHOULD is intended to address your concern about prioritization
> (since it results in segregation without prioritization).
> 
> 	[SM] Ah, in that case the AP needs to be be NQB aware anyway,
> would it then not be better to use an appropriate scheduler/AQM in front of
> the AC_BE queue and keep all traffic in the same priority class? The
> disadvantage of setting AC_VI to the same EDCA values as AC_BE is then that
> applications that expect an airtime access boost from using AC_VI will not get
> it any more (not necessarily a deal-breaker but certainly unexpected enough
> to merit clear communication of that side-effect).
> 
> > Absent this requirement (or the ability to comply with it operationally), the
> operator would need to consider (and perhaps limit) which applications are
> allowed to be marked as NQB.  This aspect isn't discussed in the draft, but I
> will add it based on your input.
> 
> 	[SM] Great! I would guess the safest would be to have the NQB-
> aware scheduler in an AP apply some (proportional) rate-limiting if NQB
> traffic is getting preferential air-time access.

This is an example of a good thing to do with all uses of "SHOULD" - at least warn about the risks and/or consequences of not following the "SHOULD" (or "SHOULD NOT"), and (even better) provide some advice on staying out of serious trouble in that case (as will be done here).  

Thanks!, --David

> -----Original Message-----
> From: tsvwg <[email-masked]> On Behalf Of Sebastian Moeller
> Sent: Tuesday, November 5, 2019 3:59 AM
> To: Greg White
> Cc: tsvwg IETF list
> Subject: Re: [tsvwg] draft-ietf-tsvwg-nqb, more questions
> 
> 
> [EXTERNAL EMAIL]
> 
> Hi Greg,
> 
> 
> > Interoperability with existing WiFi equipment is an important aspect, since
> WiFi latency can be considerable. By default, many existing APs only support
> 4 priority queues, and thus it is not possible to meet all of the requirements
> of the NQB PHB (at least in this default configuration).
> 
> >  Nonetheless, it is possible to utilize two of the four queues in order to
> meet some of the requirements, and thus provide some of the benefits of
> the NQB PHB.
> 
> 	[SM] Unless you opt for selecting AC_BK for the NQB traffic, for most
> users the value of NQB will be mostly in the priority boost on wifi and the
> resulting air-time access advantage (which results in both lower latency and
> potentially higher bandwidth).
> 
> 	[SM] Sure, I am concerned about the status quo wich does not entail
> "proper configuration and/or policies", and hence I believe the NQB special
> treatment on WIFI should be opt-in and not "opt-out" (in quotes as most
> endusers will not be able to opt-out). For thid reaon I believe that the
> proposal to use a code point that by default is mapped to AC_BK is the only
> correct solution (as a bonus it seems that such a code point also has a better
> chance to survive transit over the internet). NQB-aware APs then simply
> treat that NQB-codepoint however they want. If for example a priority boost
> is desired such an AP can easily implement the required rate-limiting so that
> AC_BE traffic does not get starved out. In short, I fully agree that special
> treatment requires "proper configuration and/or policies" and the desirable
> strategy if that can not guaranteed should be "do no harm".
> 
> > The final SHOULD is intended to address your concern about prioritization
> (since it results in segregation without prioritization).
> 
> 	[SM] Ah, in that case the AP needs to be be NQB aware anyway,
> would it then not be better to use an appropriate scheduler/AQM in front of
> the AC_BE queue and keep all traffic in the same priority class? The
> disadvantage of setting AC_VI to the same EDCA values as AC_BE is then that
> applicatons that expect an airtime access boost from using AC_VI will not get
> it any more (not necessarily a deal-breaker but certainly unexpected enough
> to merit clear communication of that side-effect).
> 
> > Absent this requirement (or the ability to comply with it operationally), the
> operator would need to consider (and perhaps limit) which applications are
> allowed to be marked as NQB.  This aspect isn't discussed in the draft, but I
> will add it based on your input.
> 
> 	[SM] Great! I would guess the safest would be to have the NQB-
> aware scheduler in an AP apply some (proportional) rate-limiting if NQB
> traffic is getting preferential air-time access.
> 
> >
> > Network operators understand the value of segregating NQB traffic on WiFi
> links, and will almost certainly select a DSCP in practice that achieves that
> goal.
> 
> 	[SM] That is exactly part of my concern with the default mapping to
> AC_VI approach, I expect that very quickly a lot of traffic will utilize the AC_VI
> queue potentially starving normal AC_BE traffic in the process.
> 
> 	[SM] Sure, but is that really a good justification for proposing a DSCP
> with known side-effects? As far as I am concerned an RFC should propose
> sane defaults and hope for the best.
> 
> >  Instead, what we need to do is clearly articulate how to make best use of
> the existing WiFi tools, and how to avoid conflicts.
> 
> > In existing RFCs, the IETF already recommends that video conferencing
> applications mark their traffic as either AF4x or CS4, all of which get mapped
> to AC_VI.  The remaining language in the NQB draft describes sparser flows
> than these.
> 
> 	[SM] as an implementer I read "relatively low data rates", without
> further guidance I have very little intuition what to use as reference. Could
> this be made more explicit? This is orthogonal to the question whether such
> a limit should be enforced in any way, here the question really is about
> getting a feel what is considered acceptable for NQB treatment.
> 
> >
> > Based on your comments, I attempted to remove all text that could be
> interpreted as recommending that high-data-rate traffic be marked NQB.
> 
> 	[SM] Thanks, as long as the aggregate NQB traffic is relative sparse
> compared to the available WiFi bandwidth (or the number of tx_ops) most of
> my WiFi concerns get less and less relevant. To be explicit, I do not object on
> principle to using AC_VI or even AC_VO as long as this does not eat
> significantly into the tx_ops for AC_BE, the current draft improves  in that
> direction. Would it be possible to make this point even stronger?
> 
> > It appears that I missed one instance (in the Introduction it gives
> "interactive voice and video" as an example). Aside from this (which I can
> correct), I think the draft currently recommends that NQB only be used for
> sparse traffic.  That said, the section where this guidance is intended to be
> given is still lacking in specificity, and poses some open questions that may
> need to be addressed in a subsequent revision.
> 
> 	[SM] Sounds great. Now this then cycles back to one of the other
> open topics, "enforcement". Ideally NQB-aware APs should monitor both
> queues and re-assign flows between them based on flow-behavior in
> relation to time-variant bandwidth experienced by that flow.
> 
> Best Regards
> 	Sebastian
> 
> >
> > Best Regards,
> > Greg
> >
> >
> > On 11/4/19, 3:25 PM, "tsvwg on behalf of Sebastian Moeller" <tsvwg-
> [email-masked] on behalf of [email-masked]> wrote:
> >
> >    [SM] This last section is puzzling: if the wifi system configures AC_VI with
> EDCA parameters that match the AC_BE parameters, AC_VI ceases to be
> different from AC_BE, in that case picking a codepoint that automatically
> maps to CS0 and hence to AC_BE  seems much safer, simpler and straight
> forward to me.
> >    Especially since essentially none of the millions deployed WiFi APs out
> there will a) have this configured like proposed already and b) none of the
> consumer APs I know actually allow to easily adjust EDCA parameters at all. I
> guess I must be missing something and would be delighted to be shown why
> the proposed text is the right thing.
> >    My take on this still is, if NQB traffic is sufficiently sparse using AC_VI can
> be justified, but without any rate limits this has the potential of being quite
> unfair to concurrent APs on the same channel (as well as the neighboring
> channels that overlap with the selected).
> >    I do not want to sound alarmist, but given the number of cable-ISP WiFi-
> APs (as indicated by a SSID containing the ISPs name) in my city, I believe
> making sure that those APs will not basically start hogging most airtime
> seems the prudent thing to do. If there are sufficient backstops in place (like
> rate limiting or automatic down-marking if the traffic is not sparse enough) to
> avoid the described situation, I am all for it.
> >
> >    The text probably should also openly discuss that in WiFi/WMM the four
> available queues by design have different priorities, and by moving NQB out
> of the default AC_BE while leaving QB flows in there, this effectively runs
> against  the following text in the draft: "The NQB queue SHOULD be given
> equal priority compared to queue-building traffic of equivalent importance."
> (leaving alone the question how an AP or a station is supposed to measure
> importance)
> >
> >
> >    Sebastian
> >
> >

---

From: Greg White <[email-masked]>
Date: Thu, 7 Nov 2019 20:36:48 +0000

Noted, and I agree that it is important.  I'll write some appropriate warning text.

BTW, just to avoid confusion, I'm reading your "strong +1" to be solely about adding warnings/advice in case the "final SHOULD" is not implemented (and similar, for other SHOULDs in the draft as well).   You also quoted some text from Sebastian which was factually incorrect (that an AP complying with the SHOULD is NQB aware).  I'm assuming you weren't "+1" on his conclusions from that, but correct me if I'm wrong.

-Greg

On 11/7/19, 1:02 PM, "Black, David" <[email-masked]> wrote:

    
    
    Thanks!, --David

---

From: Sebastian Moeller <[email-masked]>
Date: Thu, 7 Nov 2019 21:52:46 +0100

> On Nov 7, 2019, at 21:36, Greg White <[email-masked]> wrote:
> 
> BTW, just to avoid confusion, I'm reading your "strong +1" to be solely about adding warnings/advice in case the "final SHOULD" is not implemented (and similar, for other SHOULDs in the draft as well).   You also quoted some text from Sebastian which was factually incorrect (that an AP complying with the SHOULD is NQB aware).  

	[SM] Are you talking about:

"In order to preserve the incentives principle, WiFi systems SHOULD
   configure the EDCA parameters for the Video Access Category to match
   those of the Best Effort Access Category."

in the context of non NQB-aware APs? How feasible di you think it will be to expect all deployed APs to have the AC_VI EDCA parameters changed to comply with this recommendations, especially in the light that almost no APs actually offer to configure these parameters at all? Does it really make sense to propose a SHOULD that is known to be almost impossible to actually implement in virtually all existing APs?
I guess I must be misunderstanding you here, because the remedy for (arguably) misusing a prioritization system can not really be "disable the priority system", color me confuzed.

Best Regards
	Sebastian

> I'm assuming you weren't "+1" on his conclusions from that, but correct me if I'm wrong.
> 
> -Greg
> 
>

---

From: "Black, David" <[email-masked]>
Date: Thu, 7 Nov 2019 21:00:33 +0000

> > BTW, just to avoid confusion, I'm reading your "strong +1" to be solely
> about adding warnings/advice in case the "final SHOULD" is not implemented
> (and similar, for other SHOULDs in the draft as well).   

That's correct.

Thanks, --David

> From: Sebastian Moeller <[email-masked]>
> Sent: Thursday, November 7, 2019 3:53 PM
> To: Greg White
> Cc: Black, David; tsvwg IETF list
> > BTW, just to avoid confusion, I'm reading your "strong +1" to be solely
> about adding warnings/advice in case the "final SHOULD" is not implemented
> (and similar, for other SHOULDs in the draft as well).   You also quoted some
> text from Sebastian which was factually incorrect (that an AP complying with
> the SHOULD is NQB aware).
> 
> in the context of non NQB-aware APs? How feasible di you think it will be to
> expect all deployed APs to have the AC_VI EDCA parameters changed to
> comply with this recommendations, especially in the light that almost no APs
> actually offer to configure these parameters at all? Does it really make sense
> to propose a SHOULD that is known to be almost impossible to actually
> implement in virtually all existing APs?
> I guess I must be misunderstanding you here, because the remedy for
> (arguably) misusing a prioritization system can not really be "disable the
> priority system", color me confuzed.
> 
> Best Regards
> 	Sebastian
> 
> 
> >    This is an example of a good thing to do with all uses of "SHOULD" - at
> least warn about the risks and/or consequences of not following the
> "SHOULD" (or "SHOULD NOT"), and (even better) provide some advice on
> staying out of serious trouble in that case (as will be done here).
> >
> >    Thanks!, --David
> >
> >>> Assigning a different DSCP in this draft would do nothing to prevent
> them
> >> from doing so.
> >>

---

From: Sebastian Moeller <[email-masked]>
Date: Thu, 7 Nov 2019 22:04:02 +0100

Hi David,

> On Nov 7, 2019, at 22:00, Black, David <[email-masked]> wrote:
> 

	Regarding my point, what is the purpose of adding SHOULDs that for all means and purposes are impossible to see quantitatively implemented, even if the consequences are well discussed?

Sebastian

---

From: Greg White <[email-masked]>
Date: Thu, 7 Nov 2019 21:11:59 +0000

Sebastian,

In the interest of moving this forward and not going in circles, I think you summarized your position as: "To be explicit, I do not object on principle to using AC_VI or even AC_VO as long as this does not eat significantly into the tx_ops for AC_BE, the current draft improves  in that direction. Would it be possible to make this point even stronger?"  

In my view, as long as the applications that we're recommending to be marked NQB are no more bandwidth intensive than video conferencing (the applications that the IETF already recommends be marked with a DSCP that maps to AC_VI), then we have achieved what is needed.  Do you agree?

-Greg

On 11/5/19, 1:58 AM, "Sebastian Moeller" <[email-masked]> wrote:

    Hi Greg,

    

    

    

    

    

    

    

    Best Regards
    	Sebastian

---

From: Greg White <[email-masked]>
Date: Thu, 7 Nov 2019 21:40:39 +0000

Sebastian,

As far as I am aware, EDCA parameters are adjustable via user configuration on many Access Points.  It is available via the factory firmware in some cases, and it is available via openWRT.

-Greg

On 11/7/19, 2:04 PM, "Sebastian Moeller" <[email-masked]> wrote:

    Hi David,

    
    Sebastian

---

From: Sebastian Moeller <[email-masked]>
Date: Thu, 7 Nov 2019 23:00:39 +0100

Greg,

> On Nov 7, 2019, at 22:11, Greg White <[email-masked]> wrote:
> 
> Sebastian,
> 
> In the interest of moving this forward and not going in circles,

	[SM] My impression is not that we going in circles, it is a rather slow road to understanding and accepting the properties and limitations of wifi's unfortunate prioritization scheme in conjunction with your intended use of the NQB dscp. Me shutting up, would not change the underlaying facts that need to be considered here if the issue is to be solved.

> I think you summarized your position as: "To be explicit, I do not object on principle to using AC_VI or even AC_VO as long as this does not eat significantly into the tx_ops for AC_BE, the current draft improves  in that direction. Would it be possible to make this point even stronger?"  
> 

	To state the obvious, "no more bandwidth intensive than video conferencing" is virtually meaningless as it will give very little guidance on acceptable either single flow nor aggregate NQB traffic share or absolute bandwidth (yes rfc8325 is also pretty silent on this, but "look mum, the other guys are doing it too" is not the best of defenses IMHO). I realize that this is an issue for you as you explicitly target NQB as requiring no prioritization or rate-limiting, I get that; but I believe that on wifi since you effectively propose to use a prioritization system you really really should require rate-limiting. 

rfc8325, section 8.2:
"The wireless LAN presents a unique DoS attack vector, as endpoint
   devices contend for the shared media on a completely egalitarian
   basis with the network (as represented by the AP).  This means that
   any wireless client could potentially monopolize the air by sending
   packets marked to preferred UP values (i.e., UP values 4-7) in the
   upstream direction.  Similarly, airtime could be monopolized if
   excessive amounts of downstream traffic were marked/mapped to these
   same preferred UP values.  As such, the ability to mark/map to these
   preferred UP values (of UP 4-7) should be controlled.

   If such marking/mapping were not controlled, then, for example, a
   malicious user could cause WLAN DoS by flooding traffic marked CS7
   DSCP downstream.  This codepoint would map by default (as described
   in Section 2.3) to UP 7 and would be assigned to the Voice Access
   Category (AC_VO).  Such a flood could cause Denial-of-Service to not
   only wireless voice applications, but also to all other traffic
   classes.  Similarly, an uninformed application developer may request
   all traffic from his/her application be marked CS7 or CS6, thinking
   this would achieve the best overall servicing of their application
   traffic, while not realizing that such a marking (if honored by the
   client operating system) could cause not only WLAN DoS, but also IP
   network instability, as the traffic marked CS7 or CS6 finds its way
   into queues intended for servicing (relatively low-bandwidth) network
   control protocols, potentially starving legitimate network control
   protocols in the process."

To me this clearly indicates that the achievable wifi rate betwnn AP and each station needs to be taken into account when considering which fraction of > AC_BE traffic is acceptable. So very much incompatible with your goal of having endpoints set the NQB dscp based on their own best assessment of traffic type without some sanitization at the AP level (only the AP will have a reasonable chance of predicting immediate achievable rates with some confidence, neither endpoints nor intermediate low latency queue enabled AQMs have sufficient knowledge to judge what traffic rate is acceptable for AC_VI). I consider it to be quite unfortunate that rfc8325 has no references to research on real-world data on the consequences of actually following through with its recommendations, nor that it has robust recommendations of recommended maximal fractions of the achievable rate each AC should be constrained to.

All of this is not really rocket science, and the obvious solution, following both the principle of least surprise and a "first, do no harm" maxim is to select the NQB dscp such that the unfortunate default DSCP to AC mappings keep NQB marked traffic in the AC_BE queue, UNLESS the AP is NQB-aware in which case the AP should be mandated to at least reliably avoid starvation of ACs.
The amount of back and forth seems to indicate that this is not an outcome you consider desirable.

Sebastian

---

From: Dave Taht <[email-masked]>
Date: Thu, 07 Nov 2019 14:24:56 -0800

I'm not sure if I should weigh in here or not. A couple notes...

802.11e was seemingly a good idea in 2004, when men were men, APs
scarce, and txops limited to about 3000/sec.

802.11n added packet aggregation, and 802.11ac added ever more
dense encodings to wedge even more data into that txop...

but the limiting factor for wifi - particularly in dense environments
with a range of standards being broadcast remains that fatal 3000
txops/sec - and while that's a little mitgated by mu-mimo and with
wifi 6 in ofdma mode made MUCH better, having to be backward compatible
elsewhere still messes things up.

furthermore, in 802.11n the VO queue cannot aggregate. 700usec lost
on a single packet.

Use of the VI queue was often buggy in 802.11n chipsets at least as
far back as 2014 when I last poked into it. The main tested paths
have generally been BE, BK, and to a small extent VO.

I've got plenty of data showing that it's in general better (from the
AP's standpoint) to well multiplex and fully fill as best as possible
just the BE queue for each station, to ignore 802.11e, and to try to
manage the max txop size in BE in proportion to the load.

We pointed to that result in "ending the anomaly".

and 802.11e scales ever more badly to ever more devices.

>From the stations standpoint, it can be (if lightly used) to still
use the 802.11e stuff, but that should at best be sparingly used.

Some (mostly enterprise) wifi routers do fiddle with the edca params
some, in particular it does make sense at higher workloads to clamp the
size of txops to stations are allowed to transmit (via the beacon), and
I wish more wifi routers did that.

But trying to actively use the 802.11e priorities at this late date,
not huge on it. Twiddling edca extensively seems like an especially bad idea.

That said, I've been meaning to dig up my old work on the subject,
look at it in light of modern conditions, but given that most of
my aircaps still see some wireless-g APs helping mess up things up,
don't think I have huge reasons to change my current take on it.

I guess my core takeway I'd like people to think about is txops/sec
relative to how much data can be stuffed into a txop, in the real world,
rather than trying to make 802.11e do anything useful.

---

From: Greg White <[email-masked]>
Date: Thu, 7 Nov 2019 22:44:45 +0000

Sebastian,

I agree that this isn't rocket science.  In the existing WiFi systems that we're discussing, there are 16 DSCPs that get mapped to AC_VI, and 16 DSCPs that get mapped to AC_VO.   No one polices any of them in residential WiFi networks!  There is nothing that prevents anyone from writing an application today that sends bulk traffic marked as CS7 (a value that the IETF considers to be reserved).  

I believe that the reason that RFC 8325 simply wrings its hands over this issue, as opposed to solving it, is that A) it is a *really* hard problem to solve in an unmanaged network, and B) while it is certainly a problem in theory, there is no evidence that it is a real problem in practice.  

Blocking the IETF from assigning NQB the 0x2A value does *nothing* to prevent an application from using 0x2A (or any of the other 31 code points that you are concerned about) for *any* purpose that the application developer sees fit, it does *nothing* to prevent a network operator from using 0x2A for NQB traffic, and it does *nothing* to help solve the main issue that you are concerned about.

If you want to solve this problem, my suggestion is that you start a new draft proposing a technology that will holistically protect WiFi networks from all potential DSCP abuses. 

Greg

On 11/7/19, 3:00 PM, "Sebastian Moeller" <[email-masked]> wrote:

    Greg,

    
    
    rfc8325, section 8.2:

    

    Sebastian

---

From: Greg White <[email-masked]>
Date: Thu, 7 Nov 2019 22:59:00 +0000

Dave,

Thanks for these thoughts.  I agree that a better solution for NQB is to have the WiFi devices *actually* support the NQB PHB (or support fq_* if that is what you prefer), as opposed to putting NQB traffic into a separate Access Category.   That is essentially the default recommendation of the draft (i.e. support the actual requirements in the draft), even though it doesn't explicitly mention WiFi in that context.  This discussion is more about interoperability with existing WiFi gear that does not support the PHB.   

BTW, our experiments have shown that .11ac implementations actually do a pretty good job at implementing WMM (some better than others).  But I've heard anecdotally about older gear that suffers from priority inversions, etc.

-Greg

On 11/7/19, 3:25 PM, "Dave Taht" <[email-masked]> wrote:

---

From: Sebastian Moeller <[email-masked]>
Date: Fri, 8 Nov 2019 00:11:50 +0100

Hi Greg,

> On Nov 7, 2019, at 23:44, Greg White <[email-masked]> wrote:
> 
> Sebastian,
> 

	[SM] Sure, but thanks to ISP often bleaching DSCPs there currently is very little in and outgoing traffic that actually maps to anything but AC_BE, you propose to change that in a major way, with your attempt at making NQB end to end (with one end potentially being in a close data center with an SLA allowing for NQB survival). Just because no one has massively abused this so far, is NOT a justification to do so now.

> I believe that the reason that RFC 8325 simply wrings its hands over this issue, as opposed to solving it, is that A) it is a *really* hard problem to solve in an unmanaged network, and B) while it…

	[SM] The problem is that there is simply no data, and interpreting this as there is no problem is neither solid science nor engineering. If you have measurements showing that this is no problem with the expected traffic rates with the NQB marking, please feel free to post them to the list or as PM.

> Blocking the IETF from assigning NQB the 0x2A value does *nothing* to prevent an application from using 0x2A (or any of the other 31 code points that you are concerned about) for *any* purpose that…

	[SM] It will keep one expected major source of DSCP marked traffic on a sane(r) policy. Most users and applications do not bother paying with dscps so the current amount of abuse is limited (and if I configure my internal skype and ssh applications to even use AC_VO I can control their activity and usage much better than I can traffic rushing in from the internet). Sure I can re-map 0x2A to a sane value on ingress to my network, but that is not going to help that much if my neighbors do not do this, and their APs start hogging all tx_ops on the shared channel.

> If you want to solve this problem, my suggestion is that you start a new draft proposing a technology that will holistically protect WiFi networks from all potential DSCP abuses. 

	[SM] First rule of holes, put the shovel away when you find yourself inside one. Here, I am not concerned so much in fixing all wifi AC abuse and more in giving my best to avoid this unfortunate and undesirable condition getting worse.

Sebastian

---

From: Greg White <[email-masked]>
Date: Thu, 7 Nov 2019 23:20:16 +0000

You've still missed the point.

    	[SM] It will keep one expected major source of DSCP marked traffic on a sane(r) policy.

No. It won't. 

What will keep that source on a sane policy is that they have an interest in having a sane policy.  This IETF draft does not create that interest, nor would it prevent them from running amok.   

-Greg

On 11/7/19, 4:12 PM, "Sebastian Moeller" <[email-masked]> wrote:

    Hi Greg,

    

    

    
    Sebastian

---

From: Sebastian Moeller <[email-masked]>
Date: Fri, 8 Nov 2019 00:24:55 +0100

Hi David,

>> (and similar, for other SHOULDs in the draft as well).   

	[SM] Here is an attempt at doing this for the last paragraph in the wifi section:

In order to preserve the incentives principle, WiFi systems SHOULD configure the EDCA parameters for the Video Access Category to match those of the Best Effort Access Category. 

Not doing this risks that sufficiently high rate NQB traffic completely starves out normal traffic in the AC_BE queue. Doing this on the other hand will violate the traffic prioritization that rfc8325-compliant applications might expect from using dscp's that normally map into the AC_VI priority queue.

Question, does it really make sense to refer to rfc8325 and then to recommend to basically invalidate that RFC's assumptions?

Sebastian

---

From: Greg White <[email-masked]>
Date: Thu, 7 Nov 2019 23:35:57 +0000

[GW] One data point is that most consumer routers ship with WMM enabled by default.  If there were rampant misuse of DSCP such that WMM was unusable, I would expect that many APs would ship with it disabled by default, and let the user decide whether to risk turning it on.

---

From: Sebastian Moeller <[email-masked]>
Date: Fri, 8 Nov 2019 01:09:11 +0100

> On Nov 8, 2019, at 00:20, Greg White <[email-masked]> wrote:
> 

	[SM] Sorry with source, I was not talking about individual senders, but about the "NQB/L4S complex" that I expect to cause a lot of NQB marked traffic to appear on the ingress side of home users ionce it gets off the ground. And my point is very much to give my best arguments to make sure you do not end up writing a bad policy into an RFC. What ever you do in the real world is outside of the scope of the IETF, but taking that as an argument in favor of bad engineering is simply a bad argument.
	And regarding your interpretation of individual senders, it is clear that remote senders have a snowballs chance in hell to react timely to the variable bitrates on a wifi segment, hence the wifi elements AP (and ideally STAs) will need to enforce sanity and make sure tp avoid starvation. This is not a new requirement, but the status quo is that most traffic is AC_BE, so the lack of enforcement was sort of tolerable; but either NQB withers away and will not be used (and all of this discussion does not matter) or it will be used and then you better make sure that NQB will not be found out as a reason why non-NQB on-line gaming starts to suck. But really looking at the AC stats from my laptop:

laptop:~ user$ sudo netstat -I en0 -qq
en0:
     [ sched:  FQ_CODEL  qlength:    0/128 ]
     [ pkts:          0  bytes:          0  dropped pkts:    185 bytes:  55724 ]
=====================================================
     [ pri: VO (1)	srv_cl: 0x400180	quantum: 600	drr_max: 8 ]
     [ queued pkts: 0	bytes: 0 ]
     [ dequeued pkts: 171322	bytes: 15967234 ]
     [ budget: 0	target qdelay: 10.00 msec	update interval:100.00 msec ]
     [ flow control: 0	feedback: 0	stalls: 0	failed: 0 ]
     [ drop overflow: 0	early: 0	memfail: 0	duprexmt:0 ]
     [ flows total: 0	new: 0	old: 0 ]
     [ throttle on: 0	off: 0	drop: 0 ]
=====================================================
     [ pri: VI (2)	srv_cl: 0x380100	quantum: 3000	drr_max: 6 ]
     [ queued pkts: 0	bytes: 0 ]
     [ dequeued pkts: 1081254	bytes: 95307849 ]
     [ budget: 0	target qdelay: 10.00 msec	update interval:100.00 msec ]
     [ flow control: 0	feedback: 0	stalls: 0	failed: 0 ]
     [ drop overflow: 0	early: 0	memfail: 0	duprexmt:0 ]
     [ flows total: 0	new: 0	old: 0 ]
     [ throttle on: 0	off: 0	drop: 0 ]
=====================================================
     [ pri: BE (7)	srv_cl: 0x0	quantum: 1500	drr_max: 4 ]
     [ queued pkts: 0	bytes: 0 ]
     [ dequeued pkts: 41792980	bytes: 10120070005 ]
     [ budget: 0	target qdelay: 10.00 msec	update interval:100.00 msec ]
     [ flow control: 9	feedback: 9	stalls: 8	failed: 0 ]
     [ drop overflow: 0	early: 5	memfail: 0	duprexmt:0 ]
     [ flows total: 0	new: 0	old: 0 ]
     [ throttle on: 0	off: 0	drop: 0 ]
=====================================================
     [ pri: BK (8)	srv_cl: 0x100080	quantum: 1500	drr_max: 2 ]
     [ queued pkts: 0	bytes: 0 ]
     [ dequeued pkts: 4392109	bytes: 1258595132 ]
     [ budget: 0	target qdelay: 10.00 msec	update interval:100.00 msec ]
     [ flow control: 2	feedback: 2	stalls: 2	failed: 0 ]
     [ drop overflow: 0	early: 0	memfail: 0	duprexmt:0 ]
     [ flows total: 0	new: 0	old: 0 ]
     [ throttle on: 0	off: 0	drop: 0 ]

and my OpenWrt router:

root@router:~# cat /sys/kernel/debug/ieee80211/phy1/ath9k/xmit
                            BE         BK        VI        VO

MPDUs Queued:             4933        120       595     47628
MPDUs Completed:          2765        331      1045    110627
MPDUs XRetried:           2792         30       381       216
Aggregates:            4053416     109096     11152         0
AMPDUs Queued HW:            0          0         0         0
AMPDUs Completed:     29761018     931822    280598         0
AMPDUs Retried:         484203      23327      4543         0
AMPDUs XRetried:          8606        149       754         0
TXERR Filtered:             97          7        32        37
FIFO Underrun:               0          0         0         0
TXOP Exceeded:               0          0         0         0
TXTIMER Expiry:              0          0         0         0
DESC CFG Error:              0          0         0         0
DATA Underrun:               0          0         0         0
DELIM Underrun:              0          0         0         0
TX-Pkts-All:          29775181     932332    282778    110843
TX-Bytes-All:        672115293 1008162267 199579558  20417055
HW-put-tx-buf:               8          8         8         8
HW-tx-start:          21266021     570626    256944    110799
HW-tx-proc-desc:      21266026     570629    257004    110839
TX-Failed:                   0          0         0         0

Summary packet numbers:
AC	Laptop
BE:		 41792980	29775181
BK:		   4392109	    932332
VI:		   1081254	    282778
VO:		     171322	    110843
Total:	 47437665	31101134

So my status quo is that all four AC are used with the fraction of AC_VI+AC_VO at 
100*(1081254+ 171322)/47437665 = 2.6 % (laptop)
100*(282778 + 110843)/31101134 = 1.3 % (router)

This is with relative high streaming media usage.

Best Regards
	Sebastian

---

From: Sebastian Moeller <[email-masked]>
Date: Fri, 8 Nov 2019 01:14:07 +0100

> On Nov 8, 2019, at 00:35, Greg White <[email-masked]> wrote:
> 

	[SM] I am not a big fan of such inductive evidence generation. Also I applaud your confidence into vendor sanity. But if I recall correctly to use higher data rates in >=802.11ac WMM is mandatory, so disabling it is as far as I can tell not as straight forward and the naive "just disable it completely" approach seems not in the interest of device manufacturers if that would cost in the number one marketing value, achievable rates in speedtests.

Sebastian

---

From: Greg White <[email-masked]>
Date: Fri, 8 Nov 2019 00:44:31 +0000

It seems as if you are arguing from religious grounds.   There is no "NQB/L4S complex" that is nefariously seeking to saturate your home network.

So, I will try to ask the question again.

If the policy that gets written into the RFC is that NQB traffic should not be high data rate traffic, then this achieves your objective?  If we include a paragraph like that which exists in RFC 8325 that explains why, in the case of WiFi networks, it should not be high data rate traffic, would that be sufficient? 

-Greg

On 11/7/19, 5:09 PM, "Sebastian Moeller" <[email-masked]> wrote:

    

    
    
    and my OpenWrt router:

    Summary packet numbers:
    AC	Laptop
    BE:		 41792980	29775181
    BK:		   4392109	    932332
    VI:		   1081254	    282778
    VO:		     171322	    110843
    Total:	 47437665	31101134

    Best Regards
    	Sebastian

---

From: Sebastian Moeller <[email-masked]>
Date: Fri, 8 Nov 2019 09:30:43 +0100

Hi Greg,

> On Nov 8, 2019, at 01:44, Greg White <[email-masked]> wrote:
> 
> It seems as if you are arguing from religious grounds.  

	[SM] ??? I am just opposed to shitty engineering and against enshrining recommendations into an RFC that have considerable easy to predict side-effects on most of the deployed networks.

> There is no "NQB/L4S complex" that is nefariously seeking to saturate your home network.

	[SM] Yes that is my point, it is not malice I see here, but unwillingness to think through the consequences and side-effects of proposed solutions (combined with a tendency to simply brush off reviewer comments) that on the face of it seems a good fit to the problem, but comes at the cost of everybody else.

> If the policy that gets written into the RFC is that NQB traffic should not be high data rate traffic, then this achieves your objective?  If we include a paragraph like that which exists in RFC 83…

	[SM] Well, if you would list video explicitly as not qualifying for NQB and add a paragraph to the wifi section discussing the risk of starving normal traffic if there is too much traffic in AC_VI and AC_VO especially considering the variable rate nature of wifi links this would go a long way. 
Now wording in the draft is one thing and realistic use by interested senders is a whole different kettle of fish; wich cycles back to the queue protection issue.

But since we are having a go at this let me opine on section 8:

8.  Open Points
   o  Traffic Protection: SHOULD or MUST?

[SM] I argue for a MUST as otherwise "It is worthwhile to note that the NQB designation and marking is intended to convey verifiable traffic behavior, not needs or wants." does not make any sense at all.

   o  Traffic Protection: what are the detailed requirements?

[SM] a) avoid starvation of QB traffic, b) aim to not make the existing rate inequalities between different flows worse...

   o  DSCP value vis a vis WMM: VideoAC or BestEffortAC?

[SM] From my perspective AC_BE unless the AP is NQB aware and takes measures to avoid starvation of AC_BE, in that case I would consider AC_VI to be a viable solution.

   o  Are there hidden requirements in Section 9 of the individual draft?

[SM] Section 9 is Acknowledgements, so this question seems to be referring to something els. What exactly?

   o  Is more discussion needed around applicability in order to give
      guidance to application devs?

[SM] I would desire to see relative exhaustive lists of traffic types/applications that in your opinion are qualified for NQB treatment as well as such a list for traffic types/applications that do not qualify for NQB traffic. Implementing and mandating the use of queue protection and not using AC_VI on non NQB-aware APs, IMHO would allow to keep these lists less explicit and more general.

And then there is:
"Editor's Note: Do we need to answer the following questions?  How can
   an application determine whether it is queue building or not, given
   that the sending application is generally not aware of the available
   capacity of the path to the receiving endpoint?  Even if the
   application were to be aware of the capacity of the path, how could
   it be sure that the available capacity (considering other flows that
   may be sharing the path) would be sufficient to result in the
   application's traffic not causing a queue to form?"

IMHO opinion these question highlight the absurdity of calling the PHB Non-queue building in the first place (a queue builds if ingress rate of a flow is larger than its egress rate at a bottleneck, and since the endpoints can only control one of these properties a flow has no way of deciding whether it is queue building or not). It also convinces me that queue protection/ and anti-starvation enforcement are of essence to make sure end up in the appropriate queue (in other words treat NQB as a hint, but make sure the "boost" NQB-marking entails is commensurate to the actual traffic situation on the ground).

Best Regards
	Sebastian

---

From: "Black, David" <[email-masked]>
Date: Fri, 8 Nov 2019 19:41:59 +0000

> Question, does it really make sense to refer to rfc8325 and then to
> recommend to basically invalidate that RFC's assumptions?

Yes, RFC 8325 is rather new, so providing recommendations both for situations in which it is supported and for situations in which it is not supported does make sense.

There's recent relevant experience in what TSVWG went through to select a recommended DSCP for the LE PHB.  The network behavior (observed in the Internet) that was the primary cause of that consternation was bleaching (zeroing) the IP precedence field, whose bits were respecified to be part of the DSCP field by RFC 2474.  So, in that case, TSVWG was dealing with equipment that did not comply with RFC 2474 ... which is much older than RFC 8325. 

Thanks, --David

> Sent: Thursday, November 7, 2019 6:25 PM
> To: Black, David
> Cc: Greg White; tsvwg IETF list
> In order to preserve the incentives principle, WiFi systems SHOULD configure
> the EDCA parameters for the Video Access Category to match those of the
> Best Effort Access Category.
> 
> Not doing this risks that sufficiently high rate NQB traffic completely starves
> out normal traffic in the AC_BE queue. Doing this on the other hand will
> violate the traffic prioritization that rfc8325-compliant applications might
> expect from using dscp's that normally map into the AC_VI priority queue.
> 
> 
> Question, does it really make sense to refer to rfc8325 and then to
> recommend to basically invalidate that RFC's assumptions?
> 
> 
> Sebastian
> 
> 
> 
> 
> >
> > Thanks, --David
> >
> >>> Noted, and I agree that it is important.  I'll write some appropriate
> warning
> >> text.
> >>>
> >>> I'm assuming you weren't "+1" on his conclusions from that, but correct
> me
> >> if I'm wrong.
> >>>
> >>> -Greg
> >>>
> >>>
> >>>> would it then not be better to use an appropriate scheduler/AQM in
> front
> >> of
> >>>> disadvantage of setting AC_VI to the same EDCA values as AC_BE is
> then
> >> that
> >>>> applications that expect an airtime access boost from using AC_VI will
> not
> >> get
> >>>>> Absent this requirement (or the ability to comply with it
> operationally),
> >> the
> >>>> allowed to be marked as NQB.  This aspect isn't discussed in the draft,
> but
> >> I
> >>>> meet some of the requirements, and thus provide some of the
> benefits
> >> of
> >>>> the NQB PHB.
> >>>>
> >>>> would it then not be better to use an appropriate scheduler/AQM in
> front
> >> of
> >>>> disadvantage of setting AC_VI to the same EDCA values as AC_BE is
> then
> >> that
> >>>> applicatons that expect an airtime access boost from using AC_VI will
> not
> >> get
> >>>>> Absent this requirement (or the ability to comply with it
> operationally),
> >> the
> >>>> allowed to be marked as NQB.  This aspect isn't discussed in the draft,
> but
> >> I
> >>>>> Network operators understand the value of segregating NQB traffic
> on
> >> WiFi
> >>>>> Instead, what we need to do is clearly articulate how to make best
> use
> >> of
> >>>> my WiFi concerns get less and less relevant. To be explicit, I do not
> object
> >> on
> >>>> guess I must be missing something and would be delighted to be
> shown
> >> why
> >>>> available queues by design have different priorities, and by moving
> NQB
> >> out

---

From: "Black, David" <[email-masked]>
Date: Fri, 8 Nov 2019 19:56:44 +0000

Hi Greg,

Backing up a few messages, I might have found a way out of this debate.   Sebastian wrote:

>     	[SM] Sorry with source, I was not talking about individual senders,
> but about the "NQB/L4S complex" that I expect to cause a lot of NQB marked
> traffic to appear on the ingress side of home users once it gets off the
> ground.

That specific situation appears to be straightforward to address because the edge of the ISP network that supports Diffserv is involved.   Specifically, the specification of the NQB PHB ought to include text to the effect that outbound NQB-marked traffic MUST be rate limited at the egress from the Diffserv domain/region if the downstream (receiving) network is not known to support NQB (this is not the precise language, but should convey the concept).   In the reverse direction rate limiting NQB traffic on ingress (or outright bleaching it to best effort if the subscriber should not be using NQB in the first place) seems like a good idea, and may rise to the level of a MUST requirement if the NQB-supporting  network that the traffic is entering does not implement traffic protection for the NQB "queue" at each network node.  With a little creativity, the necessary rate limiting might be able to take advantage of an NQB queue protection mechanism if one is present at the Diffserv edge.

The individual sender situation appears to be of less concern, as at least in this case it looks like an instance of:

	If you point the gun at your own foot and pull the trigger, do not ask where the hole in your foot came from.

As, at least for the home user, the result is only to damage her own WiFi network, particularly if the ISP ingress node protects its network from the user sending too much NQB-marked traffic.

Thanks, --David

> From: tsvwg <[email-masked]> On Behalf Of Greg White
> Sent: Thursday, November 7, 2019 7:45 PM
> To: Sebastian Moeller
> Cc: tsvwg IETF list
> It seems as if you are arguing from religious grounds.   There is no "NQB/L4S
> complex" that is nefariously seeking to saturate your home network.
> 
> If the policy that gets written into the RFC is that NQB traffic should not be
> high data rate traffic, then this achieves your objective?  If we include a
> paragraph like that which exists in RFC 8325 that explains why, in the case of
> WiFi networks, it should not be high data rate traffic, would that be
> sufficient?
> 
> -Greg
> 
> 
>     > What will keep that source on a sane policy is that they have an interest
> in having a sane policy.  This IETF draft does not create that interest, nor
> would it prevent them from running amok.
>     >
>     > -Greg
> 
>     	[SM] Sorry with source, I was not talking about individual senders,
> but about the "NQB/L4S complex" that I expect to cause a lot of NQB marked
> traffic to appear on the ingress side of home users ionce it gets off the
> ground. And my point is very much to give my best arguments to make sure
> you do not end up writing a bad policy into an RFC. What ever you do in the
> real world is outside of the scope of the IETF, but taking that as an argument
> in favor of bad engineering is simply a bad argument.
>     	And regarding your interpretation of individual senders, it is clear that
> remote senders have a snowballs chance in hell to react timely to the
> variable bitrates on a wifi segment, hence the wifi elements AP (and ideally
> STAs) will need to enforce sanity and make sure tp avoid starvation. This is
> not a new requirement, but the status quo is that most traffic is AC_BE, so
> the lack of enforcement was sort of tolerable; but either NQB withers away
> and will not be used (and all of this discussion does not matter) or it will be
> used and then you better make sure that NQB will not be found out as a
> reason why non-NQB on-line gaming starts to suck. But really looking at the
> AC stats from my laptop:
> 
>     >> I agree that this isn't rocket science.  In the existing WiFi systems that
> we're discussing, there are 16 DSCPs that get mapped to AC_VI, and 16
> DSCPs that get mapped to AC_VO.   No one polices any of them in residential
> WiFi networks!  There is nothing that prevents anyone from writing an
> application today that sends bulk traffic marked as CS7 (a value that the IETF
> considers to be reserved).
>     >
>     >    	[SM] Sure, but thanks to ISP often bleaching DSCPs there currently is
> very little in and outgoing traffic that actually maps to anything but AC_BE,
> you propose to change that in a major way, with your attempt at making NQB
> end to end (with one end potentially being in a close data center with an SLA
> allowing for NQB survival). Just because no one has massively abused this so
> far, is NOT a justification to do so now.
>     >
>     >
>     >>
>     >> I believe that the reason that RFC 8325 simply wrings its hands over this
> issue, as opposed to solving it, is that A) it is a *really* hard problem to solve
> in an unmanaged network, and B) while it is certainly a problem in theory,
> there is no evidence that it is a real problem in practice.
>     >
>     >    	[SM] The problem is that there is simply no data, and interpreting this
> as there is no problem is neither solid science nor engineering. If you have
> measurements showing that this is no problem with the expected traffic
> rates with the NQB marking, please feel free to post them to the list or as
> PM.
>     >
>     >>
>     >>
>     >> Blocking the IETF from assigning NQB the 0x2A value does *nothing* to
> prevent an application from using 0x2A (or any of the other 31 code points
> that you are concerned about) for *any* purpose that the application
> developer sees fit, it does *nothing* to prevent a network operator from
> using 0x2A for NQB traffic, and it does *nothing* to help solve the main issue
> that you are concerned about.
>     >
>     >    	[SM] It will keep one expected major source of DSCP marked traffic
> on a sane(r) policy. Most users and applications do not bother paying with
> dscps so the current amount of abuse is limited (and if I configure my internal
> skype and ssh applications to even use AC_VO I can control their activity and
> usage much better than I can traffic rushing in from the internet). Sure I can
> re-map 0x2A to a sane value on ingress to my network, but that is not going
> to help that much if my neighbors do not do this, and their APs start hogging
> all tx_ops on the shared channel.
>     >
>     >>
>     >> If you want to solve this problem, my suggestion is that you start a new
> draft proposing a technology that will holistically protect WiFi networks from
> all potential DSCP abuses.
>     >
>     >    	[SM] First rule of holes, put the shovel away when you find yourself
> inside one. Here, I am not concerned so much in fixing all wifi AC abuse and
> more in giving my best to avoid this unfortunate and undesirable condition
> getting worse.
>     >
>     >
>     >
>     >    Sebastian
>     >
>     >
>     >
>     >>
>     >> Greg
>     >>
>     >>
>     >>
>     >>
>     >>   	[SM] My impression is not that we going in circles, it is a rather slow
> road to understanding and accepting the properties and limitations of wifi's
> unfortunate prioritization scheme in conjunction with your intended use of
> the NQB dscp. Me shutting up, would not change the underlaying facts that
> need to be considered here if the issue is to be solved.
>     >>
>     >>
>     >>> I think you summarized your position as: "To be explicit, I do not object
> on principle to using AC_VI or even AC_VO as long as this does not eat
> direction. Would it be possible to make this point even stronger?"
>     >>>
>     >>> In my view, as long as the applications that we're recommending to be
> marked NQB are no more bandwidth intensive than video conferencing (the
> applications that the IETF already recommends be marked with a DSCP that
> maps to AC_VI), then we have achieved what is needed.  Do you agree?
>     >>
>     >>   	To state the obvious, "no more bandwidth intensive than video
> conferencing" is virtually meaningless as it will give very little guidance on
> acceptable either single flow nor aggregate NQB traffic share or absolute
> bandwidth (yes rfc8325 is also pretty silent on this, but "look mum, the other
> guys are doing it too" is not the best of defenses IMHO). I realize that this is
> an issue for you as you explicitly target NQB as requiring no prioritization or
> rate-limiting, I get that; but I believe that on wifi since you effectively
> propose to use a prioritization system you really really should require rate-
> limiting.
>     >>
>     >>   rfc8325, section 8.2:
>     >>   To me this clearly indicates that the achievable wifi rate betwnn AP and
> each station needs to be taken into account when considering which fraction
> of > AC_BE traffic is acceptable. So very much incompatible with your goal of
> having endpoints set the NQB dscp based on their own best assessment of
> traffic type without some sanitization at the AP level (only the AP will have a
> reasonable chance of predicting immediate achievable rates with some
> confidence, neither endpoints nor intermediate low latency queue enabled
> AQMs have sufficient knowledge to judge what traffic rate is acceptable for
> AC_VI). I consider it to be quite unfortunate that rfc8325 has no references
> to research on real-world data on the consequences of actually following
> through with its recommendations, nor that it has robust recommendations
> of recommended maximal fractions of the achievable rate each AC should be
> constrained to.
>     >>
>     >>   All of this is not really rocket science, and the obvious solution,
> following both the principle of least surprise and a "first, do no harm" maxim
> is to select the NQB dscp such that the unfortunate default DSCP to AC
> mappings keep NQB marked traffic in the AC_BE queue, UNLESS the AP is
> NQB-aware in which case the AP should be mandated to at least reliably
> avoid starvation of ACs.
>     >>>> Interoperability with existing WiFi equipment is an important aspect,
> since WiFi latency can be considerable. By default, many existing APs only
> support 4 priority queues, and thus it is not possible to meet all of the
> requirements of the NQB PHB (at least in this default configuration).
>     >>>
>     >>>> Nonetheless, it is possible to utilize two of the four queues in order
> to meet some of the requirements, and thus provide some of the benefits of
> the NQB PHB.
>     >>>
>     >>>> The final SHOULD is intended to address your concern about
> prioritization (since it results in segregation without prioritization).
>     >>>
> operationally), the operator would need to consider (and perhaps limit)
> which applications are allowed to be marked as NQB.  This aspect isn't
> discussed in the draft, but I will add it based on your input.
>     >>>
> on WiFi links, and will almost certainly select a DSCP in practice that achieves
> that goal.
>     >>>
> them from doing so.
> use of the existing WiFi tools, and how to avoid conflicts.
>     >>>
>     >>>> In existing RFCs, the IETF already recommends that video
> conferencing applications mark their traffic as either AF4x or CS4, all of which
> get mapped to AC_VI.  The remaining language in the NQB draft describes
> sparser flows than these.
>     >>>
>     >>>> Based on your comments, I attempted to remove all text that could
> be interpreted as recommending that high-data-rate traffic be marked NQB.
>     >>>
>     >>>> [SM] This last section is puzzling: if the wifi system configures AC_VI
> with EDCA parameters that match the AC_BE parameters, AC_VI ceases to
> be different from AC_BE, in that case picking a codepoint that automatically
>     >>>> My take on this still is, if NQB traffic is sufficiently sparse using AC_VI
> can be justified, but without any rate limits this has the potential of being
> quite unfair to concurrent APs on the same channel (as well as the
> neighboring channels that overlap with the selected).
>     >>>> I do not want to sound alarmist, but given the number of cable-ISP
> WiFi-APs (as indicated by a SSID containing the ISPs name) in my city, I
> believe making sure that those APs will not basically start hogging most
> airtime seems the prudent thing to do. If there are sufficient backstops in
> place (like rate limiting or automatic down-marking if the traffic is not sparse
> enough) to avoid the described situation, I am all for it.
>     >>>>
>     >>>> The text probably should also openly discuss that in WiFi/WMM the
> four available queues by design have different priorities, and by moving NQB
> out of the default AC_BE while leaving QB flows in there, this effectively runs

---

From: Sebastian Moeller <[email-masked]>
Date: Sat, 9 Nov 2019 00:18:15 +0100

Hi David,

thanks, more below.

> On Nov 8, 2019, at 20:41, Black, David <[email-masked]> wrote:
> 

	[SM] I read the last paragraph in the wifi section as an extension of the two previous paragraphs explicitly dealing with rfc8325, but I see that it can be considered an alternative. It might be helpful, it that paragraph is to be kept, to make it clear that this paragraph is applicable for non-rfc8325 compliant networks.
	That leaves still the question, whether the proposed EDCA change actually solves the issue (I hope that Greg has some data to support that). As well as the question how feasible that change would be for the APs deployed in the field already.

> There's recent relevant experience in what TSVWG went through to select a recommended DSCP for the LE PHB.  The network behavior (observed in the Internet) that was the primary cause of that conste…

	[SM] That seems to agree with what Ruediger Geib observed, an dscp intended to pass the existing internet probably needs to restrict itself to the "last" 3 bits of the dscp field. IMHO that would be an elegant solution that would also address the side-effects of NQB on non NQB-aware APs, requiring APs to actively opting-in into giving NQB a special treatment. It is also a solution that seems undesirable to Greg  if I understood correctly.

Sebastian

>>>> prioritization
>>>> since
>>>> prioritization
>> conferencing
>> be
>>>> with
>>>> can
>>>> WiFi-
>>>> four

---

From: Sebastian Moeller <[email-masked]>
Date: Sat, 9 Nov 2019 00:23:12 +0100

Hi David,

> On Nov 8, 2019, at 20:56, Black, David <[email-masked]> wrote:
> 
> Hi Greg,
> 
> That specific situation appears to be straightforward to address because the edge of the ISP network that supports Diffserv is involved.   Specifically, the specification of the NQB PHB ought to include text to the effect that outbound NQB-marked traffic MUST be rate limited at the egress from the Diffserv domain/region if the downstream (receiving) network is not known to support NQB (this is not the precise language, but should convey the concept).  

	[SM] I like this idea, I just wonder how that is going to work in the light of highly variable transmit rates on wifi links? IMHO AP & stations are in a better position to meaningfully rate limit than any upstream element.

> In the reverse direction rate limiting NQB traffic on ingress (or outright bleaching it to best effort if the subscriber should not be using NQB in the first place) seems like a good idea, and may rise to the level of a MUST requirement if the NQB-supporting  network that the traffic is entering does not implement traffic protection for the NQB "queue" at each network node.  With a little creativity, the necessary rate limiting might be able to take advantage of an NQB queue protection mechanism if one is present at the Diffserv edge.
> 
>> on a sane(r) policy.

---

From: "Black, David" <[email-masked]>
Date: Fri, 8 Nov 2019 23:43:12 +0000

Looks like progress - more inline ...

Thanks, --David

> Sent: Friday, November 8, 2019 6:23 PM
> To: Black, David
> > That specific situation appears to be straightforward to address because
> the edge of the ISP network that supports Diffserv is involved.   Specifically,
> the specification of the NQB PHB ought to include text to the effect that
> outbound NQB-marked traffic MUST be rate limited at the egress from the
> Diffserv domain/region if the downstream (receiving) network is not known
> to support NQB (this is not the precise language, but should convey the
> concept).
> 
> 	[SM] I like this idea, I just wonder how that is going to work in the
> light of highly variable transmit rates on wifi links? IMHO AP & stations are in
> a better position to meaningfully rate limit than any upstream element.

[David>] Apply a generous "fudge factor" so that the NQB rate limit is well short of any rate that could cause trouble.  My initial sense is that this NQB rate limit limit is a safety limit that does not have an optimization goal, so the rate can be set well short of transmission rates that have a reasonable possibility of causing trouble.  As part of, this, I'm hoping that there's limited downside to remarking more NQB traffic to Default (best effort) than necessary in this situation.  I understand that the WiFi AP/station would be a more effective location for this sort of functionality, but in this situation, we are able specify the functionality of the immediate upstream ISP element, but not the well-worn WiFi AP that the user bought on eBay last week.

I would leave configuration of NQB rate limits to network operators.  Also, in extremis, zero is always a safe NQB egress rate ;-), so would it help to require that the NQB egress rate be configurable to zero?

> 
> 
> > In the reverse direction rate limiting NQB traffic on ingress (or outright
> bleaching it to best effort if the subscriber should not be using NQB in the
> first place) seems like a good idea, and may rise to the level of a MUST
> requirement if the NQB-supporting  network that the traffic is entering does
> not implement traffic protection for the NQB "queue" at each network node.
> With a little creativity, the necessary rate limiting might be able to take
> advantage of an NQB queue protection mechanism if one is present at the
> Diffserv edge.
> >
> > As, at least for the home user, the result is only to damage her own WiFi
> network, particularly if the ISP ingress node protects its network from the
> user sending too much NQB-marked traffic.
> >
> > Thanks, --David
> >
> >>>>>>   Priority" which is then mapped to the four WMM Access
> Categories.
> >> In

---

From: Sebastian Moeller <[email-masked]>
Date: Sat, 9 Nov 2019 10:36:56 +0100

Hi David,

in short, I guess that would work for me (what ever that is worth), more below.

> On Nov 9, 2019, at 00:43, Black, David <[email-masked]> wrote:
> 

	[SM] That looks like reasonable compromise for everybody.

> I would leave configuration of NQB rate limits to network operators.  Also, in extremis, zero is always a safe NQB egress rate ;-), so would it help to require that the NQB egress rate be configura…

	[SM] That is also okay, as an enduser I can (and can be expected to) address my ISP if I have questions/issues with my link's configuration, so making sure the access network provider feels responsible for avoiding NQB flooding would be good.

Thanks
	Sebastian

---

From: Greg White <[email-masked]>
Date: Sat, 9 Nov 2019 19:02:03 +0000

David,

Thanks for these suggestions.  I agree that rate limiting aggregate NQB traffic could be an approach to address the concern.

It seems to me that this concern exists only for existing residential WiFi networks, which do not support the NQB PHB, are known to treat 0x2A as higher priority than the 0x1* and 0x0* DSCPs, and are unlikely to have other means of re-marking traffic before it hits the WiFi link.  For interconnections with another AS, the recommendations in Section 2.3.4.2 of RFC 2475 and Section 4.1 of RFC 2474 (unrecognized DSCPs) should be sufficient. 

On that basis, I think that any such text would be placed in the section on existing WiFi (which, in retrospect, I should not have put in the PHB "Use Cases" section of the draft, but rather as a separate "Interoperability ..." section, to avoid confusion).

Also, I think the remedies available in this situation include more than just rate limiting (and other remedies may be preferred in some cases), so I would not want to make it a MUST that rate limiting be employed.

I've taken a stab at some text below.

8. Interoperability with WiFi Networks

   WMM systems, by default, are configured to provide statistically prioritized channel access for the four Access Categories, with "Voice" being given highest priority, followed by "Video", "Best Effort" and "Background".  Since prioritization of NQB traffic over QB traffic is contrary to the requirements of the NQB PHB and could erode the principle of incentive alignment, care needs to be taken in introducing NQB-marked traffic into such networks.  One remedy is to configure the EDCA parameters for the Video Access Category to match those of the Best Effort Access Category, thus giving the two queues statistically equal access to the channel.  Another remedy is to limit the amount of traffic that is allowed to be marked as NQB, such as to ensure that it does not monopolize airtime to the detriment of QB traffic.   In situations where a network operator is introducing aggregate traffic into a network that is known or presumed to be utilizing WMM-enabled WiFi, the operator MUST employ a remedy to ensure that QB traffic is not disadvantaged.  

On 11/8/19, 4:43 PM, "Black, David" <[email-masked]> wrote:

    Thanks, --David

---

From: Sebastian Moeller <[email-masked]>
Date: Sat, 9 Nov 2019 22:01:50 +0100

Hi Greg,

more questions below.

> On Nov 9, 2019, at 20:02, Greg White <[email-masked]> wrote:
> 
> David,
> 
> It seems to me that this concern exists only for existing residential WiFi networks, which do not support the NQB PHB, are known to treat 0x2A as higher priority than the 0x1* and 0x0* DSCPs, and are unlikely to have other means of re-marking traffic before it hits the WiFi link.

	[SM] I am not sure whether this set only includes "residential WiFi networks", IMHO this should be true for the big majority of all wifi networks.

>  For interconnections with another AS, the recommendations in Section 2.3.4.2 of RFC 2475 and Section 4.1 of RFC 2474 (unrecognized DSCPs) should be sufficient. 
> 
>   WMM systems, by default, are configured to provide statistically prioritized channel access for the four Access Categories, with "Voice" being given highest priority, followed by "Video", "Best Effort" and "Background".  Since prioritization of NQB traffic over QB traffic is contrary to the requirements of the NQB PHB and could erode the principle of incentive alignment, care needs to be taken in introducing NQB-marked traffic into such networks.  One remedy is to configure the EDCA parameters for the Video Access Category to match those of the Best Effort Access Category, thus giving the two queues statistically equal access to the channel.

	[SM] I would very much like to see data that confirm that this idea actually works as intended in the real world. That is, that configuring the ACs as proposed will "isolate" the down-prioritized AC_VI traffic from the latency in the AC_BE queue and that AC are sufficiently well mutiplexed on transmit that neither starves the other and that neither AC gets too bursty transmissions (AC_BE should not care much, but NQB seems to be allergic to burstiness). I am confident you have such data, as otherwse you would not have proposed that, so please share it and ideally add it to the "Informative References" section.
	Also it seems worth adding to the paragraph that this modifies the assumptions of RFC8325 and why in this context this is justified.

>  Another remedy is to limit the amount of traffic that is allowed to be marked as NQB, such as to ensure that it does not monopolize airtime to the detriment of QB traffic.   In situations where a network operator is introducing aggregate traffic into a network that is known or presumed to be utilizing WMM-enabled WiFi

	[SM] Might make sense to turn this around, and require the implementation of remedies unless the network is known to use NQB-aware wifi, the numbers as far as I understand make it such, that basically any wifi network >= 802.11n will be using WMM by default... better safe than sorry.

> , the operator MUST employ a remedy to ensure that QB traffic is not disadvantaged.  

Best Regards
	Sebastian

---

From: Sebastian Moeller <[email-masked]>
Date: Sat, 9 Nov 2019 22:07:23 +0100

Hi Greg,

one more thought below.

>   WMM systems, by default, are configured to provide statistically prioritized channel access for the four Access Categories, with "Voice" being given highest priority, followed by "Video", "Best E…

	[SM] To be actionable this should be "the operator MUST employ one of the enumerated remedies to ensure that QB traffic is not disadvantaged" if other remedies appear the RFC should be amended or replaced.

Best Regards
	Sebastian

---

From: "Black, David" <[email-masked]>
Date: Mon, 11 Nov 2019 01:37:07 +0000

Greg,

I will look at the proposed text in more detail later - this is a quick response to say that I agree with the comments that precede the proposed text, and especially that I agree with this:

> Also, I think the remedies available in this situation include more than just
> rate limiting (and other remedies may be preferred in some cases), so I
> would not want to make it a MUST that rate limiting be employed.

I definitely agree that if there are multiple possible remedies, then it is better to apply the "MUST" to "solve the problem" as opposed to mandating the specific remedy of rate limiting.

Thanks, --David

> From: Greg White <[email-masked]>
> Sent: Saturday, November 9, 2019 2:02 PM
> To: Black, David
> Cc: tsvwg IETF list; Sebastian Moeller
> Thanks for these suggestions.  I agree that rate limiting aggregate NQB traffic
> could be an approach to address the concern.
> 
> It seems to me that this concern exists only for existing residential WiFi
> networks, which do not support the NQB PHB, are known to treat 0x2A as
> higher priority than the 0x1* and 0x0* DSCPs, and are unlikely to have other
> means of re-marking traffic before it hits the WiFi link.  For interconnections
> with another AS, the recommendations in Section 2.3.4.2 of RFC 2475 and
> Section 4.1 of RFC 2474 (unrecognized DSCPs) should be sufficient.
> 
> On that basis, I think that any such text would be placed in the section on
> existing WiFi (which, in retrospect, I should not have put in the PHB "Use
> Cases" section of the draft, but rather as a separate "Interoperability ..."
> section, to avoid confusion).
> 
> Also, I think the remedies available in this situation include more than just
> rate limiting (and other remedies may be preferred in some cases), so I
> would not want to make it a MUST that rate limiting be employed.
> 
>    WMM systems, by default, are configured to provide statistically prioritized
> channel access for the four Access Categories, with "Voice" being given
> highest priority, followed by "Video", "Best Effort" and "Background".  Since
> prioritization of NQB traffic over QB traffic is contrary to the requirements of
> the NQB PHB and could erode the principle of incentive alignment, care
> needs to be taken in introducing NQB-marked traffic into such networks.
> One remedy is to configure the EDCA parameters for the Video Access
> Category to match those of the Best Effort Access Category, thus giving the
> two queues statistically equal access to the channel.  Another remedy is to
> limit the amount of traffic that is allowed to be marked as NQB, such as to
> ensure that it does not monopolize airtime to the detriment of QB traffic.   In
> situations where a network operator is introducing aggregate traffic into a
> network that is known or presumed to be utilizing WMM-enabled WiFi, the
> operator MUST employ a remedy to ensure that QB traffic is not
> disadvantaged.
> 
> 
> 
> 
> 
> 
> 
> 
> 
>     > > Backing up a few messages, I might have found a way out of this
> debate.
>     > Sebastian wrote:
>     > >
>     [David>] Apply a generous "fudge factor" so that the NQB rate limit is well
> short of any rate that could cause trouble.  My initial sense is that this NQB
> rate limit limit is a safety limit that does not have an optimization goal, so the
> rate can be set well short of transmission rates that have a reasonable
> possibility of causing trouble.  As part of, this, I'm hoping that there's limited
> downside to remarking more NQB traffic to Default (best effort) than
> necessary in this situation.  I understand that the WiFi AP/station would be a
> more effective location for this sort of functionality, but in this situation, we
> are able specify the functionality of the immediate upstream ISP element,
> but not the well-worn WiFi AP that the user bought on eBay last week.
> 
>     I would leave configuration of NQB rate limits to network operators.  Also,
> in extremis, zero is always a safe NQB egress rate ;-), so would it help to
> require that the NQB egress rate be configurable to zero?
> 
>     >
>     >
>     > > The individual sender situation appears to be of less concern, as at least
> in
>     > this case it looks like an instance of:
>     > >
>     > >> paragraph like that which exists in RFC 8325 that explains why, in the
> case
>     > of
>     > >> ground. And my point is very much to give my best arguments to
> make
>     > sure
>     > >> you do not end up writing a bad policy into an RFC. What ever you do
> in
>     > the
>     > >> reason why non-NQB on-line gaming starts to suck. But really looking
> at
>     > the
>     > >> AC stats from my laptop:
>     > >>
>     > >> application today that sends bulk traffic marked as CS7 (a value that
> the
>     > IETF
>     > >> you propose to change that in a major way, with your attempt at
> making
>     > NQB
>     > >> end to end (with one end potentially being in a close data center with
> an
>     > SLA
>     > >> allowing for NQB survival). Just because no one has massively abused
> this
>     > so
>     > >> using 0x2A for NQB traffic, and it does *nothing* to help solve the
> main
>     > issue
>     > >> skype and ssh applications to even use AC_VO I can control their
> activity
>     > and
>     > >> usage much better than I can traffic rushing in from the internet). Sure
> I
>     > can
>     > >> draft proposing a technology that will holistically protect WiFi
> networks
>     > from
>     > >> inside one. Here, I am not concerned so much in fixing all wifi AC
> abuse
>     > and
>     > >> unfortunate prioritization scheme in conjunction with your intended
> use
>     > of
>     > >> the NQB dscp. Me shutting up, would not change the underlaying
> facts
>     > that
>     > >> marked NQB are no more bandwidth intensive than video
> conferencing
>     > (the
>     > >> guys are doing it too" is not the best of defenses IMHO). I realize that
> this
>     > is
>     > >> an issue for you as you explicitly target NQB as requiring no
> prioritization
>     > or
>     > >>>>     excessive amounts of downstream traffic were marked/mapped
> to
>     > >> these
>     > >> of > AC_BE traffic is acceptable. So very much incompatible with your
> goal
>     > of
>     > >> having endpoints set the NQB dscp based on their own best
> assessment
>     > of
>     > >> AQMs have sufficient knowledge to judge what traffic rate is
> acceptable
>     > for
>     > >> of recommended maximal fractions of the achievable rate each AC
> should
>     > be
>     > >> constrained to.
>     > >>>>
>     > >>>>> 	[SM] I agree the question is how to deal with that
> "impedance
>     > >> mismatch".
>     > >>>>>
>     > >> resulting air-time access advantage (which results in both lower
> latency
>     > and
>     > >> treat that NQB-codepoint however they want. If for example a
> priority
>     > boost
>     > >> is desired such an AP can easily implement the required rate-limiting
> so
>     > that
>     > >> this be made more explicit? This is orthogonal to the question
> whether
>     > such
>     > >> be interpreted as recommending that high-data-rate traffic be
> marked
>     > NQB.
>     > >>>>>
>     > >> correct), I think the draft currently recommends that NQB only be
> used
>     > for
>     > >>>>>>   Differentiated Services-Compliant Nodes as described in
> Section 4
>     > >> of
>     > >>>>>>   Systems that utilize [RFC8325], SHOULD map the NQB codepoint
> to
>     > >> UP_5
>     > >>>>>>   configure the EDCA parameters for the Video Access Category
> to
>     > >> match
>     > >> with EDCA parameters that match the AC_BE parameters, AC_VI
> ceases
>     > to
>     > >>>>>> Especially since essentially none of the millions deployed WiFi
> APs
>     > out
>     > >> consumer APs I know actually allow to easily adjust EDCA parameters
> at
>     > all. I
>     > >> four available queues by design have different priorities, and by
> moving
>     > NQB
>     > >> out of the default AC_BE while leaving QB flows in there, this
> effectively
>     > runs

---

From: "Black, David" <[email-masked]>
Date: Mon, 11 Nov 2019 23:53:07 +0000

At the bottom ...

Thanks, --David

> Sent: Saturday, November 9, 2019 4:07 PM
> To: Greg White
> networks, which do not support the NQB PHB, are known to treat 0x2A as higher
> priority than the 0x1* and 0x0* DSCPs, and are unlikely to have other means of
> re-marking traffic before it hits the WiFi link.  For interconnections with another
> AS, the recommendations in Section 2.3.4.2 of RFC 2475 and Section 4.1 of RFC
> 2474 (unrecognized DSCPs) should be sufficient.
> >
> existing WiFi (which, in retrospect, I should not have put in the PHB "Use Cases"
> section of the draft, but rather as a separate "Interoperability ..." section, to
> avoid confusion).
> >
> > Also, I think the remedies available in this situation include more than just rate
> limiting (and other remedies may be preferred in some cases), so I would not
> want to make it a MUST that rate limiting be employed.
> >
> channel access for the four Access Categories, with "Voice" being given highest
> priority, followed by "Video", "Best Effort" and "Background".  Since
> the NQB PHB and could erode the principle of incentive alignment, care needs to
> be taken in introducing NQB-marked traffic into such networks.  One remedy is
> to configure the EDCA parameters for the Video Access Category to match
> those of the Best Effort Access Category, thus giving the two queues statistically
> equal access to the channel.  Another remedy is to limit the amount of traffic
> that is allowed to be marked as NQB, such as to ensure that it does not
> monopolize airtime to the detriment of QB traffic.   In situations where a
> network operator is introducing aggregate traffic into a network that is known
> or presumed to be utilizing WMM-enabled WiFi, the operator MUST employ a
> remedy to ensure that QB traffic is not disadvantaged.
> 
> 	[SM] To be actionable this should be "the operator MUST employ one of
> the enumerated remedies to ensure that QB traffic is not disadvantaged" if
> other remedies appear the RFC should be amended or replaced.
> 
> Best Regards
> 	Sebastian
> 
[David>] This text is "digging in the right place" but could use some additional editing.

The mention of EDCA parameters implies that "the operator" is the operator of the WiFi network, so that implied context carries over to the next sentence about limiting traffic that is marked as NQB.  That leaves the final sentence in an odd position because it's about the situation where "the operator" is not the operator of the WiFi network, but rather of an adjacent network.  I suggest moving the final sentence into a separate paragraph, adding that context, and adding the example that we've been discussing, e.g., imposing a suitable rate limit on NQB traffic introduced into the WiFi network.   Turning to the equipment providers, what's the corresponding "MUST implement" requirement for that equipment - i.e., what has to be implemented in the edge network element in order to ensure that the operator can control NQB traffic, e.g., via rate limiting?

> short of any rate that could cause trouble.  My initial sense is that this NQB rate
> limit limit is a safety limit that does not have an optimization goal, so the rate
> can be set well short of transmission rates that have a reasonable possibility of
> causing trouble.  As part of, this, I'm hoping that there's limited downside to
> remarking more NQB traffic to Default (best effort) than necessary in this
> situation.  I understand that the WiFi AP/station would be a more effective
> location for this sort of functionality, but in this situation, we are able specify
> the functionality of the immediate upstream ISP element, but not the well-worn
> WiFi AP that the user bought on eBay last week.
> >
> >    I would leave configuration of NQB rate limits to network operators.  Also, in
> extremis, zero is always a safe NQB egress rate ;-), so would it help to require
> that the NQB egress rate be configurable to zero?
> >
> >>
> >>

---

From: Greg White <[email-masked]>
Date: Tue, 12 Nov 2019 01:16:22 +0000

Ok, I see your point.   The context for the MUST needs to be a bit more specific.  The MUST would only apply in the case that the "network operator" in question is introducing aggregate traffic into "someone else's" WiFi network, where that someone else doesn’t have the ability to support the NQB PHB (either via new software in their AP, or via EDCA parameter changes) and doesn't have the ability to apply the RFC2474 or RFC2475 functions (re-mark NQB or treat it as default).

In terms of equipment requirements, it seems to me that this could be implemented as part of the "traffic protection" mechanism in an upstream device, or it could be implemented further back in the operator's network in either flow-aware or flow-blind ways. Because of this, and also because the MUST is only true in certain deployment contexts, I'm not sure that it is correct to mandate that a particular device (let alone a device that itself supports the NQB PHB) be burdened with specific mandatory requirements here.  I think it is sufficient to require that the operator handle this situation appropriately.

How about the following for the new text:

WMM systems, by default, are configured to provide statistically prioritized channel access for the four Access Categories, with "Voice" being given highest priority, followed by "Video", "Best Effort" and "Background".  Since prioritization of NQB traffic over QB traffic is contrary to the requirements of the NQB PHB and could erode the principle of incentive alignment, care needs to be taken in introducing NQB-marked traffic into such networks.  One remedy is to configure the EDCA parameters for the Video Access Category to match those of the Best Effort Access Category, thus giving the two queues statistically equal access to the channel.  Another remedy is to limit the amount of traffic that is allowed to be marked as NQB, such as to ensure that it does not monopolize airtime to the detriment of QB traffic.   

In situations where a network operator is introducing aggregate traffic into network outside of their control (e.g. a user's home network) that is known or presumed to be utilizing non-NQB-aware, WMM-enabled WiFi, and where the receiving network does not have the ability to re-mark traffic or adjust the mapping of NQB traffic to WMM Access Category, the operator MUST employ a remedy to ensure that QB traffic is not disadvantaged. 

On 11/11/19, 4:53 PM, "Black, David" <[email-masked]> wrote:

    At the bottom ...
    
    Thanks, --David

---

From: "Black, David" <[email-masked]>
Date: Tue, 12 Nov 2019 05:38:58 +0000

Inline ...

Thanks, --David

> Sent: Monday, November 11, 2019 8:16 PM
> To: Black, David; Sebastian Moeller
> Cc: tsvwg IETF list
> Ok, I see your point.   The context for the MUST needs to be a bit more specific.
> The MUST would only apply in the case that the "network operator" in question
> is introducing aggregate traffic into "someone else's" WiFi network, where that
> someone else doesn’t have the ability to support the NQB PHB (either via new
> software in their AP, or via EDCA parameter changes) and doesn't have the
> ability to apply the RFC2474 or RFC2475 functions (re-mark NQB or treat it as
> default).

[David>] Yes, that needs to be explained at about that level of detail.
> 
> In terms of equipment requirements, it seems to me that this could be
> implemented as part of the "traffic protection" mechanism in an upstream
> device, or it could be implemented further back in the operator's network in
> either flow-aware or flow-blind ways. Because of this, and also because the
> MUST is only true in certain deployment contexts, I'm not sure that it is correct
> to mandate that a particular device (let alone a device that itself supports the
> NQB PHB) be burdened with specific mandatory requirements here.  I think it is
> sufficient to require that the operator handle this situation appropriately.

[David>] Need to ensure that the tools are available to the operator who wants to do that.  The "MUST implement" requirement is about ensuring that the operator has the tools available.
> monopolize airtime to the detriment of QB traffic.
> 
> In situations where a network operator is introducing aggregate traffic into
> network outside of their control (e.g. a user's home network) that is known or
> presumed to be utilizing non-NQB-aware, WMM-enabled WiFi, and where the
> receiving network does not have the ability to re-mark traffic or adjust the
> mapping of NQB traffic to WMM Access Category, the operator MUST employ a

[David>] The problem is that this "MUST" is almost meaningless, because "a remedy" and "not disadvantaged" are indistinct terms.  The latter can be explained elsewhere, as it's part of the PHB behavior, and referenced from here.   For the former, I think rate limiting needs to be mentioned here, and in order to ensure that this tool is available to operators, a "MUST implement" requirement to rate limit outbound NQB traffic on any port that may exit a Diffserv domain or region appears to be in order..
> higher
> Cases"
> rate
> highest
> needs to
>     The mention of EDCA parameters implies that "the operator" is the operator
> of the WiFi network, so that implied context carries over to the next sentence
> about limiting traffic that is marked as NQB.  That leaves the final sentence in an
> odd position because it's about the situation where "the operator" is not the
> operator of the WiFi network, but rather of an adjacent network.  I suggest
> moving the final sentence into a separate paragraph, adding that context, and
> adding the example that we've been discussing, e.g., imposing a suitable rate
> limit on NQB traffic introduced into the WiFi network.   Turning to the
> equipment providers, what's the corresponding "MUST implement" requirement
> for that equipment - i.e., what has to be implemented in the edge network
> element in order to ensure that the operator can control NQB traffic, e.g., via
> rate limiting?
> 
>     >
>     > >
>     > >
>     > >
>     > >
>     > >
>     > >
>     > >
>     > >
>     > >
> rate
>     > >>> 	If you point the gun at your own foot and pull the trigger, do
> not ask
>     > >> where the hole in your foot came from.
>     > >>>
>     > >>>>>>>>  Differentiated Services-Compliant Nodes as described in Section
> 4
>     > >>>> of

---

From: Sebastian Moeller <[email-masked]>
Date: Tue, 12 Nov 2019 08:31:04 +0100

Hi Greg, David,

see more in-line.

> On Nov 12, 2019, at 06:38, Black, David <[email-masked]> wrote:
> 
> Inline ...
> 
> Thanks, --David
> 

	[SM] I think we all agree, that in spite of the word "only' the enumerated conditions basically encompass all home wifi networks on the planet. So again, would it not better reflect reality to require the must "unless the downstream WiFi network supports the NGQ PHB or re-maps NQB to something that maps into AC_BE"? BTW, hostapd allows so called qos_maps which which the administrator can over-ride the default DSCP to AC mappings for AP (and as it appears even for STAs) but that to my knowledge is not exposed in any AP (and in OpenWrt it is reported to not work).

> [David>] Yes, that needs to be explained at about that level of detail.

	[SM] I still would like to see data that shows that the relative intrusive EDCA changes actually solve Greg's problem in real world environments. I agree that in theory it should help, but in practice this might not be true. I am convinced that this was tested before adding it to the rfc draft, so it should be relative simple to at least show anecdotal evidence that this solves the problem.

> [David>] Need to ensure that the tools are available to the operator who wants to do that.  The "MUST implement" requirement is about ensuring that the operator has the tools available.

	[SM] How about simple language like "under these [enumerated] conditions enforcment of downstream protections (just as stand-in for the correct description) MUST be performed before handing traffic to the downstream network"?

>> remedy to ensure that QB traffic is not disadvantaged.

	[SM] as above, how about turning this around from "if enumerated set of conditions apply the operator MUST" to "the operator MUST, unless enumerated set of conditions that remove the susceptibility of the downstream network to potential NQB side-effects"?

Sebastian

---

From: Greg White <[email-masked]>
Date: Thu, 14 Nov 2019 00:51:07 +0000

Ok, how about:

In situations where a network operator is introducing aggregate traffic into
network outside of their control (e.g. a user's home network) that is known or
presumed to be utilizing non-NQB-aware, WMM-enabled WiFi, and where the
receiving network does not have the ability to re-mark traffic or adjust the
mapping of NQB traffic to WMM Access Category, the operator MUST 
ensure that the rate of NQB traffic is controlled so as to prevent it from 
monopolizing airtime to the detriment of QB traffic.

I wrote "controlled" instead of "limited" since "rate limited" to me gives the impression of a traditional rate limiter (such as token bucket), whereas in this case I think it is good to leave options open for more sophisticated solutions.  For example, if the operator can identify a category of "non-sparse" flows that have marked themselves as NQB, while the remaining sparse NQB traffic (in aggregate) amounts to only 2 Mbps, then simply detecting the non-sparse flows and re-marking them as Default would be sufficient.

I understand your interest in ensuring that there are tools available to do this, but since this rate control function is only needed in certain scenarios, and even in those scenarios could be implemented in equipment other than the devices that implement the PHB (perhaps even in software written by the ISP themselves) I don’t think it works to add it as a mandatory requirement on NQB PHB equipment.  

Also, if I were an ISP, I would want to observe that a problem actually exists before I start investing in remedies.   This requirement is predicated on a belief of Sebastian's that may or may not come true in reality.  

-Greg

On 11/11/19, 10:39 PM, "Black, David" <[email-masked]> wrote:

    Inline ...
    
    Thanks, --David

---

From: "Black, David" <[email-masked]>
Date: Thu, 14 Nov 2019 04:12:23 +0000

Hi Greg,

The use of "controlled" instead of "rate limited" in the proposed text seems fine to me.  However, I think there's still have a problem in ensuring that the operator has functionality available to meet that "operator MUST ensure" requirement in that text.   I do understand this ... 

> Also, if I were an ISP, I would want to observe that a problem actually exists
> before I start investing in remedies.   This requirement is predicated on a belief
> of Sebastian's that may or may not come true in reality.

... but what's the operator supposed to do in the time period between when the customer calls to complain and when the new equipment can be ordered, delivered and installed?  I would agree with your view that a blanket "MUST" requirement on all equipment that supports the NQB PHB is probably overkill, but I suspect that an operator who does not want to invest in remedies until the problem is observed also does not want to invest in rolling trucks if the problem is observed ;-).

One simple (perhaps too simple?) approach would be to require that if the NQB PHB is supported on equipment that could be connected to the sort of WiFi network described, then any interface that could be connected to such a WiFi network MUST be configurable (by the operator) to remark all NQB traffic to Default (zero DSCP), as zero is a known-to-be-safe NQB PHB rate in this scenario.  For a cable network, I think the "could be connected" provision would exempt all head-end equipment, which should reduce the impact.  But (as noted) this approach may be too simple - what would you suggest?

Thanks, --David

> Sent: Wednesday, November 13, 2019 7:51 PM
> To: Black, David
> Cc: tsvwg IETF list
> I wrote "controlled" instead of "limited" since "rate limited" to me gives the
> impression of a traditional rate limiter (such as token bucket), whereas in this
> case I think it is good to leave options open for more sophisticated solutions.
> For example, if the operator can identify a category of "non-sparse" flows that
> have marked themselves as NQB, while the remaining sparse NQB traffic (in
> aggregate) amounts to only 2 Mbps, then simply detecting the non-sparse flows
> and re-marking them as Default would be sufficient.
> 
> I understand your interest in ensuring that there are tools available to do this,
> but since this rate control function is only needed in certain scenarios, and even
> in those scenarios could be implemented in equipment other than the devices
> that implement the PHB (perhaps even in software written by the ISP
> themselves) I don’t think it works to add it as a mandatory requirement on NQB
> PHB equipment.
> 
> Also, if I were an ISP, I would want to observe that a problem actually exists
> before I start investing in remedies.   This requirement is predicated on a belief
> of Sebastian's that may or may not come true in reality.
> 
> -Greg
> 
> 
> 
>     [David>] Need to ensure that the tools are available to the operator who
> wants to do that.  The "MUST implement" requirement is about ensuring that
> the operator has the tools available.
>     >
>     >
> employ a
>     [David>] The problem is that this "MUST" is almost meaningless, because "a
> remedy" and "not disadvantaged" are indistinct terms.  The latter can be
> explained elsewhere, as it's part of the PHB behavior, and referenced from here.
> For the former, I think rate limiting needs to be mentioned here, and in order to
> ensure that this tool is available to operators, a "MUST implement" requirement
> to rate limit outbound NQB traffic on any port that may exit a Diffserv domain
> or region appears to be in order..
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >     > > Thanks for these suggestions.  I agree that rate limiting aggregate
> NQB
>     > traffic
>     >     > priority than the 0x1* and 0x0* DSCPs, and are unlikely to have other
> means
>     > of
>     >     > AS, the recommendations in Section 2.3.4.2 of RFC 2475 and Section 4.1
> of
>     > RFC
>     >     > prioritization of NQB traffic over QB traffic is contrary to the
> requirements
>     > of
>     >     > be taken in introducing NQB-marked traffic into such networks.  One
> remedy
>     > is
>     >     > or presumed to be utilizing WMM-enabled WiFi, the operator MUST
> employ
>     > a
>     >     [David>] This text is "digging in the right place" but could use some
> additional
>     > editing.
>     >
>     >     > >>>> but about the "NQB/L4S complex" that I expect to cause a lot of
> NQB
>     >     > marked
>     >     > >> outbound NQB-marked traffic MUST be rate limited at the egress
> from
>     > the
>     >     > >> light of highly variable transmit rates on wifi links? IMHO AP &
> stations
>     > are in
>     >     > >    [David>] Apply a generous "fudge factor" so that the NQB rate limit
> is
>     > well
>     >     > can be set well short of transmission rates that have a reasonable
> possibility
>     > of
>     >     > the functionality of the immediate upstream ISP element, but not the
> well-
>     > worn
>     >     > >> requirement if the NQB-supporting  network that the traffic is
> entering
>     > does
>     >     > >> not implement traffic protection for the NQB "queue" at each
> network
>     > node.
>     >     > >> advantage of an NQB queue protection mechanism if one is present
> at
>     > the
>     >     > >> Diffserv edge.
>     >     > >>>
>     >     > >>>> If the policy that gets written into the RFC is that NQB traffic
> should
>     > not be
>     >     > >>>> high data rate traffic, then this achieves your objective?  If we
> include
>     > a
>     >     > >>>> in having a sane policy.  This IETF draft does not create that
> interest,
>     > nor
>     >     > >>>> but about the "NQB/L4S complex" that I expect to cause a lot of
> NQB
>     >     > >> marked
>     >     > >>>> variable bitrates on a wifi segment, hence the wifi elements AP
> (and
>     >     > >> ideally
>     >     > >>>> STAs) will need to enforce sanity and make sure tp avoid
> starvation.
>     > This is
>     >     > >>>> not a new requirement, but the status quo is that most traffic is
> AC_BE,
>     > so
>     >     > >>>> the lack of enforcement was sort of tolerable; but either NQB
> withers
>     >     > >> away
>     >     > >>>> and will not be used (and all of this discussion does not matter) or
> it
>     > will be
>     >     > >>>> used and then you better make sure that NQB will not be found out
> as
>     > a
>     >     > >>>>   root@router:~# cat
> /sys/kernel/debug/ieee80211/phy1/ath9k/xmit
>     >     > >>>>                               BE         BK        VI        VO
>     >     > >>>>
>     >     > >>>>>> On Nov 7, 2019, at 23:44, Greg White
> <[email-masked]>
>     >     > wrote:
>     >     > >>>>>>
>     >     > >>>>>> Sebastian,
>     >     > >>>>>>
>     >     > >>>>>> I believe that the reason that RFC 8325 simply wrings its hands
> over
>     > this
>     >     > >>>> issue, as opposed to solving it, is that A) it is a *really* hard
> problem to
>     >     > >> solve
>     >     > >>>> as there is no problem is neither solid science nor engineering. If
> you
>     > have
>     >     > >>>> rates with the NQB marking, please feel free to post them to the
> list or
>     > as
>     >     > >>>> PM.
>     >     > >>>>>
>     >     > >>>>>>
>     >     > >>>>>>
>     >     > >>>> prevent an application from using 0x2A (or any of the other 31
> code
>     > points
>     >     > >>>> developer sees fit, it does *nothing* to prevent a network
> operator
>     > from
>     >     > >>>> on a sane(r) policy. Most users and applications do not bother
> paying
>     > with
>     >     > >>>> dscps so the current amount of abuse is limited (and if I configure
> my
>     >     > >> internal
>     >     > >>>> re-map 0x2A to a sane value on ingress to my network, but that is
> not
>     >     > >> going
>     >     > >>>> to help that much if my neighbors do not do this, and their APs
> start
>     >     > >> hogging
>     >     > >>>>>> If you want to solve this problem, my suggestion is that you start
> a
>     > new
>     >     > >>>>>>> On Nov 7, 2019, at 22:11, Greg White
> <[email-masked]>
>     >     > >>>> wrote:
>     >     > >>>>>>>
>     >     > >>>>>>> Sebastian,
>     >     > >>>>>>>
>     >     > >>>> road to understanding and accepting the properties and limitations
> of
>     >     > >> wifi's
>     >     > >>>>>>> I think you summarized your position as: "To be explicit, I do
> not
>     >     > >> object
>     >     > >>>> significantly into the tx_ops for AC_BE, the current draft improves
> in
>     > that
>     >     > >>>>>>> In my view, as long as the applications that we're
> recommending to
>     > be
>     >     > >>>> applications that the IETF already recommends be marked with a
> DSCP
>     >     > >> that
>     >     > >>>> conferencing" is virtually meaningless as it will give very little
> guidance
>     > on
>     >     > >>>> bandwidth (yes rfc8325 is also pretty silent on this, but "look mum,
> the
>     >     > >> other
>     >     > >>>> propose to use a prioritization system you really really should
> require
>     >     > >> rate-
>     >     > >>>> limiting.
>     >     > >>>>>>
>     >     > >>>>>> rfc8325, section 8.2:
>     >     > >>>>>>    excessive amounts of downstream traffic were
> marked/mapped to
>     >     > >>>> these
>     >     > >>>>>>    malicious user could cause WLAN DoS by flooding traffic
> marked
>     > CS7
>     >     > >>>>>>    Category (AC_VO).  Such a flood could cause Denial-of-Service
> to
>     > not
>     >     > >>>>>>    client operating system) could cause not only WLAN DoS, but
> also
>     > IP
>     >     > >>>>>> To me this clearly indicates that the achievable wifi rate betwnn
> AP
>     > and
>     >     > >>>> each station needs to be taken into account when considering
> which
>     >     > >> fraction
>     >     > >>>> traffic type without some sanitization at the AP level (only the AP
> will
>     >     > >> have a
>     >     > >>>> following both the principle of least surprise and a "first, do no
> harm"
>     >     > >> maxim
>     >     > >>>> mappings keep NQB marked traffic in the AC_BE queue, UNLESS
> the AP
>     > is
>     >     > >>>>>> The amount of back and forth seems to indicate that this is not
> an
>     >     > >>>> outcome you consider desirable.
>     >     > >>>>>>
>     >     > >>>>>>
>     >     > >>>>>> Sebastian
>     >     > >>>>>>
>     >     > >>>>>>>
>     >     > >>>>>>> -Greg
>     >     > >>>>>>>
>     >     > >>>>>>>
>     >     > >>>>>>>
>     >     > >>>>>>>
>     >     > >>>>>>>
>     >     > >>>>>>> On 11/5/19, 1:58 AM, "Sebastian Moeller"
> <[email-masked]>
>     >     > >> wrote:
>     >     > >>>>>>>
>     >     > >>>>>>> Hi Greg,
>     >     > >>>>>>>
>     >     > >>>>>>>
>     >     > >>>>>>>> On Nov 5, 2019, at 01:28, Greg White
> <[email-masked]>
>     >     > >>>> wrote:
>     >     > >>>>>>>>
>     >     > >>>>>>>> Hi Sebastian,
>     >     > >>>>>>>>
>     >     > >>>> since WiFi latency can be considerable. By default, many existing
> APs
>     > only
>     >     > >>>>>>> 	[SM] Unless you opt for selecting AC_BK for the NQB
> traffic, for
>     >     > most
>     >     > >>>> users the value of NQB will be mostly in the priority boost on wifi
> and
>     > the
>     >     > >>>>>>> 	[SM] Sure, I am concerned about the status quo wich
> does not
>     >     > entail
>     >     > >>>> "proper configuration and/or policies", and hence I believe the
> NQB
>     >     > >> special
>     >     > >>>> proposal to use a code point that by default is mapped to AC_BK is
> the
>     >     > >> only
>     >     > >>>> correct solution (as a bonus it seems that such a code point also
> has a
>     >     > >> better
>     >     > >>>> is desired such an AP can easily implement the required rate-
> limiting so
>     >     > >> that
>     >     > >>>> it any more (not necessarily a deal-breaker but certainly
> unexpected
>     >     > >> enough
>     >     > >>>> on WiFi links, and will almost certainly select a DSCP in practice
> that
>     >     > >> achieves
>     >     > >>>> that goal.
>     >     > >>>>>>>
>     >     > >>>> AC_VI approach, I expect that very quickly a lot of traffic will utilize
> the
>     >     > >> AC_VI
>     >     > >>>>>>> 	[SM] Sure, but is that really a good justification for
> proposing a
>     >     > DSCP
>     >     > >>>> conferencing applications mark their traffic as either AF4x or CS4,
> all of
>     >     > >> which
>     >     > >>>>>>> 	[SM] as an implementer I read "relatively low data
> rates",
>     >     > without
>     >     > >>>> further guidance I have very little intuition what to use as
> reference.
>     >     > >> Could
>     >     > >>>>>>> 	[SM] Thanks, as long as the aggregate NQB traffic is
> relative
>     >     > sparse
>     >     > >>>> compared to the available WiFi bandwidth (or the number of
> tx_ops)
>     >     > >> most of
>     >     > >>>> significantly into the tx_ops for AC_BE, the current draft improves
> in
>     > that
>     >     > >>>> "interactive voice and video" as an example). Aside from this
> (which I
>     > can
>     >     > >>>> sparse traffic.  That said, the section where this guidance is
> intended to
>     > be
>     >     > >>>> given is still lacking in specificity, and poses some open questions
> that
>     > may
>     >     > >>>>>>> 	[SM] Sounds great. Now this then cycles back to one of
> the
>     >     > other
>     >     > >>>> open topics, "enforcement". Ideally NQB-aware APs should
> monitor
>     > both
>     >     > >>>>>>>>  either four or eight transmit queues and four sets of
> associated
>     >     > >>>> EDCA
> Section
>     >     > >>>>>>>>  [RFC2475].  As a result this document discusses
> interoperability
>     > with
>     >     > >>>>>>>>  separate queue from QB traffic in existing WiFi equipment,
> the
>     >     > >>>> 0x2A
>     >     > >>>>>>>>  codepoint is preferred for NQB.  This would map NQB to
> UP_5
>     >     > >>>> which is
>     >     > >>>>>>>>  configure the EDCA parameters for the Video Access
> Category to
>     >     > >>>> match
>     >     > >>>> there will a) have this configured like proposed already and b) none
> of
>     > the
>     >     > >>>>>>>> I do not want to sound alarmist, but given the number of
> cable-
>     > ISP
>     >     > >>>> airtime seems the prudent thing to do. If there are sufficient
> backstops
>     > in
>     >     > >>>> place (like rate limiting or automatic down-marking if the traffic is
> not
>     >     > >> sparse
>     >     > >>>>>>>> The text probably should also openly discuss that in
> WiFi/WMM
>     > the
>     >     > >>>> against  the following text in the draft: "The NQB queue SHOULD
> be
>     > given

---

From: Greg White <[email-masked]>
Date: Thu, 14 Nov 2019 06:09:22 +0000

Thanks David, see [GW] inline.

On 11/13/19, 9:12 PM, "Black, David" <[email-masked]> wrote:

    Hi Greg,

    

[GW] An operator could monitor traffic volumes using standard counters to understand the likelihood of a problem occurring, and then presumably (though not assuredly) have a bit of lead time to work on remedies if need be.

[GW] Actually, that functionality exists today in cable equipment, so my constituents shouldn't have a problem with it being a requirement here.  I suppose ISPs (or their equipment suppliers) that don't deploy cable equipment would need to weigh in if they find this to be objectionable.  I'm not as familiar with OLT and BRAS capabilities.  Unless I hear objections, I will go ahead and add that requirement.

    Thanks, --David

---

From: Sebastian Moeller <[email-masked]>
Date: Thu, 14 Nov 2019 09:14:40 +0100

Hi Greg,

More below in line.

> On Nov 14, 2019, at 01:51, Greg White <[email-masked]> wrote:
> 
> Ok, how about:
> 

	[SM] I still believe that traffic control should be the default and not doing this should be phrased as the exception with a list of conditions needed for the exception to become valid. This is simply based on the fact that the fraction of wifi networks out there equiped to gracefully handle the proposed PHB approaches zeros. But this is the last time I mention this.

> I wrote "controlled" instead of "limited" since "rate limited" to me gives the impression of a traditional rate limiter (such as token bucket), whereas in this case I think it is good to leave opti…

	[SM] IMHO this seems covered in David's proposal, since the amount of NQB traffic admitted in the downstream network still is rate limited, is is not that rate limiting on a specific DSCP required dropping of overlimit packets, no? I thought "policing" would imply that over-limit packets need to be dropped, but if "limiting" has the same implication sure, but it might be good to give add your example above to the draft?

> 
> I understand your interest in ensuring that there are tools available to do this, but since this rate control function is only needed in certain scenarios,

	[SM] Currently, and for the foreseeable future, certain scenarios denotes the vast majority of all wifi networks on this planet. Effectively rate controll will NOT be needed in a much more limited set of scenarios and networks. The RFC does not need to accept that, but that is the reality in the field...

> and even in those scenarios could be implemented in equipment other than the devices that implement the PHB (perhaps even in software written by the ISP themselves) I don’t think it works to add it as a mandatory requirement on NQB PHB equipment.

	[SM] I am with David, as you know, if you pass a loaded gun to the internet community, at least make sure the gun has a safety switch...

>  
> 
> Also, if I were an ISP, I would want to observe that a problem actually exists before I start investing in remedies.

	[SM] Could you please explain, how this is realistically feasible? I hope you agree that the vast maority of wifi networks are end-user managed, so how does an ISP even know there is a wifi network connected at the end let alone how it is configured or that there are starvation issues? You could argue that user will complain to their ISP, but why would they complain to the ISP if their wifi network misbehaves (unless the ISP supplied the wifi router, but then the ISP knows about the capabilities)? And honestly, I had thought it would be an onus of the author of an RFC to make sure that following the RFC will not lead to situations where invasion into end-user wifi network becomes an ISPs responsibility...

>   This requirement is predicated on a belief of Sebastian's that may or may not come true in reality.  

	[SM] Well, I ran flent's rrul_cs8 test over my local wifi network to confirm that AC_VO andvAC_VI traffic effectively preempts/starves Ac_BE traffic, so the fact that there is potential for starvation is proven, or do you disagree? 

	Also the fact that in wifi as a shared medium all APs on the same channel need to share airtime, and that such misuse of higher ACs has effects outside of the local network applying/accepting the marking should not be contentious?
	
	So I hope we all agree that my basic analysis that the proposed wifi behaviour is not side-effect free and care needs to be taken to not give NQB traffic an undeserved unfair advantage.
	
	So care to explain how, my concern that NQB traffic might starve/slow down to a trickle all other traffic unless properly managed is a "belief"? IMHI it is a pretty conservative hypothesis based on theoretical considerations and actual experimental data.

	Speaking of experimental data, I have now asked multiple times for data showing that the proposed EDCA manipulations work in the real world. But let me repeat that question:

Does setting AC_VI EDCA parameters to identical values as AC_BE:

A) solve your apparent multiplexing issue (giving NQB traffic lower latency access to airtime because it might be stuck behind larger aggregates) and does that also work in networks with multiple concurrently active stations?

B) does it have undesired side-effects on normal wifi operations (for the sake of the argument, I concede that applications expecting preferential air time access by using AC_VI will not get it (but they were never guaranteed to do so in the first place. I am more concerned whether cheap AP hardware will not simply lock up or serve the queues unfairly given that they probably were never tested with non-standard EDCA parameters)?

The fact that you could not enumerate end-user grade AP firmwares that allow to manipulate the EDCA parameters nor were up-to-date how this does or does not work on modern OpenWrt, excuse my insistence to see real data. In all honestly, this looks more like a way to avoid adding harder requirements to the RFC, than to actually propose a technically viable and tested solution.

I intend to ask the same question as a remote participant at your IETF presentation unless we solve this in the mailing list. Since I do want to surpise you I wanted to inform you of that in advance.

Best Regards
	Sebastian

---

From: Sebastian Moeller <[email-masked]>
Date: Thu, 14 Nov 2019 09:29:25 +0100

Hi Greg,

more below.

> On Nov 14, 2019, at 07:09, Greg White <[email-masked]> wrote:
> 

	[SM] That is not how wifi, or variable bit rate links work in general... The ISP counters will not tell whether meaningful starvation by NQB traffic actually exists downstream. I agree that an ISP should do this to avoid flooding by NQB traffic though, as that is almost guaranteed to lead to my scenario of concern.

> [GW] Actually, that functionality exists today in cable equipment, so my constituents shouldn't have a problem with it being a requirement here.
>  I suppose ISPs (or their equipment suppliers) that don't deploy cable equipment would need to weigh in if they find this to be objectionable.  

	[SM] Are you really proposing to make the functionality of user operated wifi networks conditional on ISPs wishes here? An ISP can always just opt to ignore an RFC (and sure no RFC should require something impossible/improbable) but we are not really talking about major investments here (DSCP resetting equipment needs to be at the edge anyway, if only to bleach DSCPs coming from the customer). End-users how ever can not be expected to even know about the details required to mitigate potential NQB side-effects (DSCP re-mapping on ingress, re-mapping of DSCP to AC in the AP, changing EDCA parameters).
	I note that all of this will help very little, if the part of the RFC that talks about making NQB safe to traverse the internet un-bleached, in that case there is no ISP that would be responsible for controlling the NQB rate (not bleaching DSCPs but simply ignoring them is AFAICT a permissable option for handling diffserve markimgs).

IMHO the upshot of this should be to 

a)  propose a DSCP for the NQB PHB that maps into AC_BE

b) instruct edge network operators to re-map NQB to a DSCP that maps into AC_VI, IFF it is safe to do so (either because the downstream has is known to handle NQB properly, or NQB traffic is controlled)

I base this on the principle of least surprise and the fact that as we agree NQB can, under certain conditions, have adverse affects on wifi networks.

> I'm not as familiar with OLT and BRAS capabilities.  Unless I hear objections, I will go ahead and add that requirement.
> 
> 
> 
>    Thanks, --David
>

---

From: <[email-masked]>
Date: Fri, 15 Nov 2019 07:32:21 +0000

Hi Sebastian,

I agree with your proposal.

Regards,

Ruediger