Great, I am no fan of RFC8325, but I am a fan of having this capability in OpenWrt!
This won't get triggered as you have set dscp default tags to other class. You have to set them in bulk priority.
I don't think so, with bulk_trigger_pps you can make downloads to go to the bulk tier.
Does qosify work with hardware offloading enabled? or does it conflict similarly as it does with SQM?
Personal choice how people like there QoS setup however this was here by default bulk_trigger_pps.
Point i was trying to make was, by default when installing Qosify P2P takes over WWW traffic as you can see here
Best for you at the moment @Knomax is luci-app-qos (qos-scripts) if yo need to do fancy IP stuff for now
opkg update
opkg install luci-app-qos
Go Luci > Network > QoS
Based on
kmod-ipt-conntrack-extra.
kmod-sched-connmark.
kmod-ipt-raw.
kmod-ipt-ipopt.
iptables-mod-ipopt.
iptables-mod-conntrack-extra.
qos-scripts.
How? I do not think that qos-scripts solved the "getting access to internal IP-addresses before the traffic shaper gets hold of packets" problem. But it is ages I last looked at that code, so I might well be wrong here.
CS6 imho should not be used for voice. I would also really like people showing measurable benefits of all this work by posting tc -s qdisc show for cake, and also inspecting the aqm files for wifi for usage, drops, and marks in those queues.
Secondly, I'm not sure if sparseness is well understood as yet. A fq-aqm'd scheduled flow counts as "sparse" when a quantum's worth of bytes are delivered from it, and all other flows are served, before another quantum arrives. In the context of DNS, pretty much all udp or tcp transactions count as sparse, and in the case of nailed up TLS/DOH/DOT/whatever, it's relative to the typical size, back-to-backness and number of queries pushed through that pipe that can be served in that quantum. I'm still not really sure if that helps!
I would enjoy seeing a packet capture of an entire web page load through these more advanced DNS techniques. Try, say, one of the most sharded sites in the world - www.cnn.com.
I would guess that most VoIP apps that do mark use either EF(46) or VA(54), so no CS6. However in normal WiFi WMM EF maps to AC_VI, while VA maps to AC_VO.
Since a recent change however linked above OpenWrt will use the following 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 according to the following hostapd rules:
### hostapd/wpad qos_map
# QoS Map Set configuration
#
# Comma delimited QoS Map Set in decimal values
# (see IEEE Std 802.11-2012, 8.4.2.97)
#
# format:
# [<DSCP Exceptions[DSCP,UP]>,]<UP 0 range[low,high]>,...<UP 7 range[low,high]>
#
# There can be up to 21 optional DSCP Exceptions which are pairs of DSCP Value
# (0..63 or 255) and User Priority (0..7). This is followed by eight DSCP Range
# descriptions with DSCP Low Value and DSCP High Value pairs (0..63 or 255) for
# each UP starting from 0. If both low and high value are set to 255, the
# corresponding UP is not used.
Expand 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 EF(46), VA(44)
Range7 48-56 VO CS6(48), CS7(56)
EDIT: corrected wrong value and range for VA, thanks @grrr2
Which will put all of EF, CS6, VA, CS7 into AC_VO... probably based on the assumption that an IETF RFC's recommendations are sane. (A view I subscribed to in the past, and I am still hoping this to be true for RFC8325, but the whole L4S rubber-stamping exercise in spite of well-documented design errors makes me fear for the worst).
Well, testing is good.
I really really really don't support the use of VO for wireless-n. The VI queue has, overall, much nicer properties for most traffic regardless.
2 Likes
I think this would be the correct table, might be wrong but i recall VA is 44 not 54:
| Range6 | 44-46 | VO | VA(44), EF(46) |
|---|---|---|---|
| Range7 | 48-56 | VO | CS6(48), CS7(56) |
and assuming the config above follows RFC8325 it is recommended as well like this:
Similarly, the VOICE-ADMIT DSCP (44 decimal / 101100 binary) described in [RFC5865] is RECOMMENDED to be mapped to UP 6, thereby admitting it also into the Voice Access Category (AC_VO).
2 Likes
Mmmh, the only real differences are slightly less lop-sided sharing behavior with AC_BE and longer temporal aggregates. The second point however has the potential to noticeably increase the goodput achieved in a WiFi network. Which other property differences am I missing?
Fchk yes, I was doing this accidentally in base8 not base10.... Thanks for catching that! I will correct it.
That is I used a calculator accidentally set to base8, I do not usually think in base8, and if I do Ithen not accidentally..... 
1 Like
Worked for me for a number of years with a old DSL-ADSL 2 line however this was more of private LAN to guest LAN. e.g separate subnets 192.168.1.0/24 & 192.168.2.0/24 so making our private LAN are first priority for traffic for in/out
Anyway it was more of a "for now solution" as @Knomax looked like he needed something for IPs,
how can I install qosify ? i can't find it on openwrt
1 Like
Same issue here. Either I'm doing something exceptionally stupid or perhaps it's not been compiled for my router (a Linksys WRT-3200 ACM).
It’s available only for snapshot builds for now. Are you running a snapshot?
You can also Download the ipk (and the two dependencies) manually and install them to the current live build (it works for x86/amd64 at least)
can cake and qosify coexist or just qosify?
I did a little test using iperf3 which supports tos/dscp marking. with an additional conf file (iperf.conf) in the /etc/qosify with this very simple content:
# iperf
tcp:5201 +video
my test was like:
# iperf client with qosify on
# .201 is the iperf server
# .212 is WAN address of client (it is VM so don't get confused traffic is through WAN interface)
iperf3 -c 192.168.1.201 -t1 --dscp CS2
# server side
iperf3 -s
# running on client
tcpdump -iany -n -v 'host 192.168.1.212 and tcp port 5201' | awk '/IP \(t
os/ {tos=substr($4,1,length($4)-1); next} {printf("%s > %s tos=%s\n",$1,$3,tos)}'
192.168.1.201.5201 > 192.168.1.212.33308: tos=0x88
192.168.1.212.33310 > 192.168.1.201.5201: tos=0x88
192.168.1.212.33310 > 192.168.1.201.5201: tos=0x88
192.168.1.201.5201 > 192.168.1.212.33310: tos=0x88
192.168.1.201.5201 > 192.168.1.212.33310: tos=0x88
192.168.1.201.5201 > 192.168.1.212.33310: tos=0x88
my expectation was that as I mark traffic with CS2 the +video will not overwrite TOS, but 0x88 is AF41 which is the video class.
# without iperf.conf it works as expected
192.168.1.212.33318 > 192.168.1.201.5201: tos=0x40
192.168.1.212.33318 > 192.168.1.201.5201: tos=0x40
192.168.1.201.5201 > 192.168.1.212.33318: tos=0x40
192.168.1.201.5201 > 192.168.1.212.33318: tos=0x40
am i doing something wrong? or +xxx notation means something different and will overwrite regardless TOS/DSCP value?