Subject: [tsvwg] L4S WiFi tests

From: Pete Heist <[email-masked]>
Date: Thu, 19 Aug 2021 16:21:12 +0200

We ran a few tests of L4S with WiFi, using a laptop with the L4S kernel
along with our existing "real-world" wired setup. A few results came
out of that, which have been added to the l4s-tests repo:

1) With L4S traffic through existing RFC3168 queues (even with FQ), the
latency spikes predicted in theory, particularly on rate changes, do
show up in practice. This comes from under-reacting to the existing,
incompatible RFC3168 version of CE:

https://github.com/heistp/l4s-tests#intra-flow-latency-spikes-from-underreaction-to-rfc3168-ce

In this case we tested two Prague flows together in a 20Mbps bottleneck
at 20ms, one wired and one WiFi. Both the WiFi and wired flows are
affected, since they share the same queue.

2) With L4S traffic through DualPI2, and two flows competing with one
another as in #1, we see that the delay that the WiFi flow induces on
the wired flow in the shared L queue exceeds the sub 1ms low latency
goal:

https://github.com/heistp/l4s-tests#between-flow-induced-delay-from-wifi

One may reasonably argue here that WiFi should be improved to not
induce such delays, but I still think it raises the question of whether
reliably low latency is achievable in shared queues in practice,
regardless of how tight the AQM marking is.

3) We also saw underutilization for the L4S flow in #2
(https://github.com/heistp/l4s-tests/blob/main/results/wifi/prague_dualpi2_wifi_tput.png
) relative to runs with CUBIC through dualpi2 and CUBIC through
fq_codel (in the same directory), but I did not write that up. With
WiFi, rates can change run to run, and I think there's a general
awareness already that bursty arrivals in the L queue can lead to
underutilization. A more accurate analysis of how WiFi utilization is
affected by L4S would take more work. I do think this sounds like
something that the "canary" type testing should be able to spot.

Pete