From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 5270A3B29D for ; Wed, 5 Jan 2022 12:12:00 -0500 (EST) Received: by mail-yb1-xb30.google.com with SMTP id 139so88430375ybd.3 for ; Wed, 05 Jan 2022 09:12:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sauVOd44AlGXJoNvP8Vz5BTKPeeP4hz7/Nb4Fld1YQI=; b=MIBDXjG/EeQAhN7Qdl/6tQIvnGyJRYC393wF67Ho6qudwXFJkPjwrH9CgGUrZjBf4K qW24amCR/99VfWsSnhkIqdYBWCGf0hwKN9XsOJ4J5VIocwl9/4TDf8r/YjPIvuOxvE+0 3+6R67xn7yB/cicxHOL2FmQsqZaU9jZAyJuvwgZv+d8XZd3Rfxq0e4Qn0TeKqf9tnF6+ 8S/lz7RwcafF2vPvN+tHYdK4oSvmOW0p6m5sf5vbWe9mkV+owPbioMu+QnwWow+cZ0qB 5aK6XOjrXrEFAQwPPvNBw80Drs5YLZv8m1BMsp/ZuiOvCFEACqtHKlqs1EV6ZDJJPYlb 4kvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sauVOd44AlGXJoNvP8Vz5BTKPeeP4hz7/Nb4Fld1YQI=; b=qggqzuRnpQMGmHX7DqapzPOlkxLdCCUwSEGidMfw0L28v+wvj7BM0+tS/NCHlPaRFf Vq5AXn8JaXquhL+frRMxJ+z9F+U+wrCla3nk6vp4rphZmcZsjpOUefzLkI75fqYdx3LK 5Ax6D0K45YfnCzmO7pfDS0+RVFPjDGZQ55TKS/CTk7NEvqfnqgcn1FmqrGgRBuCX+zoC GB8qylSUSLSCregB3CvrZvpHIzQFFOc3NsILxyL5Q4mr2smPRZ93zfcb7CncgVKIzvls TJuM+57UpX3S5FXFip2d/W6U+kT1URJnRwXYlaIc3/3gMTi7ErrlAQd+q5T3wmUl07pz 1WNw== X-Gm-Message-State: AOAM532lB08cWgPWqoItrU+qbHeISvehEM+cnvTENEZb4/WYeW7paIYb xJAohKNKGSyLHFqKYJ0yyHhC9P19T9IvSXqEKLo= X-Google-Smtp-Source: ABdhPJw67ku5EJKNCe4YSQSFPJsF0HXvrqM57o4dOyxfHIW14H47B9Qh5UMHMYiuYNha9Xz4T5ut4nq4yaRej7eH8Fg= X-Received: by 2002:a25:aa8c:: with SMTP id t12mr54417971ybi.615.1641402719615; Wed, 05 Jan 2022 09:11:59 -0800 (PST) MIME-Version: 1.0 References: <87r19nb27v.fsf@toke.dk> <87k0febdaq.fsf@toke.dk> In-Reply-To: From: Aaron Wood Date: Wed, 5 Jan 2022 09:11:49 -0800 Message-ID: To: Sebastian Moeller Cc: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Make-Wifi-fast , Jon Pike Content-Type: multipart/alternative; boundary="000000000000093df205d4d8da14" Subject: Re: [Make-wifi-fast] Upcoming WiFi standard to set per-flow DSCP values? X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2022 17:12:00 -0000 --000000000000093df205d4d8da14 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrote: > Hi Toke, hi Jon, > > here is a corrected version of what I sent to another list (I accidentall= y > converted the VA bit-pattern with my calculator set to base8 so decimal 5= 4 > 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 > >> Wed, 3 Nov 2021 22:40:53 +0100 (22:40 +0100) > >> committer Felix Fietkau > >> 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 properl= y > >> 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 > > > > 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/que= ues > 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 t= he > 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... (A= Ps > 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=C3=B8iland-J=C3=B8rgensen via Make-wif= i-fast < > make-wifi-fast@lists.bufferbloat.net> wrote: > > > > Jon Pike 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@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/make-wifi-fast > > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast --000000000000093df205d4d8da14 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm guessing that schemes like this are mostly aimed-a= t, or developed-by, at the enterprise wifi market, where you have mixed use= s being run on the same AP (much like running separate vlans on the same wi= red network), to mix both "infrastructure" uses which have priori= ty, and "guests" networks which have less priority.=C2=A0 When I = was in that part of the industry, I was seeing this a lot, the general atte= mpt to move the QoS and vlans from wired networks into WLAN and WAN links.<= /div>
O= n Wed, Jan 5, 2022 at 4:28 AM Sebastian Moeller <moeller0@gmx.de> wrote:
Hi Tok= e, 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 cha= nge much for the AC mapping as both range6 and 7 map to AC_VO):

>> hostapd: add wmm qos map set by default
>> author=C2=A0 =C2=A0 =C2=A0 =C2=A0Felix Fietkau <nbd@nbd.name>=C2=A0 =C2=A0
>> Wed, 3 Nov 2021 22:40:53 +0100 (22:40 +0100)
>> committer=C2=A0 =C2=A0 Felix Fietkau <nbd@nbd.name>=C2=A0 =C2=A0
>> Wed, 3 Nov 2021 22:47:55 +0100 (22:47 +0100)
>> commit=C2=A0 =C2=A0 =C2=A0 =C2=A0a5e3def1822431ef6436cb493df77006d= bacafd6
>> tree f4494efd6e08a872524eedb5081564a6f5ece20c=C2=A0 =C2=A0 =C2=A0 = =C2=A0 tree | snapshot
>> parent=C2=A0 =C2=A0 =C2=A0 =C2=A0b14f0628499142a718a68be7d1a7243f7= f51ef0a=C2=A0 =C2=A0 =C2=A0 =C2=A0 commit | diff
>> hostapd: add wmm qos map set by default
>>
>> This implements the mapping recommendations from RFC8325, with an<= br> >> update from RFC8622. This ensures that DSCP marked packets are pro= perly
>> sorted into WMM classes.
>> The map can be disabled by setting iw_qos_map_set to something inv= alid
>> like 'none'
>>
>> Signed-off-by: Felix Fietkau <nbd@nbd.name>
>
> Which introduces the following new RFC8325 inspired DSCP to AC mapping= s:
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0set_default iw_qos_map_set 0,0,2,16,1,1,25= 5,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=C2=A0 =C2=A0 DSCP=C2=A0 =C2=A0 AC=C2=A0 =C2=A0 =C2=A0 PHBs(decDSCP)=
> Ex0=C2=A0 =C2=A0BE=C2=A0 =C2=A0 =C2=A0 BE(0)=C2=A0 =C2=A0BE/CS0(0)
> Range0=C2=A0 =C2=A0 =C2=A0 =C2=A0 2-16=C2=A0 =C2=A0 BE=C2=A0 =C2=A0 = =C2=A0 CS1(8)**, AF11(10), AF12(12), AF13(14), CS2(16)
> Range1=C2=A0 =C2=A0 =C2=A0 =C2=A0 1-1=C2=A0 =C2=A0 =C2=A0BK=C2=A0 =C2= =A0 =C2=A0 LE(1)
> Range2=C2=A0 =C2=A0 =C2=A0 =C2=A0 -=C2=A0 =C2=A0 =C2=A0 =C2=A0
> Range3=C2=A0 =C2=A0 =C2=A0 =C2=A0 18-22=C2=A0 =C2=A0BE=C2=A0 =C2=A0 = =C2=A0 AF21(18), AF22(20), AF23(22)
> Range4=C2=A0 =C2=A0 =C2=A0 =C2=A0 24-38=C2=A0 =C2=A0VI=C2=A0 =C2=A0 = =C2=A0 CS3(24), AF31(26), AF32(28), AF33(30), CS4(32), AF41(34), AF42(36), = AF43(38)
> Range5=C2=A0 =C2=A0 =C2=A0 =C2=A0 40-40=C2=A0 =C2=A0VI=C2=A0 =C2=A0 = =C2=A0 CS5(40)
> Range6=C2=A0 =C2=A0 =C2=A0 =C2=A0 44-46=C2=A0 =C2=A0VO=C2=A0 =C2=A0 = =C2=A0 VA(44), EF(46)
> Range7=C2=A0 =C2=A0 =C2=A0 =C2=A0 48-56=C2=A0 =C2=A0VO=C2=A0 =C2=A0 = =C2=A0 CS6(48), CS7(56)

The kernel's default mappings, as far as https://wireless.wiki.kernel.org/en/developers/documen= tation/mac80211/queues states, seem driven by the top 3 bits of the DSC= P field:
RFC8325 also has a section about the default mappings

UP=C2=A0 =C2=A0 =C2=A0 DSCP=C2=A0 =C2=A0 AC=C2=A0 =C2=A0 =C2=A0 PHBs(decDSC= P)
Range0=C2=A0 0-7=C2=A0 =C2=A0 =C2=A0BE=C2=A0 =C2=A0 =C2=A0 CS0(0)
Range1=C2=A0 8-15=C2=A0 =C2=A0 BK=C2=A0 =C2=A0 =C2=A0 CS1(8), AF11(10), AF1= 2(12), AF13(14)
Range2=C2=A0 16-23=C2=A0 =C2=A0BK=C2=A0 =C2=A0 =C2=A0 CS2(16), AF21(18), AF= 22(20), AF23(22)
Range3=C2=A0 24-31=C2=A0 =C2=A0BE=C2=A0 =C2=A0 =C2=A0 CS3(24), AF31(26), AF= 32(28), AF33(30)
Range4=C2=A0 32-39=C2=A0 =C2=A0VI=C2=A0 =C2=A0 =C2=A0 CS4(32), AF41(34), AF= 42(36), AF43(38)
Range5=C2=A0 40-47=C2=A0 =C2=A0VI=C2=A0 =C2=A0 =C2=A0 CS5(40), VA(44), EF(4= 6)
Range6=C2=A0 48-55=C2=A0 =C2=A0VO=C2=A0 =C2=A0 =C2=A0 CS6(48)
Range7=C2=A0 56-63=C2=A0 =C2=A0VO=C2=A0 =C2=A0 =C2=A0 CS7(56)


IMHO RFC8325 and the whole WMM scheme clearly lacks data showing that is ac= tually delivers on its promises. RFC8325 specifically seems obsessed in cha= nging mappings such that PHBs align with the 4 WMM queues, instead of inter= preting the fact that the apparent mismatch between what the IETF thinks ab= out specific PHBs/DSCPs and how they are treated for most users, as clear s= ign, 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 applicati= ons seems taking an proven non-working idea to the extreme... (APs can alre= ady instruct stations on which DSCPs to map to which AC (see Felix's pa= tch), 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 an= y better).

Regards
=C2=A0 =C2=A0 =C2=A0 =C2=A0 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=C3=B8iland-J=C3=B8rgensen via Make-wi= fi-fast <make-wifi-fast@lists.bufferbloat.net> wrote:
>
> Jon Pike <= jonpike54@gmail.com> writes:
>
>> Heh...=C2=A0 So each and everyone in the stadium can have ALL thei= r data
>> prioritized above everybody else's!=C2=A0 For a more Egalitari= an world!
>>
>> Sigh...=C2=A0 =C2=A0Meanwhile, back in reality...
>>
>> An aside, is that commit in git a significant improvement on the m= appings,
>> 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@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/ma= ke-wifi-fast

_______________________________________________
Make-wifi-fast mailing list
M= ake-wifi-fast@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/make-wif= i-fast
--000000000000093df205d4d8da14--