[tsvwg] Re: WGLC for A NQB PHB for Differentiated Services (draft-ietf-tsvwg-nqb) to end 27th May 2024.

[Sebastian Moeller <[e-mail]>]

Dear All,


summary: I believe this draft needs to be changed to propose a safe DSCP value for existing WiFi APs and should not pass last call before that change has been made.

QUESTION: To all parties that have tested this, how did you assess the fraction of airtime taken up by NQB traffic? And if you did not do so, how can you be sure that deploying it on existing WiFi networks is safe?



> On 20. May 2024, at 09:41, Gorry Fairhurst <[e-mail]> wrote:
> 
> This email starts a 3 week WG Last Call to determine if the following TSVWG ID is ready:
> 
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/
> 
> This document targets: PROPOSED STANDARD.
> The document shepherd will be: Gorry Fairhurst.
> 
> The WGLC will end at midnight UTC on 10th June 2024 (2024-06-27)
> 
> Please do read the draft, and please send any comments/concerns to  the TSVWG mailing list, including notes on whether these are ready to publish (or send an email directly to the chairs<[e-mail]>).

[SM] I consider this draft not to be ready for publication. The choice for the decimal DSCP value of 45 has clear side effects for the majority of existing WiFi deployments and neither the justification for that not the proposed diagnostics or remedies are appropriate. I strongly believe any PHB  intended for common use by end-users without mandatory relevant traffic behaviour policing should refrain from proposing DSCP values that map into the higher priority access classes AC_VI and AC_VO. (Relevant here means not based on capacity share on some upstream link but in the (likely common) case of WiFi bottleneck links capacity share over the air, aka airtime share). In WiFi airtime access is affecting the full channel, so using more tx opportunities with AVC_VI will not just prioritise NQB packets against other packets of the same SSID (which arguably might be acceptable) but also against traffic in other SSIDs on the same channel.

This is completely avoidable, by simply selecting a DSCP value without that side effect and simply have NQB-aware APs implement the desired redefinition of AC_VI and use the standard qos map feature to have compliant SSIDs assign the selected DSCP value to the redefined AC.

"Since this equipment is widely deployed, and the Wi-Fi link can become a bottleneck link, the performance of traffic marked with the NQB DSCP across such links could have a significant impact on the viability and adoption of the NQB DSCP and PHB. Depending on the DSCP used to mark NQB traffic, existing Wi-Fi equipment that uses the default mapping of DSCPs to Access Categories and the default EDCA parameters will support either the NQB PHB requirement for separate queuing of NQB traffic from Default, or the recommendation to treat NQB traffic with forwarding preference equal to Default traffic, but not both."

A consequence of the high probability of non NQB-aware APs becoming the relevant bottleneck is that together with 

"NQB microflows are expected to each consume no more than 1% of the link capacity, and in low stat-mux environments (such as at the edge of the network) would be unlikely in aggregate to consume 50% of the link capacity. Thus, 50% seems a reasonable upper bound on the weight for the NQB PHB in these environments."

While spending 50% of capacity on NQB traffic seems inappropriately high, 50% of a 1000 Mbps DOCSIS link is still 500 Mbps, a rate that WiFI4/5 APs and station often never achieve. But at that point a traffic protector upstream of the AP that takes 1000 Mbps as reference will essentially not have much protective function on the WiFi link.
If we add the information, that WiFI is variable bitrate, a station far away from the AP can result in considerably less capacity making the whole issue even more dire; especially for APs that do not implement airtime fairness, but that default to throughput fairness... 


Now to the individual points:
"    • Separate queuing is necessary in order to provide a benefit for traffic marked with the NQB DSCP."

	+1; the rationale is sound, the question however is IMHO, is 'benefit' at the expense of others appropriate here?



"    • The arrangement of queues in Wi-Fi gear is typically fixed, whereas the relative priority of the Access Category queues is configurable. Most Wi-Fi gear has hardware support (albeit generally not exposed for user control) which could be used to adjust the EDCA parameters in order to meet the equal forwarding preference recommendation. This is discussed further below."

	Given the admission "albeit generally not exposed for user control" this seems to be an argument for only using this as an explicit opt-in mechanism for NQB-aware APs.

"    • Traffic that is compliant with the NQB sender requirements Section 4.1 is unlikely to cause more degradation to lower priority Access Categories than the existing recommended Video Access Category traffic types: Broadcast Video, Multimedia Streaming, Multimedia Conferencing from [RFC8325], and AudioVideo, ExcellentEffort from [QOS_TRAFFIC_TYPE]."

	That is in itself not wrong, however it seems ligically close the my kids argument "but dad, the other kids do it too" which is IMHO not an acceptable argument for doing something detrimental to others.

"    • Several existing client applications that are compatible with the NQB sender requirements already select the Video Access Category, and thus would not see a degradation in performance by transitioning to the NQB DSCP, regardless of whether the network supported the PHB."

	Correct, but that removes the argument for NQB as being a safe alternative to the traditionally uses PHBs/DSCPs, but still expects users of EF to change their code for no gain... (it is arguable that WMM should have defaulted everything to AC_BE, after all a DSCP is not sufficient evidence of a full PHB being implemented, e.g. sufficient access control for EF traffic).

"    • Application instances on Wi-Fi client devices are already free to choose any Access Category that they wish, regardless of their sending behavior, without any policing of usage. So, the choice of using DSCP 45 (decimal) for NQB creates no new avenues for non-NQB-compliant client applications to exploit the prioritization function in Wi-Fi."

	Sure, but again it invalidates the following claim for NQB "The PHB is also designed to minimize any incentives for a sender to mismark its traffic, since neither higher priority nor reserved bandwidth are being offered." in the likely common legacy WiFi situation the NQB PHB will do exactly what it claims not to do, it will give higher priority and higher throughput (at least if competing with other flows)... 


"    • For application traffic that originates outside of the Wi-Fi network, and thus is transmitted by the Access Point, the choice of DSCP 45 does create a potential for abuse by non-compliant applications. But, opportunities exist in the network components upstream of the Wi-Fi Access Point to police the usage of the NQB DSCP and potentially re-mark traffic that is considered non-compliant, as is recommended in Section 4.4.1. Furthermore, it is a common practice for residential ISPs to re-mark the Diffserv field to zero on all traffic destined to their customers' networks, and any change to this practice done to enable the NQB DSCP to pass through could be done alongside the implementation of the recommendations in Section 4.4.1."

	Well, the problem with this idea is, that the upstream policer likely has zero insight about the actual bottleneck capacity of the WiFi link, not that there is a simmering aggregate capacity to beginn with (different stations will be accessed with different MCSs).
	The claim 'common practice for residential ISPs to re-mark the Diffserv field to zero on all traffic destined to their customers' IMHO needs substantiation, because to show a black swan, my ISP the German daughter of a big European telco does not generally re-mark all DSCP codepoints to zero, and I believe there are studies showing that this is NOT universally done.


IMHO all of this implies, that the draft should not pass last call, the remedy for this is easy, change the proposed DSCP value to one the maps by default to AC_BE, and instruct NQB-aware APs apply special treatment to that DSCP (the section already exists in the draft).
The sole argument for using DSCP 45 seems to be that it is likely easier to deploy that way, but the choice here is 'convenience of deployment' or 'safety'. I think we should clearly opt for safety and hence I believe the draft is not ready for last call.


Regards
	Sebastian



> 
> Best wishes,
> Gorry and Marten
> (tsvwg co-chairs)
> 
> —
> 
> The IETF WG Last Call process is described in RFC 6174.
>