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

[Greg White <[e-mail]>]

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

    Hi David,
    
    
    > On Nov 7, 2019, at 22:00, Black, David <[e-mail]> 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).   
    > 
    > That's correct.
    
    	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
    
    
    > 
    > 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
    >>>>> 
    >>>>> 
    >>> 
    >>> 
    >>> 
    >