On Sun, May 31, 2020 at 11:08 AM Kevin Darbyshire-Bryant <[email protected]> wrote: > > > > > On 31 May 2020, at 18:26, John Yates <[email protected]> wrote: > > > > On Sun, May 31, 2020 at 1:08 PM Kevin Darbyshire-Bryant > > <[email protected]> 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 > [email protected] > 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 [email protected] <Dave Täht> CTO, TekLibre, LLC Tel: 1-831-435-0729 _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
