Thanks, it's my fault cause i captured packets on br-lan, so this will show tags on ingress only!
but is it better to use conntrack!, so it will ensure the tagging on both src and dest.
I think a length match like
--length 0:250 or maybe 0:350 makes more sense, do you see many VoIP or game packets larger than that range?
which app? 1280 bytes / 20ms is 512 kbps for voice, which is a huge amount. I think you can do ok video in that. Even g711 ulaw codec is only about 100 kbps including overhead.
this for imo, whatsapp, viber.
i don't know why packet size is growing by time!!!!
I grabbed your second packet capture and looked, what I see is a bimodal distribution of packet lengths. I think the data and some control information are traveling in the same UDP stream. Or perhaps the large packets are some kind of compression reset (like sending a new set of parameters or something). I isolated one conversation (based on ip address and ports) and found that there's a bunch of packets around 200-300 bytes or less and another bunch around 1000 bytes. Something like 1:640 bytes would capture about 60% of the stream. I'd suggest something like that.
Looking in your first packet capture (game), the maximum packet size is 555 bytes
So try out something like UDP packets with
--length 1:700. It's also the case that 700 bytes takes about 5.6 ms to send at 1Mbps so that's not an enormous delay in case you have a false positive.
Oh, nice analysis.
i will try 1:700 length,is it better to insert conntrack match with the same rule?
Conntrack match is probably much more intensive, as it has to keep track of statistics on the whole flow, but it will ensure the whole flow is prioritized not just the short packets, so it's up to you. Maybe try it with UDP conntrack avgpacket between 1:700 both directions... See how it works in a packet capture.
Edit: suggested rule:
iptables -t mangle -A OUTPUT -p udp -m connbytes --connbytes 0:700 --connbytes-dir both --connbytes-mode avgpkt -j DSCP --set-dscp-class CS6
Mmh, Not sure about marking different packets from the same flow with different dscps, this can lead to packet reordering at the receiver, which in turn might have some side-effects. Admitted, this is UDP not TCP but still, reordering seems better avoided.
So what is the right way to do it.
Cause port/ip is hard to guess and there's no available traffic identifier ?!
i will see if there's a noticeable side effects!
my plan is to prioritize the whole flow not just the short packets, but as you know it's not possible to match
port/ip cause it's change on every session!
i think it should be prerouting instead of output ?!
iptables -t mangle -A PREROUTING -p udp -m multiport ! --ports 53,80,443,60887 -m connbytes --connbytes 0:700 --connbytes-dir both --connbytes-mode avgpkt -j DSCP --set-dscp-class CS6
Yes makes sense for a router
Yes the reordering issue is a good reason to use the conntrack match, because it will match the whole flow.
when i used some rules to prioritize small tcp flags, now browsing is much faster when download or uploading.
even with full saturated up/down link will not affect game or browsing!
But do I still need to use length with conntrack!?, something like this:
$IPT -t mangle -A PREROUTING -p udp -m conntrack --ctorigsrc 192.168.1.0/24 -m multiport ! --ports 53,80,443,60887 -m length --length 0:700 -j DSCP --set-dscp-class CS6
No do the connbytes match I suggested with connbytes average btw 0-700 you can add the port exclusion if you like, like you did in your modified command from Ultimate SQM settings: Layer_cake + DSCP marks
Briefly for the first few ms to a sec or so the connection might go back and forth until the avg size stabilizes, after that the whole flow will be prioritized so long as it stays below 700 bytes. You might drop that to more like 550 or so, it's still catch your example packet capture.
Like this ?
$IPT -t mangle -A PREROUTING -p udp -m conntrack --ctorigsrc 192.168.1.0/24 -m multiport ! --ports 53,80,443,60887 -m connbytes --connbytes 0:700 --connbytes-dir both --connbytes-mode avgpkt -j DSCP --set-dscp-class CS6
port exclusion is important, you know that HTTP and HTTPS are bulky, also i'm already have a rules for them!
Yes that should work fine, the port exclusion will handle ignoring QUIC too so that's good.
Another thing you could add would be a rateest match, not only match small packets but also no more than say 300kbps for the flow... But I'm not sure how to do that, rateest match.