Subject: [tsvwg] l4s or sce on wifi

From: Dave Taht <[email-masked]>
Date: Fri, 15 Nov 2019 19:43:05 -0800

I've been working on layering the sce and l4s stuff on top of the latest
wifi-ac + fq_codel + AQL code (some graphs here:
https://drive.google.com/corp/drive/folders/14OIuQEHOUiIoNrVnKprj6rBYFNZ0Coif
) in the hope that I finally might understand how it should work.

And I just don't get it.

over "prague" I hit it with web-like traffic (15 simultaneous
connections, all in slow start) - big latency hit. I hit it with torrent
traffic and watch the switchover cost. DASH is nasty especially with two
or more folks watching videos. Netflix is bursty as heck...

I try dctcp + dualpi over a controlled environment with some of these
traffic types using it, don't get anywhere.

I suspect if I hit dualpi with normal users on a normal campus
with multiple wifi APs it would be uglier, but limited to the
dualpi queue, at least at that edge.

I have never been able to duplicate most of the l4s results on ethernet
or wifi, starting with the first slide on the preso to netdevconf - near
as I can tell codel result was was from a non-rfc3168 enabled version,
and the dctcp portion bogus, and totally unclear how the cdf was
generated, and it got more confusing from there. 

I pointed out the headaches GRO and IW10 is causing me in the field in
an earlier message. Wireless-n is a up to 42 packet burst that
effectively arrives at an infinite rate, and my egress links usually run
at 5-20mbit, tops, ingress at 1-200Mbit, so in one direction comcast is
the bottleneck, the other, wifi. ac is up to 4MB of data, also arriving
at an infinite rate, I don't see how these bursts on normal mixed
traffic can be mitigated without fq in place in either dualpi queue.

Maybe, if y'all can explain how this is supposed to work, in person,
with the SCE team in front of some repeatable simulations and they
can explain it back to me perhaps I'll finally understand what the heck
the benefits y'all are talking about, and whether it can apply to wifi.

on the non-wifi front (I've only had a few days on it) - From tearing
apart the current l4s bakeoff dataset, on the simulated 50mbit link I
see somewhat low latency at the cost of an enormously inflated
convergence time, a huge latecomer disadvantage, and massive rtt
unfairness especially at short to mid-range rtts - are these also goals?

and those tests don't use the kinds of normal traffic I slam these links
with, but boring single or dual flows in long durations which normal,
dash, torrent, etc, traffic aren't.

anyway, I'm happy to have some data and decent code now and I look
forward to following along with the various presos remotely this week.

I'll try to pull together some comparison plots this weekend,
showing some details others haven't got around to yet, perhaps
they will end up useful in the coming debate or the weeks to come.