[Make-wifi-fast] Upcoming WiFi standard to set per-flow DSCP values?
Bob McMahon
bob.mcmahon at broadcom.com
Mon Jan 10 11:02:26 EST 2022
hmm, curious about the side effects.
I perceive the multiple queues with static EDCAs as a poor man's version of
adaptive EDCAs where every transmit could have the EDCAs defined via a
delayed binding just prior to transmit arbitration. Also, things like push
in first out (PIFO) hw queues <http://web.mit.edu/pifo/> seem interesting
allowing a TCP 3WHS and the first few packets (mouse flow) to jump the
line, similar to an express lane at a grocery store.
Bob
On Sun, Jan 9, 2022 at 6:41 PM Dave Taht <dave.taht at gmail.com> wrote:
> I've tried to describe the side effects of using all 4 of these queues
> in nearly every talk. I'd really like it if the AP drivers just better
> multiplexed best effort traffic and modified the values in the beacon.
>
> I do see more value in pushing out queue selection to the clients, if
> used sparingly.
>
> On Wed, Jan 5, 2022 at 9:12 AM Aaron Wood <woody77 at gmail.com> wrote:
> >
> > I'm guessing that schemes like this are mostly aimed-at, or
> developed-by, at the enterprise wifi market, where you have mixed uses
> being run on the same AP (much like running separate vlans on the same
> wired network), to mix both "infrastructure" uses which have priority, and
> "guests" networks which have less priority. When I was in that part of the
> industry, I was seeing this a lot, the general attempt to move the QoS and
> vlans from wired networks into WLAN and WAN links.
> >
> > On Wed, Jan 5, 2022 at 4:28 AM Sebastian Moeller <moeller0 at gmx.de>
> wrote:
> >>
> >> Hi Toke, hi Jon,
> >>
> >> here is a corrected version of what I sent to another list (I
> accidentally converted the VA bit-pattern with my calculator set to base8
> so decimal 54 and Range7 instead of the correct decimal 44 and Range6,
> which does not change much for the AC mapping as both range6 and 7 map to
> AC_VO):
> >>
> >> >> hostapd: add wmm qos map set by default
> >> >> author Felix Fietkau <nbd at nbd.name>
> >> >> Wed, 3 Nov 2021 22:40:53 +0100 (22:40 +0100)
> >> >> committer Felix Fietkau <nbd at nbd.name>
> >> >> Wed, 3 Nov 2021 22:47:55 +0100 (22:47 +0100)
> >> >> commit a5e3def1822431ef6436cb493df77006dbacafd6
> >> >> tree f4494efd6e08a872524eedb5081564a6f5ece20c tree | snapshot
> >> >> parent b14f0628499142a718a68be7d1a7243f7f51ef0a commit
> | diff
> >> >> hostapd: add wmm qos map set by default
> >> >>
> >> >> This implements the mapping recommendations from RFC8325, with an
> >> >> update from RFC8622. This ensures that DSCP marked packets are
> properly
> >> >> sorted into WMM classes.
> >> >> The map can be disabled by setting iw_qos_map_set to something
> invalid
> >> >> like 'none'
> >> >>
> >> >> Signed-off-by: Felix Fietkau <nbd at nbd.name>
> >> >
> >> > Which introduces the following new RFC8325 inspired DSCP to AC
> mappings:
> >> > + set_default iw_qos_map_set
> 0,0,2,16,1,1,255,255,18,22,24,38,40,40,44,46,48,56
> >> >
> >> > Which translates into the following mappings (according to the
> hostapd rules below*):
> >> >
> >> > unraveling this gets us to (0 is coded as DSCP Exception, the rest as
> DSCP ranges):
> >> >
> >> > UP DSCP AC PHBs(decDSCP)
> >> > Ex0 BE BE(0) BE/CS0(0)
> >> > Range0 2-16 BE CS1(8)**, AF11(10), AF12(12), AF13(14),
> CS2(16)
> >> > Range1 1-1 BK LE(1)
> >> > Range2 -
> >> > Range3 18-22 BE AF21(18), AF22(20), AF23(22)
> >> > Range4 24-38 VI CS3(24), AF31(26), AF32(28), AF33(30),
> CS4(32), AF41(34), AF42(36), AF43(38)
> >> > Range5 40-40 VI CS5(40)
> >> > Range6 44-46 VO VA(44), EF(46)
> >> > Range7 48-56 VO CS6(48), CS7(56)
> >>
> >> The kernel's default mappings, as far as
> https://wireless.wiki.kernel.org/en/developers/documentation/mac80211/queues
> states, seem driven by the top 3 bits of the DSCP field:
> >> RFC8325 also has a section about the default mappings
> >>
> >> UP DSCP AC PHBs(decDSCP)
> >> Range0 0-7 BE CS0(0)
> >> Range1 8-15 BK CS1(8), AF11(10), AF12(12), AF13(14)
> >> Range2 16-23 BK CS2(16), AF21(18), AF22(20), AF23(22)
> >> Range3 24-31 BE CS3(24), AF31(26), AF32(28), AF33(30)
> >> Range4 32-39 VI CS4(32), AF41(34), AF42(36), AF43(38)
> >> Range5 40-47 VI CS5(40), VA(44), EF(46)
> >> Range6 48-55 VO CS6(48)
> >> Range7 56-63 VO CS7(56)
> >>
> >>
> >> IMHO RFC8325 and the whole WMM scheme clearly lacks data showing that
> is actually delivers on its promises. RFC8325 specifically seems obsessed
> in changing mappings such that PHBs align with the 4 WMM queues, instead of
> interpreting the fact that the apparent mismatch between what the IETF
> thinks about specific PHBs/DSCPs and how they are treated for most users,
> as clear sign, that reality does not care... (probably mostly driven by the
> elephant in the room, of DSCPs not being end-to-end).
> >>
> >> I agree with Toke that allowing APs to steer specific DSCP use by
> applications seems taking an proven non-working idea to the extreme... (APs
> can already instruct stations on which DSCPs to map to which AC (see
> Felix's patch), which is not used that much, no idea why anybody thinks
> that allowing APs even more disruptive changes to end-point behavior is
> going to work any better).
> >>
> >> Regards
> >> Sebastian
> >>
> >> P.S.: IMHO the biggest change might be the up-prioritisation of EF from
> AC_VI to AC_VO, and I am not sure that is a good idea.
> >>
> >>
> >>
> >> > On Jan 5, 2022, at 13:02, Toke Høiland-Jørgensen via Make-wifi-fast <
> make-wifi-fast at lists.bufferbloat.net> wrote:
> >> >
> >> > Jon Pike <jonpike54 at gmail.com> writes:
> >> >
> >> >> Heh... So each and everyone in the stadium can have ALL their data
> >> >> prioritized above everybody else's! For a more Egalitarian world!
> >> >>
> >> >> Sigh... Meanwhile, back in reality...
> >> >>
> >> >> An aside, is that commit in git a significant improvement on the
> mappings,
> >> >> or just some minor tweaks?
> >> >
> >> > I *think* they are just minor tweaks, but I don't actually recall the
> >> > exact mapping that's the kernel default...
> >> >
> >> > -Toke
> >> > _______________________________________________
> >> > Make-wifi-fast mailing list
> >> > Make-wifi-fast at lists.bufferbloat.net
> >> > https://lists.bufferbloat.net/listinfo/make-wifi-fast
> >>
> >> _______________________________________________
> >> Make-wifi-fast mailing list
> >> Make-wifi-fast at lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/make-wifi-fast
> >
> > _______________________________________________
> > Make-wifi-fast mailing list
> > Make-wifi-fast at lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/make-wifi-fast
>
>
>
> --
> I tried to build a better future, a few times:
> https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org
>
> Dave Täht CEO, TekLibre, LLC
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast
--
This electronic communication and the information and any files transmitted
with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may contain
information that is confidential, legally privileged, protected by privacy
laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/make-wifi-fast/attachments/20220110/06bebe1e/attachment-0001.html>
More information about the Make-wifi-fast
mailing list