Tag traffic based on state bytes?



  • I would like to kick http/https sessions with for example > 2MB transferred to a lower queue, that way browsing gets higher priority than downloading/streaming. I can't find a way to do it with floating rules, am I missing something? It doesn't necessarily have to be state bytes as long as we can use it to make the distinction.

    Thanks.



  • My understanding is the queue is locked in at the time the state is created. You can't know the future. Just use something like CoDel or FairQ, which bias towards punishing heavy flows. 99% of the time when someone wants to make things "faster", they're really talking about bufferbloat, not priorities. Try fixing bufferblaot before making convoluted rules like "first 2MiB in high priority then lower after.



  • @Harvy66:

    My understanding is the queue is locked in at the time the state is created. You can't know the future. Just use something like CoDel or FairQ, which bias towards punishing heavy flows. 99% of the time when someone wants to make things "faster", they're really talking about bufferbloat, not priorities. Try fixing bufferblaot before making convoluted rules like "first 2MiB in high priority then lower after.

    I'm coming from a Mikrotik background so forgive me if I'm overlooking some core concepts, I didn't know the queue was locked in when the state gets created, in routerOS I could mangle by "connection bytes" and mark accordingly.

    I have a decent PRIQ setup now and I will try CoDel and FairQ next. I'm not trying to make things "faster" but fair. I would like to classify streaming, then make sure each tenant gets a fair amount bandwidth while giving regular browsing priority. I'm open to suggestions if you have some.

    Thanks.



  • @deagle:

    I would like to classify streaming, then make sure each tenant gets a fair amount bandwidth while giving regular browsing priority. I'm open to suggestions if you have some.

    Interesting thing to know about networks, assuming not super slow like below 10Mb. At any given time, there are only dozen or so flows of packets in the buffer, and nearly all of the packets are from the single digit heaviest of data flows. This rule of thumb applies from a 133Mb link serving 500k active flows, to 10Gb links also handling 500k flows.

    This means a few things are happening

    1. When a tail-drop buffer is full, the smaller flows get hurt the most because they lose the most packets percentage wise.
    2. A select few flows monopolize the network and it's hard for any other TCP flows to get in edge wise

    CoDel and FairQ break this up. In the case of Codel, it's primarily head-drop and is a time based buffer. This means a few things

    1. There's almost always room in the buffer, allowing small flows to make it in instead of getting tail-dropped
    2. CoDel is most likely to drop a large packet from a fat flow

    Unless you have a really low bandwidth link that is completely overwhelmed, CoDel will help maximize bandwidth, minimize latency, minimize loss, and redistribute bandwidth by dropping packets from the fatest of flows freeing up bandwidth for other flows to move in.

    I recommend trying this approach first. fq_Codel and eventually Cake will be much better at this. fq_Codel already works wonders, but Cake has a lot more features, but it's also taking longer than expected because of performance regression caused by so many features added. Unfortunately PFSense only has Codel right now, but that alone is the 80/20 rule.


Log in to reply