[Cake] Playing with ingredients = ruined the CAKE

[Dave Taht]

On Sun, May 31, 2020 at 11:08 AM Kevin Darbyshire-Bryant
<kevin at darbyshire-bryant.me.uk> wrote:
>
>
>
> > On 31 May 2020, at 18:26, John Yates <john at yates-sheets.org> wrote:
> >
> > On Sun, May 31, 2020 at 1:08 PM Kevin Darbyshire-Bryant
> > <kevin at darbyshire-bryant.me.uk> wrote:
> >> I have absolutely no idea, don’t appear to have that thread :-)
> >
> > Mea culpa.  Should have included this link to the thread:
> >
> > https://lists.bufferbloat.net/pipermail/make-wifi-fast/2020-May/002860.html
> >
> > /john
>
> Ah, well after the initial excitement that ‘oh an application actually sets DSCP’ I checked what marking my zoom packets had on the next conference…to find… Best effort.  Crushing disappointment led to this in my firewall box:
>
> #Zoom - connections go to Zoom with dest ports 8801-8810
> $IPTABLES -t mangle -A QOS_MARK_F_${IFACE} -p udp -m udp -m set --match-set Zoom4 dst -m multiport --dports 8801:8810 -j DSCP --set-dscp-class CS3 -m comment --comment "Zoom CS3 VI"
> $IP6TABLES -t mangle -A QOS_MARK_F_${IFACE} -p udp -m udp -m set --match-set Zoom6 dst -m multiport --dports 8801:8810 -j DSCP --set-dscp-class CS3 -m comment --comment "Zoom CS3 VI”
>
> With dnsmasq configured to fill the Zoom4/6 ipsets with relevant IP addresses
>
> ipset=/zoom.us/Zoom4,Zoom6
>
> Works a treat.

groovy. nicer than what I did, except that I don't remember where CS3
lands in wifi anymore! CS4 and CS5 land in the VI queue....

As for the "EF" (and for that matter, CS6 and CS7) issue on wifi, it
lands in the VO queue. babel and BGP sets CS6 last I looked, and the
VO queue on 802.11n (which is still quite common on both clients and
APs) cannot aggregate. Given the rise of videoconferencing, mapping
stuff into the VI queue makes the most sense for all forms of wifi,
for both voice and video traffic. I like to think we've conclusively
proven that
packet aggregation is way more efficient in terms of airtime and media
aquisition for both 802.11n and 802.11ac at this point.

Worse than that, EF once meant "expedited forwarding", an early
attempt to create a paid-for "fast lane" on the internet. I'd not use
that
for anything nowadays.

So I could see EF landing in VI, and CS6, at least in the babel case,
being a good candidate for VI also, but the existing usage of CS6 for
BGP (tcp transfers) is a lousy place to put stuff into the VI queue, also.

And all in all, our existing fq_codel for wifi code does not work well
when we saturate all four wifi queues in the first place, and in
general
I think it's better that APs just use the BE queue at all times with
our existing codebase for that. Someday, perhaps, the scheduler
will only feed 1-2 hw queues at a time....

On the other hand, other APs, with massively overbuffered BE queues,
will probably do better with videoconferencing-style traffic landing
in VI,
so long as it's access controlled to a reasonable extent.

Clients SHOULD put videoconferencing (and gaming and latency sensitive
traffic, like interactive ssh and mosh) into the VI queue
to more minimize media acquization delays.

On the gripping hand, the best thing anyone can do for wifi is for all
devices to be located as close to the AP as possible.

>
> Cheers,
>
> Kevin D-B
>
> gpg: 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A
>
> _______________________________________________
> Cake mailing list
> Cake at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake



-- 
"For a successful technology, reality must take precedence over public
relations, for Mother Nature cannot be fooled" - Richard Feynman

dave at taht.net <Dave Täht> CTO, TekLibre, LLC Tel: 1-831-435-0729