Anyway for those of you trying to share the network with more apps and
people than normal
and have solid, stable videoconferencing no matter the load....

It's usually most important to fix the ISP caused bufferbloat. (
https://gettys.wordpress.com/ ),
and then the wifi.

For major bufferbloat-fixing latency improvements at home, below 400mbit, in the
commercial space, presently the evenroute v3 is benchmarking out as
the least bloated, ever, on
both the wifi and the uplink. They have both fq_codel on the wifi
(rfc8290) and cake on the ISP
down and uplinks. They autoconfig well and their "sag" feature for
detecting upstream
bloat seems to work fairly well, especially on dsl, and they are,
so far as I know, the only ones to get dsl framing more right out of the box.

(I have no financial relationship with evenroute, but they do use all our stuff)

100 people on this one, with a big download from someone else during
the test. near-zero latency impact, totally transparent videoconferencing,
even over wifi: http://www.dslreports.com/speedtest/62398495

Above 400Mbit I generally recommend rolling a custom x86 fw+sqm
solution built around openwrt, ubuntu linux, ipfire, untangle, or
(distant last, but if you like bsd), pfsense.  There's dozens of
others, of course...

free.fr's dsl routers do three tiers of fq_codel at "line rate"
because they wrote their own debloated dsl driver. Sadly, it's the
only debloated dsl driver I know of, and everybody else has to shape.

ubnt's edgerouter's sqm, and pfsense's implementations of fq_codel
both work ok, but require some configuration, eero's SQM
implementation is a little too "automatic" for my taste, and in all
these products don't do dsl compensation right, so you have to shape
much lower than is theoretically possible to get good latency. There
is an out of tree build of "cake" for the edgerouters, which
does do dsl framing compensation right. coping with link compensation
for cable, fiber, or ethernet is just fine on everything, however.

Of course, openwrt, dd-wrt, ipfire, asus-merlin, vyatta, gargoyle, a
couple dozen others, have been shipping a decent fq_codel +
sqm-derived system for the past 5 years or so, if you haven't taken
the time to configure yours, it might contribute to familial harmony
if you do.... if you have an old junked router in your closet worth
reflashing... some spare time...

netduma routers have a fq_codel derived sqm solution but it seems a bit flaky.

On just the wifi front...  All the broadcom wifi products I have tried... suck.
Mt76, ath9k, and and many commercial ath10k based products seem to work ok,
but until last month, openwrt's ath10k implementation sucked (
https://forum.openwrt.org/t/aql-and-the-ath10k-is-lovely/  )
and the fixes are not in a shipping release. yet.

eero labs wifi has fq_codel and has an "automagic" sqm implementation but,
it's a little too automagic for my taste.

Google wifi does have fq_codel, but not sqm. I don't know what plume
does except that they do all sorts of snoopy things and claim it's great.
Google nest is terrible. The impact of cloudy security cams in general
on yer uplink can be terrible.

ll the cell phone - tether setups I've tried are terrible - 1.6 sec of bloat,
and terrible jitter, regardless.

mikrotik's PCQ is sfq-based and is not the greatest, but if that's all you
have, turn it on.

I have been finding out that while pie is often enabled on docsis 3.1
modems quite a few docsis 3.1 modems are being configured still in a
docsis 3.0 mode. You can find out if you are configured for 3.0 sometimes
by looking at the config screen (sometimes). Even then I'm unsure if
pie is enabled unless my upload speedtest is under 90ms and I see
random looking packet loss. still pie usually >10x better than what
docsis 3.0 used to do, when it is actually on. Regardless I slam
an openwrt box with sqm in front of it, as pie only fixes uplink bloat.

I recently had a report on AT&T fiber's 45Mbit symmetric service - over
480ms of bloat on the uplink: http://www.dslreports.com/speedtest/62767361
(They are turning the sqm-scripts on)

I'm not equipped to give recommendations for better videoconferencing
at home, on other gear. Prioritizing udp not on port 433 almost seems sane,
as does implementing sfq or wred if you have it. Saner solutions wanted,
zoom in particular wants all kinds of ports prioritized.

So far I've seen next to no attempts at diffserv usage either from the
videoconferencing world, in packet captures from zoom and other services.

On the ipv6 front, so far:

zoom does not use ipv6. bluejeans and google hangouts do. jitsi works
with ipv6 also. It's unclear if janus meetecho can be configured correctly
for ipv6 (any tips?). Haven't tried BBB (anyone?), however I'm told their
jitterbuffer was woefully misconfigured in the current release.

anyway...

in the hope that this helps with familial harmony when you try to share
the network at home...

I'd love to know you dslreports results and mitigations and more about
the QOE of
your videoconferences. And I do wish that the unending stream of
other PSAs and corporate blog posts about how the internet is holding
up would be replaced
with useful metrics to those videoconferencing a lot, about loss,
jitter and delay.

and why is rmcat dead?


dave




--
Make Music, Not War

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729