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

["Black, David" <[e-mail]>]

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 <[e-mail]> 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,
> 
> 
> > On Nov 5, 2019, at 01:28, Greg White <[e-mail]> 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 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-
> [e-mail] on behalf of [e-mail]> wrote:
> >
> >    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
> >
> >