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

[Sebastian Moeller <[e-mail]>]

Hi David,

thanks, more below.

> On Nov 8, 2019, at 20:41, Black, David <[e-mail]> wrote:
> 
>> 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.

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

	[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


> 
> Thanks, --David
> 
>> -----Original Message-----
>> From: Sebastian Moeller <[e-mail]>
>> Sent: Thursday, November 7, 2019 6:25 PM
>> To: Black, David
>> Cc: Greg White; tsvwg IETF list
>> Subject: Re: [tsvwg] draft-ietf-tsvwg-nqb, more questions
>> 
>> 
>> [EXTERNAL EMAIL]
>> 
>> 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.
>> 
>> 	[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
>> 
>> 
>> 
>> 
>>> 
>>> 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
>>>>>>> 
>>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>> 
>