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

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

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

> -----Original Message-----
> From: Sebastian Moeller <[e-mail]>
> Sent: Thursday, November 7, 2019 3:53 PM
> To: Greg White
> Cc: Black, David; tsvwg IETF list
> Subject: Re: [tsvwg] draft-ietf-tsvwg-nqb, more questions
> 
> 
> [EXTERNAL EMAIL]
> 
> 
> 
> > On Nov 7, 2019, at 21:36, Greg White <[e-mail]> wrote:
> >
> > 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).
> 
> 	[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
> >
> >
> > 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
> >>>
> >>>
> >
> >
> >