Qosify: new package for DSCP marking + cake

in my opinion, on wifi, applying the right dscp marks and landing in the right wifi queue on the clients matters more than doing so on the AP. Has anyone got anywhere on that part?

1 Like

OpenWrt snapshots allow to configure hostapd's qos_map_set feature which allows to define DSCP to AC mappings and that are distributed to the clients IIRC. But that still leaves the challenge of setting DSCPs on the clients.

Something where windows seems to be the easiest to configure, from my old notes:

# windows QoS: https://docs.microsoft.com/en-us/powershell/module/netqos/?view=win10-ps
Get-NetQosPolicy
# temporary -PolicyStore ActiveStore, otherwise omit -PolicyStore
New-NetQosPolicy -Name "putty" -AppPathNameMatchCondition "putty.exe" -ThrottleRateActionBitsPerSecond 1MB -PolicyStore ActiveStore -NetworkProfile All -DSCPAction 47 -WhatIf


New-NetQosPolicy -Name "putty" -AppPathNameMatchCondition "putty.exe" -PolicyStore ActiveStore -NetworkProfile All -DSCPAction 46

Get-NetQosPolicy -Store ActiveStore

Name           : putty_ps
Owner          : PowerShell / WMI
NetworkProfile : All
Precedence     : 127
AppPathName    : putty.exe
JobObject      :
DSCPValue      : 46

Remove-NetQosPolicy -Name "putty_ps" -PolicyStore ActiveStore

Seems to work, and I confirmed via tcpdump that putty's ssh packet originating from the windows VM host actually used DSCP 46 (aka EF). I note that powershell needs to be run as administrator, and the policies do not end up visible in Local Group Policy Editor. "-PolicyStore ActiveStore" will not survive a reboot, but for novice users that might be nice so a reboot cleans the slate in good windows tradition. I assume that after initial testing one could omit the "-PolicyStore ActiveStore" directive and store tested configs more permanently.
1 Like

zoom, microsoft meet, etc would be an even better test.

1 Like

what about wired, I now play games thanks to qosify and my rendering seems better with EF than with CS4, in diffserv4 yet CS4 is recommended for real-time gaming




in latency sensitive I see CS7 on the far left and CS4 on the far right

Does this have an impact on priority?

example CS7 much more priority then cs4 last

Sure there are better/more relevant test-cases than putty.exe, but the mechanism should be the same for any other application that is running from a single binary exe file. Not being a windows user myself, I have a somewhat hard time testing windows deeper :wink:

Your example works, this is how I set the policy to ensure my Parsec traffic in my WLAN is tagged as AF41 facilitating it landing in AC_VI queues.

1 Like

For cake diffserv4 CS7 and CS4 are effectively the same, both steer a packet into the Voice priority tin, as can be seen on one of your lists. For WiFi WMM however the difference is that CS4 should map into AC_VI, the video access class while CS7 maps into AC_VO the voice access class (keep in mind please, that voice and video really are just names im WMM and diffserv4, nobody is forced to map actual voice traffic into AC_VO or cake's Voice tin).

The likelihood of getting the next airtime transmit slot in WiFi increases in the following AC order:
AC_BK, AC_BE, AC_VI, AC_VO
but AC_VO for example does not aggregate for longish periods and hence will not be as throughput efficient as the lower AC_VI, and AC_BE IIRC.

So sure, if you actually use time critical application over WiFi, DSCP marking them such that they map into AC_VO can reduce their latency and jitter, but at a considerable throughput cost of the whole WiFi channel. That can well be an acceptable trade-off, just keep that in mind...

As I keep repeating prioritization is mostly a zero sum game, for any packet treated better some other packet(s) need to be treated worse. If such packets exist, fine, but if not then prioritization is not going to help much.

2 Likes

Thanks a lot for the clarifications,

my environment is entirely dedicated to the video game network, the wifi is really not important, my mobile phone is in 4G and my console connected in ethernet cat5E for the moment,

test now with cs7
tc -s qdisc

                   Bulk  Best Effort        Video        Voice
  thresh          1Mbit       16Mbit        8Mbit        4Mbit
  target         18.2ms          5ms          5ms          5ms
  interval        113ms        100ms        100ms        100ms
  pk_delay        3.1ms        137us          0us       2.15ms
  av_delay        228us         10us          0us        109us
  sp_delay         23us          3us          0us          4us
  backlog            0b           0b           0b           0b
  pkts             7595          514            0          480
  bytes          772428        74336            0       106640
  way_inds            0            0            0            0
  way_miss           37           12            0            1
  way_cols            0            0            0            0
  drops               0            0            0            0
  marks               0            0            0            0
  ack_drop            0            0            0            0
  sp_flows            2            0            0            1
  bk_flows            0            1            0            0
  un_flows            0            0            0            0
  max_len          3200         2726            0         1314
  quantum           300          488          300          300

qdisc ingress ffff: dev wan parent ffff:fff1 ----------------
 Sent 13872968 bytes 10473 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
qdisc noqueue 0: dev br-lan root refcnt 2
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
qdisc noqueue 0: dev wlan0 root refcnt 2
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
qdisc cake 1: dev ifb-wan root refcnt 2 bandwidth 56Mbit diffserv4 dual-dsthost nat nowash ingress no-ack-filter split-gso rtt 100ms ptm overhead 22
 Sent 14021136 bytes 10416 pkt (dropped 57, overlimits 16618 requeues 0)
 backlog 0b 0p requeues 0
 memory used: 690489b of 4Mb
 capacity estimate: 56Mbit
 min/max network layer size:           46 /    1500
 min/max overhead-adjusted size:       70 /    1546
 average network hdr offset:           14

                   Bulk  Best Effort        Video        Voice
  thresh       3500Kbit       56Mbit       28Mbit       14Mbit
  target         5.19ms          5ms          5ms          5ms
  interval        100ms        100ms        100ms        100ms
  pk_delay       5.45ms         77us          0us         39us
  av_delay       3.69ms          9us          0us          6us
  sp_delay          4us          4us          0us          4us
  backlog            0b           0b           0b           0b
  pkts             9746          361            0          366
  bytes        13961982        66647            0        78805
  way_inds            0            0            0            0
  way_miss           37           16            0            1
  way_cols            0            0            0            0
  drops              57            0            0            0
  marks               0            0            0            0
  ack_drop            0            0            0            0
  sp_flows            1            1            0            1
  bk_flows            0            0            0            0
  un_flows            0            0            0            0
  max_len          6056         3028            0         1330
  quantum           300         1514          854          427

root@OpenWrt:~#

So, actually for a diffserv4 this would be the things that would match everything:

				CAKE			WMM

tin0			LE				LE
tin1			CS0				CS0
tin2			AF41			AF41
tin3			CS7				CS7

While with diffserv8 you could not "sync" both CAKE and WMM.

1 Like

Not really, by default LE, decimal 1 will map into AC_BE IIUC... CS1 would map into cake tin0 (bulk) and AC_BK.

But really, as far as I am concerned the WiFi WMM tiers are not gospel and should be used sparingly as all prioritization. If you have a small fraction of your traffic that is especially latency sensitive, by all means up prioritize it but try to keep prioritization to a minimum. The point is fq_codel's and cake's default mild boosting of sparse flows does away with quite a number of special rules that people used/recommended in the past. This is not always true, but please first try how far you get with no/minimal prioritization. The fewer special rules you have the fewer rules can annoy you with unexpected side-effects.

EDIT: recent OpenWrt will map LE to AC_BK just fine, I am just not sure whether that only means snapshots or whether OpenWrt 20 is doing this already as well.

2 Likes

Agree, seems like LE is only implemented on devices with kernel 5.9 or higher, so better to set CS1.

In a home environment you usually have a router and a AP, so it should be better if you can sync them.

1 Like

i confirm than LE work on snapshot

config class bulk
	option ingress LE
	option egress LE

config class besteffort
	option ingress CS0
	option egress CS0

I just played with CS7 and the ports for the game and my game went really well, is it a placebo effect I can't say for the moment, but the tests seem good...

Im using pppoe with ipv6 enabled.
Do i need to setup anything else? or setting just interface 'wan' will work?
PPPOE dynamic create wan_6 interface when connected

1 Like

It looks like, Qosify is crashing from time to time. Nothing in the logs but qosify status stops reporting any values and tc -s qdisc reporting changing... Iam using qosify on current stable.

Officially there is no qosify on the stable 21.02
So, if you have tried to implement it there, you are pretty much on your own.

Iam aware of that. And the only missing dep is a lib which is anyway compatible. I just wanna Point that out.

I do see some sort of “crash” with qosify on snapshot. And by “crash” I mean that ubus call qosify dump returns an empty “entries” stanza, or sometimes it returns “Command failed: Not found”. Also, the readable files under /sys/fs/bpf/qosify_data revert to zero values.

If I had to guess, it’s related to dns: entries in the conf files, therefore I assume it’s something with ubus between dnsmasq and qosify.

Restarting qosify brings the config back, but it seems after I visit a site that has dns: entries in my conf file, it can crash (or reset, whichever is a more fitting technical explanation).

My snapshot revision is r18615 on a RPi4B. I notice qosify hasn’t been rebuilt by buildbot since December 22. Not sure if it’s relevant or not.

Can anyone corroborate my findings or suggest next steps? Pinging @nbd since he may not be watching the forums.

3 Likes

Thats exacly what i have under stable! Good Research.it feels like the project is dead :frowning:

No, Felix just has his hands in many other OpenWrt targets and projects — as a hobby, no less.

3 Likes

good evening how do I know if there is a leak in qosify because my qosify is running very well but degrades over time I have the impression here are my settings based again on script elan ^^, I only use for livestreams on twitch and fps gaming

config defaults
	list defaults /etc/qosify/*.conf
	option dscp_prio video
	option dscp_icmp +besteffort
	option dscp_default_tcp besteffort
	option dscp_default_udp besteffort
	option prio_max_avg_pkt_len 500

config class bulk
	option ingress CS1
	option egress CS1

config class besteffort
	option ingress CS0
	option egress CS0
	option dscp_prio video
	option prio_max_avg_pkt_len 500

config class high_throughput_data
	option ingress AF12
	option egress AF12
	option dscp_prio AF11
	option prio_max_avg_pkt_len 1200
	option dscp_bulk CS1
	option bulk_trigger_pps 700
	option bulk_trigger_timeout 60

config class network_services
	option ingress CS2
	option egress CS2

config class live_streaming
	option ingress CS3
	option egress CS3

config class video
	option ingress AF41
	option egress AF41
	
config class gaming
	option ingress CS4
	option egress CS4

config interface wan
	option name wan
	option disabled 0
	option bandwidth_up 16mbit
	option bandwidth_down 56mbit
	option overhead_type bridged-ptm
	# defaults:
	option ingress 1
	option egress 1
	option mode diffserv4
	option nat 1
	option host_isolate 1
	option autorate_ingress 0
	option ingress_options ""
	option egress_options "wash"
	option options "ether-vlan"

and cofnig default now

# DNS
tcp:53		network_services
tcp:5353	network_services
udp:53		network_services
udp:5353	network_services

# NTP
udp:123		network_services

# SSH
tcp:22		network_services

# DNS over TLS (DoT)
tcp:853		video
udp:853		video

# HTTP (TCP)
tcp:80		+high_throughput_data
tcp:443		+high_throughput_data

# QUIC (UDP)
udp:80		+besteffort
udp:443		+besteffort

# BitTorrent (TCP)
tcp:6881-6889	bulk
tcp:6969	bulk
tcp:51413	bulk

# BitTorrent (UDP)
udp:6881-6889	bulk
udp:6969	bulk
udp:51413	bulk

# Usenet
tcp:119	bulk
tcp:563	bulk

# Bulk
dns:*.backblaze.com		bulk
dns:*.backblazeb2.com		bulk
dns:*.ms-acdc.office.com	bulk
dns:*.windowsupdate.com		bulk
dns:*.update.microsoft.com	bulk
dns:*.onedrive.com		bulk
dns:*.1drv.ms			bulk
dns:*.1drv.com			bulk
dns:*.sharepoint.com		bulk

# Xbox (UDP)
udp:88		gaming
udp:500		gaming
udp:3544	gaming
udp:4500	gaming

# PlayStation (TCP)
tcp:1935	gaming
tcp:3074-3076	gaming
tcp:3478-3480	gaming

# PlayStation (UDP)
udp:3074-3079	gaming
udp:3478-3479	gaming
udp:3659	gaming
udp:30000-45000	gaming

# Zoom, Microsoft Teams and Skype - Them use the same ports.
udp:3478-3481		video
udp:8801-8810		video

# GoToMeeting
udp:1853		video
udp:8200		video

# Webex Meeting
tcp:5004		video
udp:9000		video

# Jitsi Meet
udp:10000		video

# Google Meet
udp:19302-19309		video

# FaceTime
udp:16384-16472		video

# TeamViewer
tcp:5938		video
udp:5938		video

# Live Streaming to YouTube Live, Twitch, Vimeo and LinkedIn Live.
tcp:1935-1936		live_streaming
tcp:2396		live_streaming
tcp:2935		live_streaming






would there also be a possibility to deactivate the down with a # or by putting 0 in mbits example -->

#option bandwidth_down 56mbit
option bandwidth_down 0mbit

1 Like