Knomax
390
Never mind, will wait for next working release.
1 Like
If I understand correctly qosify only knows the external IP addresses, so you need to figure out the IP address that is sending your video data and up-prioritize that IP (which honestly sounds a bit to broad for my taste, and tricky for services that serve data from multiple IPs).
Knomax
393
As i said ...will wait for next "working" release...will not try to find out every ip or site that sends data...to figure out to fall in etc in Video tin.
Many things must be fixed...i understand that is something new.
By the way...new release must be after release of new snapshot Openwrt?
1 Like
grrr2
394
Hi,
may I chip in at this point please? may overlooked it which case my apologies but i don't understand/see what is qosify's approach to the followings:
there are two methods i came across regarding how QoS is configured in (large) networks, i.e. trust vs un-trusted models.
trust model says whatever the end point (desktop, application, VoIP phone/video device) set it is accepted to be the right class, hence QoS engine only putting packets in the right queue and manages all the queues.
the un-trusted model on the other hand, does not care what is set by the end point but using a predefined set of rules to re-mark traffic [there are also different schools where to re-mark but is not that important for my question], only then this re-marked traffic is managed by QoS engine.
So my question is: an already classified traffic is trusted or not by qosify?
And to connect to the post am replying to, depending on the answer it maybe possible to mark traffic as wish on the desktop (ie. 192.168.1.150, all traffic or only some app's traffic via Windows QoS if it is a Windows machine), or setup firewall rules to mark all/some traffic with source of 192.168.1.150 and/or particular ports).
and my other question is: all major VoIP vendor recommends EF for Voice as far as I know, why CS6 is the default here?
thanks.
Your choice actually:
tcp:53 EF
tcp:5353 +EF
the first instructs qosify to replace what-ever DSCP value in a TCP packet from port 53 with "EF".
the second instructs qosify to only change the DSCP if that happens to be "CS0", if however a packet arrives with any DSSCP mark this rule will keep that original value. So your decision whether you want to trust your ingress traffic or not (if you trust it completely and do not want to make any changes, you do not even need qosify, but could e.g. use sqm if that floats your boat).
Yes that is possible, and for outgoing packets it is not a bad idea to corrdctly mark them at source, but for incoming packets the challenge is, if you want the ingress- cake instance to act on these DSCPs you need to have a way of setting them, which IIUC is the core problem that qosify solves, elegantly I might add.
Because DSCPs values per se have no meaning, that is you need to set up your own prioritization rules, so you can do whatever you please, heck you could make CS0 the highest priority. BUT since qosify uses cake it really hooks into the few predefined DSCP to priority tin mappings that cake offers, and these in turn are also aligned roughly with the priority mapping of WiFi (WMM). To recap, DSCPs are only what you make out of them, but qosify follows the interpretation hard-coded into cake. I hope this answers your question?
1 Like
grrr2
396
EF vs +EF, that's a great feature. thanks for pointing it out for me.
yup, incoming is usually the problem. I am really looking forward to get qosify be part of release.
finally, yes, i understand DSCP value can mean anything it is not fixed, and if tc-cake is using CS6 for Voice which is followed here, i appreciate that, though i think even in tc-cake would be better to recommend EF over CS6 to be inline with industry. which would be just a little reword in examples as EF is also recognized as voice in tc-cake too as I know, so either way it works. it is just strange to my eyes with enterprise voip background 
1 Like
There's nothing broken. DSCP tags for internal networks are not implemented, thats all. You can always tag manually with iptables.
There is a simply reason for that, WiFi WMM, EF (DSCP decimal 46) by default maps into WiFi's AC_VI and not the highest priority AC_VO, CS6 however maps into WiFI's AC_VO. cake itself treats CS6 and EF equally and puts them into its highest priority tin (see in the code):
static int cake_config_diffserv4(struct Qdisc *sch)
{
/* Further pruned list of traffic classes for four-class system:
*
* Latency Sensitive (CS7, CS6, EF, VA, CS5, CS4)
* Streaming Media (AF4x, AF3x, CS3, AF2x, TOS4, CS2, TOS1)
* Best Effort (CS0, AF1x, TOS2, and those not specified)
* Background Traffic (CS1)
*
* Total 4 traffic classes.
*/
Now, whether one actually wants to use AC_VO is a different question, but if one does then EF is not a good VoIP dscp (unless one can use qos_maps in hostapd to move F into AC_VO).
2 Likes
Yes, but that is too late to be useful for the ingress cake instance. nftables actually has a hook and could run at ingress but it seems to lack a way to peek into the conntrack tables from that position, IIRC.
2 Likes
Knomax
400
If i need to run iptables what is the benefit to use Qosify?Speed?
1 Like
Knomax
401
Anybody has idea about that?
1 Like
@nbd By default, I think bulk class would be better for defaults, As you can see, Torrents take over HTTP for example.
config defaults
list defaults /etc/qosify/*.conf
option dscp_icmp +besteffort
option dscp_default_udp bulk
option dscp_default_tcp bulk
option prio_max_avg_pkt_len 500
config class bulk
option ingress CS1
option egress CS1
and anything that isnt list below, wont get bulk'ed
# DNS
tcp:53 voice
tcp:5353 voice
udp:53 voice
udp:5353 voice
# NTP
udp:123 voice
# SSH
tcp:22 +video
# HTTP/QUIC
tcp:80 +besteffort
tcp:443 +besteffort
udp:80 +besteffort
udp:443 +besteffort
# VoIP
tcp:5060 voice
tcp:5061 voice
# TeamSpeak 3 VoiP
udp:9987 voice
# Mumble VoiP
udp:64738 voice
Latency Sensitive (CS7, CS6, EF, VA, CS5, CS4)
What higher? CS7 or CS4
Conceptually, neither DSCP are really just arbitrary 6bit-patterns that have no inherent meaning. IETF RFCs typically define per-hop-behaviour (PHB) and then propose a specific pattern to be used to request such PHB. Cake tried to collect a few of these proposed DSCPs and map those into priority tins that conceptually fit the associated PHB's and also rhyme with the WiFi WMM default mappings. But in the end which pattern signifies which priority treatment is arbitrary. In an ideal world end-points would set these DSCPs to signify their intent to the network and the other end-point, but in reality networks basically set and unset DSCPs values as they see fit for their own internal purposes (which is in compliance with the diffserv RFCs).
1 Like
amteza
405
Don't forget that now it happens by default as per how qos_maps is configured, see qos_map_set=0,0,2,16,1,1,255,255,18,22,24,38,40,40,44,46,48,56
1 Like
Mmmh, last time I looked (2019) hostapd was not configured with the required options for qos_map, if that changed by now I would be quite happy! I guess I need to install a recent main-snapshot and have a look.
amteza
409
You beat me to it, I was doing that exactly. 
Pretty recent, 4th of November.
3 Likes
