Re: [tsvwg] NQB recommendations for WiFi. [was: Qs on your 5G L4S slides]

[Sebastian Moeller <[e-mail]>]

Hi Greg,

thanks for fixing the topic. More below prefixed [SM2]

> On Mar 16, 2021, at 15:27, Greg White <[e-mail]> wrote:
> 
> Changing the subject line because this is no longer related to Ingemar's 5G L4S slides.
> 
> See [GW2].
> 
> On 3/15/21, 4:37 PM, "Sebastian Moeller" <[e-mail]> wrote:
> 
>    Hi Greg,
> 
>    see [SM] below.
> 
> 
>> On Mar 15, 2021, at 22:57, Greg White <[e-mail]> wrote:
>> 
>> Inline [GW].
> [snip]
>> [GW] The NQB draft does NOT make any recommendations on treatment of L4S-ECN marked traffic.  In addition, for NQB traffic it recommends to map it into a separate queue in the best effort access category (AC_BE).
> 
>    	[SM] Which is sweet, but for almost 100% of deployed APs that is not going to happen, not eve the tinker friendly opensource OpenWrt APs allow to change the weights of the ACs.
> 
> [GW2] What do you mean?

	[SM2] As I said, OpenWrt does not allow users to modify the EDCA parameters easily, sure, you can build your own firmware from source and add any customization you want, and you and I can do this, but te rest of my family can not. I simply assume tat the technical skills to do so are not ubiquitous in the population enough to relay in that.



>  I've personally done it with multiple off-the-shelf consumer grade devices (using multiple chipsets), and measured per-AC throughput with the EDCA params configured as described in the draft.  There was only one model that I came across where setting the EDCA parameters was not possible, and that implementation was clearly broken because it gave BE higher priority than VI by default.  I sent you an email with this result a year ago.  Plus, I believe that the majority of broadband providers in the world either deploy an integrated gateway or provide a WiFI router to their customers so they (the provider) have the ability to set these params themselves.  

	[SM2] Do you have a break-down how many of the world's APs fall into the oned by ISP ans owned by enduser categories?


> 
>> It only utilizes the video access category as a way to interoperate with existing WiFi gear (including RFC8325 gear*), and in that case it recommends that the EDCA parameters be configured so that AC_VI gets the same bandwidth priority as AC_BE.
> 
>    	[SM] But we all know that this recommendation will not actually to changes in a noticeable number of already deployed APs. Let's not kid ourselves that the update problem magically disappears just because it would be nic; this does not work for safety fixes, why should it work any better for new features?
> 
> [GW2]  You are way out on a limb here.  The recommendations in the draft currently are that ISPs use a codepoint at interconnection that (if left unmodified) would map to AC_BE.  
> It then mandates that, by default, access network gear ensure that such a codepoint is used. It only recommends that an ISP re-mark with a codepoint that maps to AC_VI when appropriate safeguards are in place, which could be a combination of policing, EDCA configuration, or full NQB PHB compliance.  What is your remaining safety concern!?

[SM2] Same as before opt-out versus opt-n for the AC_VI component. My proposal, use DSCP2 and have participating nodes that know whet they are doing and that it is safe to do so, re-map DSCP2 to DSCP42, is inherently safer than the use a DSCP with known side-effects and relay on other to clean up the mess. If there are no others or they are oblivious to NQB, but are nice enough not to bleach DSCPs where is the safety? 
In reality explicit opt-in solutions tend to be safer by far than those solutions that require explicit opt out. We have been through this before.


> 
> 
>> 
>> *this has gotten me thinking that it would be worth further discussion on NQB recommendations for RFC8325 gear.  Since the recommendation in the NQB draft would amount to a change to the implementation, perhaps the draft should recommend that 8325 gear (if possible) maps NQB to a separate queue in AC_BE, and only provides the AC_VI option as a backstop in case the implementation can’t provide a separate queue.
> 
>    	[SM] Again sounds sane, unless we look at the deployed base.
> 
> [GW2] What do you mean?

[SM2] The deployed base will ONLY do the DSCP42 to AC_VI prioritization, none other gear exists, and will, if it ever appears, take a long time to reach prevalence in the field. What you call a backstop will be the principle mode of operation for NQB for a long time.


> AFAIK there are no RFC8325 devices deployed currently.  Are you saying that it is insane for anyone to implement RFC8325?  Or are you saying that it is insane for us to provide recommendations to them?  Surely you don't think that all of the WiFi gear that will ever be deployed is already in the field.  

[SM2] No, I wanted to convey that think the argument you brought is sane and rationale, except for the timeframe in which the backstop will be operational.


> 
>> 
>> L4S is also walking into the WiFi environment as it finds it. With today's non-L4S products, I would also recommend that the L4S-ECN codepoints are mapped to the video access category, if possible. 
>> Nokia's latest WiFi products (in the 'Beacon' range) already include an L4S DualQ Coupled AQM. And as other L4S WiFi products come out, the coupling will introduce the recommended congestion signals that can be used as back-pressure against the priority scheduler. Users don't want to abuse scheduling priority at the expense of the balance between their own applications. But they have no choice until there's a mechanism that allows their applications to balance against other apps.
>> 
>> 
>> [GW] In my view the preferred option is for the dual-queue coupled AQM to be implemented within a single access category (e.g. AC_BE).  Utilizing AC_VI for L4S-ECN traffic would eliminate the ability to provide backpressure, since the BE queue in one STA can’t easily be coupled to the VI queue in another.
> 
>    [SM] Not that I want to defend ab-using AC_VI for L4S (as I said NQB with its aim for low rate flows has some justification for using AC_VI, assuming sufficiently strict admission control), but back-pessure in WiFI between all entities only happens via airtime access and that means you mainly compete with senders using the same AC, no?
> 
> [GW2] Well that statement isn't exactly true (unless I misunderstood you), but the point is that dual-q coupled AQM gives a scheduling weight to L4S traffic, but then subjects that traffic to CE marking driven by the classic queue (the backpressure).

[SM2] Yes, a design that has a number of failure modes, in fact I prefer to call a spade a spade and call this a 1:16 priority scheduler with a few heuristics to ameliorate the sharing behavior under a number of conditions, but I digress.

>  If you wanted to use default-configured AC_VI for L4S in order to provide the scheduling weight part, you wouldn't be able to get the backpressure since there is no way in WiFi for the classic (i.e. BE) queue in one device to directly influence the CE marking of traffic in another device's VI queue.  So, the better approach would be to only give L4S traffic scheduling weight within the device (i.e. a separate queue in BE) where you can provide the backpressure.  

[SM2] I agree that L4S should not use AC_VI (or other priority EDCA parameter sets). My point is that even if you would do back pressure right in one SSID, this will not help the neighbors. Assume network a on 802.11n's channel 6 uses AC_VI for L4S traffic but properly detects back pressure from its own AC_BE queue, but there is only L4S traffic active which all maps into AC_VI without issue for that SSID.
	Now, a neighbor also uses 802.11n channel 6, that neighbor will get almost no air-time on channel 6 for traffic in its own AC_BE. And that pretty much affects all other radios on channel 6 in reception range. As I said for properly managed NQB use, with rate-limiting that situation will be rare/unlikely (but still possible, WiFi rates depend on conditions and whether a traffic class is sparse or saturating depends on the ratio between the classes instantaneous rate and the available instantaneous rate*)
When scheduling on a shared medium, you really need to take the full medium into account.; but you know that way better than I do ;)

Best Regards
	Sebastian


*) I made this point in an earlier review, non-queue-buiding is IMHO a misnomer, non-capacity-seking is a far better description.


> 
> 
>