* Re: [Make-wifi-fast] [Cake] Playing with ingredients = ruined the CAKE
2020-05-31 19:01 ` [Make-wifi-fast] [Cake] Playing with ingredients = ruined the CAKE Dave Taht
@ 2020-05-31 19:25 ` Sebastian Moeller
0 siblings, 0 replies; 2+ messages in thread
From: Sebastian Moeller @ 2020-05-31 19:25 UTC (permalink / raw)
To: Dave Täht; +Cc: Kevin Darbyshire-Bryant, Cake List, Make-Wifi-fast
Hi Dave,
> On May 31, 2020, at 21:01, Dave Taht <dave.taht@gmail.com> wrote:
>
> On Sun, May 31, 2020 at 11:08 AM Kevin Darbyshire-Bryant
> <kevin@darbyshire-bryant.me.uk> wrote:
>>
>>
>>
>>> On 31 May 2020, at 18:26, John Yates <john@yates-sheets.org> wrote:
>>>
>>> On Sun, May 31, 2020 at 1:08 PM Kevin Darbyshire-Bryant
>>> <kevin@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.
According to https://tools.ietf.org/html/rfc8325#page-10 it actually often lands in AC_VI:
"Voice (EF-101110) will be mapped to UP 5 (101), and treated in the
Video Access Category (AC_VI) rather than the Voice Access
Category (AC_VO), for which it is intended"
Which IMHO is the right thing, AC_VO is so ruthless in acquiring airtime when competing with the other AC's that IMHO it should only be kept as the "nuclear option" in case an AP does not get sufficient airtime when competing with AC_VO hogging stations, but not as part as a normal scheme, UNLESS there are only managed APs in the environment, and any airtime hogging is not at the expense of the neighbors...
> 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.
+1; not that I can back this up with data...
>
> 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....
+1, I would assume the issue is that queued packets in AC_VO will basically stall all other quees until the VO queue clears. I have a macbook, which in rrul_cs8 tests over wifi basically hogs all airtime for its two AC_VO flows, essentially starving all other flows in both directions to a trickle. Hence my assesssment that AC_VO is a tad anti-social.
>
> 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.
Puzzled, using zoom, over an ath9k radio with Toke & yours airtime fairness/fq_codel fixes works quite well with competing traffic even with zoom in the default AC_BE. May this is because my nominal 100/40 link, shaped with layer_cake down to 49/36 Mbps does not make the wifi into the real bottleneck in the first place...
Best Regards
Sebastian
>
>>
>> Cheers,
>>
>> Kevin D-B
>>
>> gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A
>>
>> _______________________________________________
>> Cake mailing list
>> Cake@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@taht.net <Dave Täht> CTO, TekLibre, LLC Tel: 1-831-435-0729
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
^ permalink raw reply [flat|nested] 2+ messages in thread