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

[Greg White <[e-mail]>]

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" <[e-mail]> wrote:

    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
    > >
    > >