Should home-router-configs.md really recommend all L4S traffic is placed in AC_VI queue?

[tomderham]

home-router-configs.md currently contains the following recommendation:

"... to ensure that L4S and NQB works on some level in their router.... Level 2 Support: WiFi WMM Support ... the router can optimally set a WMM rule that these packets should be placed in the AC_VI queue for better latency."

Differentiated use of Wi-Fi Access Categories is important to meet KPIs for flows with low-latency requirements, particularly in the presence of OBSS traffic. If flows that today might be sent in AC_VO (e.g. VoIP) use L4S, the recommendation to use AC_VI would result in latency regression. On the other hand, if bulk flows that today are sent AC_BE use L4S, the recommendation to use AC_VI would result in higher collision rates that cause regression to other flows sharing the medium that do have low-latency requirements. It may also negatively impact throughput due to lower aggregation limits with AC_VI.

Consider modifying this recommendation so that AC/TID assignment is orthogonal to whether or not a flow is using L4S.

[jlivingood]

This text merely follows what is laid out in Section 7.3.1. - Interoperability with Existing Wi-Fi Networks - of the IETF NQB draft (https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb#section-7.3.1)

Feel free to discuss with Greg White (g.white@cablelabs.com)

[gwhiteCL]

The NQB draft is specific to the NQB DSCP, whereas @tomderham's comment is specific to L4S.

Aside from some misconfiguration situations, my understanding is that no HSD downlink traffic today is sent with anything other than AC_BE. So, the argument about latency regression (AC_VO to AC_VI) doesn't apply, but the other arguments are worth considering.

NQB traffic is required/expected to be low-bitrate non-bursty, so classifying it to AC_VI in the downlink is expected to be largely innocuous to non-NQB traffic while giving a better latency result for the NQB traffic itself. The NQB draft @jlivingood linked to gives more rationale for this classification.

For L4S traffic with default DSCP, I think it is a judgement call as to which AC to use. There are definitely pros & cons.

This configuration is provided as an interim step on the way to Level 3 (the end goal), so it stands to reason that it isn't the optimal arrangement.

[tomderham]

Thanks @gwhiteCL and @jlivingood for the quick responses.

I agree that, given NQB is assumed to be low-bitrate and non-bursty, the recommendation to use AC_VI seems reasonable for NQB traffic, at least as a default mapping for the special DSCP value that NQB uses.

As for non-NQB L4S traffic, I'm not sure exactly what is the definition of HSD (presumably, High Speed Data) in this context, but if it applies to any data that traversed a broadband (DOCSIS?) link, then I am aware of various scenarios today where some of that traffic is sent over Wi-Fi using AC_VI or AC_VO. This arises in a few different scenarios, including:

• AP's own proprietary algorithms or user configurations (DPI, IP-tuple rules, etc) identify certain flows and assign a prioritized AC
• features such as MSCS where the AP follows the (prioritized) AC used by the client/app in the uplink (e.g. various videoconferencing and gaming apps)
• cases where the AP maps the AC from DSCP marking applied at the source, which the ISP has preserved (e.g. I have personally seen this with IPsec packets from a carrier's Wi-Fi Calling gateway, where DSCP marking was mapped to AC_VO by the AP) Given L4S is intended to be used with a wide range of traffic types, I do think it is important that the ability to use all the Wi-Fi ACs with these flows is maintained.

In any case, perhaps I could suggest that for now the corresponding text in home-routers-configs.md is updated to be specific to NQB. It sounds like evaluation of L4S in different scenarios is continuing, and perhaps additional recommendations for non-NQB L4S might be forthcoming in the future.

Thanks again for the good discussion.

[jlivingood]

In the field trials, downstream L4S traffic is also marked AC_VI, and we have noticed no ill effects. There have been other tests of WMM prioritization in the LAN, which I can share under NDA. And for US from a WiFi client, I think it is usually the case that the AP accepts whatever WMM priority the client uses?

What are the specific use cases of concern? I think what ends up being challenging is that we sometimes look at only 1 layer in isolation and miss what may happen at other layers. In that case, if we look at VoIP that is marked AC_VO, you mention a concern that latency will get worse if it is instead marked AC_VI. Why is that? Especially given the extensive use of FEC in VoIP clients at layer 7, are we looking at this holistically?

Perhaps it is informative to note all of your use cases of concern, and then let’s go through them one by one to make sure we’re fully seeing all potential implications & effects. :-)

[moeller0]

And for US from a WiFi client, I think it is usually the case that the AP accepts whatever WMM priority the client uses?

Not if the AP used a qos map to instruct the client how to map DSCPs to UP/AC, see e.g. (https://datatracker.ietf.org/doc/html/rfc8325#page-30):

6.3. IEEE 802.11u QoS Map Set

IEEE 802.11u [IEEE.802-11u-2011] is an addendum that has now been included within the main standard ([IEEE.802.11-2016]), and which includes, among other enhancements, a mechanism by which wireless APs can communicate DSCP to/from UP mappings that have been configured on the wired IP network. Specifically, a QoS Map Set information element (described in [IEEE.802.11-2016], Section 9.4.2.95, and commonly referred to as the "QoS Map element") is transmitted from an AP to a wireless endpoint device in an association / re-association Response frame (or within a special QoS Map Configure frame).

The purpose of the QoS Map element is to provide the mapping of higher-layer QoS constructs (i.e., DSCP) to User Priorities. One intended effect of receiving such a map is for the wireless endpoint device (that supports this function and is administratively configured to enable it) to perform corresponding DSCP-to-UP mapping within the device (i.e., between applications and the operating system / wireless network interface hardware drivers) to align with what the APs are mapping in the downstream direction, so as to achieve consistent end-to-end QoS in both directions.

But that only sets UP/AC in the station, how likely it is to acquire transmit opportunities depends on the EDCA settings the station uses.

[gwhiteCL]

And for US from a WiFi client, I think it is usually the case that the AP accepts whatever WMM priority the client uses?

Not if the AP used a qos map to instruct the client how to map DSCPs to UP/AC

I don't think that is technically correct.

I think the AP always accepts whatever WMM priority the client uses. AFAIK APs don't police the usage of WMM on the uplink. The AP can send a qos map, and that can give a STA more information that it can use when selecting a WMM. But some OSes & STAs set WMM AC independently from DSCP, and some STAs don't implement qos map.

[moeller0]

Yes, the AP is at the stations mercy, what ever the station does to acquire airtime, it does, but as I implied that is true even if the ACs are aligned and as intended... Hence the phrase "AP used a qos map to instruct the client how to map DSCPs to UP/AC" which obviously is missing the part "and the station accommodates to that instruction".

The AP can send a qos map, and that can give a STA more information that it can use when selecting a WMM.

I am not sure the station selects a WMM. My understanding was this guides the selection of the UP/AC to use but I guess that is semantics and what you meant, no?

But some OSes & STAs set WMM AC independently from DSCP, and some STAs don't implement qos map.

Sure and some OS might not put DSCP dec45 into AC_VI, all is possible. However I expect that the majority of devices will support both WMM and qos maps... After all the rationale for dec45 is exactly that stations opt for the default behaviour. That said, I accept that sending a qos map is a request mostly.

And just to state the obvious, even in a tighter controlled request grant system the central controller typically expects CPE to behave (which is in their interest as well) but can not really force it... im my GPON modem insists on transmitting continuously there is little the OLT can do...

[rjmcmahon]

Another thing to keep in mind that an AC is not the primitive property for media access. Media access in this context, e.g. without 802.11ax, is driven by the EDCAs. The default EDCAs per AC provided by the 802.11 standards are values that can be changed. The 802.11 standards engineers expect the BSS managers to adjust these for the networks they are managing and not use the defaults.

[tomderham]

Thanks for all the discussion.

Again, my suggestion for now is that the recommendations here align with the recommendations in the RFCs, and to my knowledge the L4S RFCs do not specify a particular TID or AC to be used for all L4S traffic.

A number of other points/questions were raised, let me try to respond to them:

if we look at VoIP that is marked AC_VO, you mention a concern that latency will get worse if it is instead marked AC_VI. Why is that?

Each AC is affiliated with a set of EDCA/WMM parameters which effectively define (a) statistical priority for a transmitting device using EDCA (aka LBT, backoff) that is attempting to win a TXOP on the channel to send packets with that AC and (b) some constraints on that TXOP (maximum length / aggregation rules). So if a VoIP packet is sent using AC_VI instead of AC_VO, the transmitter will on average have to wait longer to win a TXOP in the presence of other traffic that is sharing the medium (be that Wi-Fi or some other wireless technology using a similar LBT mechanism). In practice, if one transmitter is trying to send an AC_VO packet and another transmitter is trying to send an AC_BE packet, the AC_VO will win almost all the time. Whereas if the former is instead trying to send an AC_VI packet, it will lose out to the AC_BE transmitter some smallish but non-negligible proportion of the time. One can argue about the ability of higher layer codecs to adapt to high jitter flows, but to my understanding both VoIP (in terms of MOS scores) and other real-time applications such as VR gaming are quite sensitive to this. For what it's worth, the reasons why AC_VO is not simply used for all traffic are primarily: (a) it uses (by design) a small TXOP limit which reduces throughput, and (b) it does not scale well to a large number of AC_VO flows contending against each other, due to the small contention window range which means they would end up colliding with each other. Hence, in general the aim is to use AC_VO for low-bandwidth flows that really need the highest statistical priority, AC_VI for somewhat higher bandwidth flows that still have some priority need over bulk traffic, and AC_BE for most everything else. I am of course oversimplifying here for the sake of brevity, but the gains of differentiated use of ACs have been well documented for many years and can be easily demonstrated... And, in the specific case of VoIP, regression caused by use of AC_BE or AC_VI instead of AC_VO can also be easily demonstrated. Of course, the absolute numbers depend on the contention environment.

The default EDCAs per AC provided by the 802.11 standards are values that can be changed.

Yes they can be changed, however in practice the WMM defaults are used by the vast majority of APs in deployment today. When considering any broad recommendation to deviate from those defaults, it is necessary to consider impacts on fairness and scalability across a wide range of scenarios.

the AP accepts whatever WMM priority the client uses

An AP will generally "accept", in terms of "successfully receive" a packet sent by a client irrespective of what AC was used to send that packet. However as discussed above, the issue is not one of packet drop, but of the impact of statistical channel access performance.

AP used a qos map to instruct the client how to map DSCPs to UP/AC

This may be going a bit off-topic now, but there are multiple mechanisms by which a transmitter determines the UP/AC of a packet, as I mentioned earlier in this thread. Certainly one of them is based on DSCP->UP mapping. All WMM devices in the field (i.e. the vast majority of Wi-Fi devices period) have some sort of mapping table to convert DSCP to UP, and will use it in the absence of some other policy (e.g. MSCS, SCS, DPI, proprietary rules, VLAN tag mapping, etc). Many legacy implementations simply use the MSBs of the DSCP value as the UP, but more recently RFC8325 is adopted as the default table. If both AP and STA support it, then QoS Map is a mechanism by which the AP can push a non-default mapping table to a client device, in which case that is used instead of the default table. As a final note, since Wi-Fi 6, a client can send uplink packets without winning its own TXOPs, by responding to trigger frames sent by the AP. The AP had to win a TXOP in order to send the trigger, and the trigger (amongst other things) the Preferred AC - i.e. the AC of packets that it expects the STA to send in response to that trigger (again, somewhat of an oversimplification, but...)

[rjmcmahon]

The default EDCAs per AC provided by the 802.11 standards are values that can be changed.

Yes they can be changed, however in practice the WMM defaults are used by the vast majority of APs in deployment today. When considering any broad recommendation to deviate from those defaults, it is necessary to consider impacts on fairness and scalability across a wide range of scenarios.

This doesn't provide any real information on optimums for modern use cases that drive QoE. The fact that so many APs use default values that were essentially "made up" by standards engineers, used to show as an example, in turn suggests the engineering done at MAC level contention is a work in progress. It's a non trivial analysis as it depends on field theory and number of radiators and emitters active within spacetime coordinates, etc. And lots and lots of simulations. Per AC defaults may be gold or may be kryptonite or, most likely, somewhere in between. Nobody really knows and for sure don't know per the EMF the devices have in each's spacetime, which is going to vary across each and every network and across coordinate time, and even by how somebody holds their phone.

And the challenges to the 14B devices in the field may be even worse as trying to verify that all these devices are actually doing what their told by the AP, honoring NAVs, etc, is extremely complex as well.