[tsvwg] NQB versus WIFI access classes Gedankenexperiment

[Sebastian Moeller <[e-mail]>]

Dear List,


since it seems clear to me that my objections against using AC_VI or AC_VO for indifferently for NQB marked packets, mainly falls on deaf ears.


Let me introduce a small Gedankenexperiment to demonstrate why this a patently problematic idea especially in the light of the stated goals of the NQB marking and L4S in general.

Let me propose the following scenario (sticking somewhat to Bob's numbers):

An dualQ type AQM on the ISP side of the access link which tries to split (a gross-rate of) 120 Mbps between a QB and a NQB queue more or less equally*. So full saturation steady state will be:
60 Mbps QB traffic
60 Mbps NQB traffic

Now let's look exactly at that saturating-load situation that is surprisingly common on end-user internet access links (otherwise an NQB mark would not really be needed)

The exact number of flows does not matter for my argument, but just to make things simple assume each flow takes of 10 Mbps of the gross-rate. So we have 
6 * NQB flows @10Mbps each (say paced video streams), dscp marked 0x2A
6 * QB flows @10Mbps average (say non-paced bulk data flows), dscp "marked" 0x00

On the end user side this data is flowing over wifi links from the CPE to the actual endpoints.

As long as wifi  rates stay >> 120 Mbps, things will just work out as intended by NQB more or less independent of which AC is assigned to NQB traffic.

But now the neighbors come home and there is going to be channel contention in the RF-medium and achievable data rates for our example household drop to 60 Mbps.

What the NQB /L4S approach seems to intend in that situation would be a grace-full  reduction in rates for both NQB and QB flows ot an aggregate of ~30 Mbps each.

But with NQB mapping to AC_VI/AC_VO what is going to happen ist, that the NQB flows will secure almost all of the tx-ops and hence starve out the QB-flows almost completely (doubly so, since the NQB airtime hogging will make it hard for QB data to reach the endpoints but also equally hard for ACKs from there to go back to the senders). The upstream dualQ AQM will see more or less NQB~60Mbps, QB~0Mbps, and will not help at al, since 60/0 is a valid traffic split.
I might be wrong, but that inevitable outcome does not seem to be well aligned with the stated goals of the NQB code point.

I present this as a Gedankenexperiment, but it is not hard to turn this into an actual experiment...


And that is the core rationale why I believe that NQB should stay at AC_BE; in addition to the observations that the current loose requirements for a flow to be NQB need to be aligned with rfc8325 so that the NQB aggregate only gets the lowest AC of any of its valid member traffic classifications according to rfc8325.

Best Regards
	Sebastian





*) I am not fully certainwhat kind of guarantees L4S actually makes for the bandwidth split between QB and NQB/L4S flows, but for this discussion I assume it aims for rough equality.