Re: [tsvwg] NQB versus WIFI access classes Gedankenexperiment

[Toke Høiland-Jørgensen <[e-mail]>]

Sebastian Moeller <[e-mail]> writes:

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

It's worse than this: The maximum aggregation size for AC_VI and AC_VO
is way smaller than for AC_BE, so even without interference, the
capacity for NQB traffic is going to be smaller, so it doesn't take that
much traffic before it starts congesting the WiFi network...

-Toke