Ultimate SQM settings: Layer_cake + DSCP marks


#342

@fuller
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.


#343

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?


#344

yeah, as i said it's rise slowly from 60 to 1208 for voip, and from 45 to 555 and maybe more!
https://a.uguu.se/VRNnPGVgzmYq_mi8-new.pcap pubg-mobile game.
https://a.uguu.se/u70eYvngCC4G_y6.pcap voip


#345

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.


#346

this for imo, whatsapp, viber.
i don't know why packet size is growing by time!!!!


#347

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.


#348

Oh, nice analysis.
i will try 1:700 length,is it better to insert conntrack match with the same rule?
like this:


#349

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

#350

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.


#351

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!
@dlakelan

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!


#352

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

#353

Yes makes sense for a router


#354

Yes the reordering issue is a good reason to use the conntrack match, because it will match the whole flow.


#355

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!


#356

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


#357

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.


#358

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!


#359

Yes that should work fine, the port exclusion will handle ignoring QUIC too so that's good.


#360

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.


#361

Man page:
http://ipset.netfilter.org/iptables-extensions.man.html#lbBU