I’n not sure if I’ve hit a bug here, or if I’m missing something.
I have one device with an address .
In the postrouting chain of the mangler I have connection marker which checks if that IP matches a Layer7 protocol regex of ".googlevideo.com". If this rule matches, it sets the connection mark to "cm - streaming". It's a passthrough mangling rule.
The next rule, which checks if connection mark matches "cm - streaming", sets a packet mark "pm - streaming" upon finding a match. It's not a passthrough mangling rule.
~~~~~ Queues -- In the Simple Queues I have two rules ~~~~~
One queue #1 named "<IP> - all traffic" does match if Target == <IP>. There I have set a generous download bandwidth.
Another queue #2 named "<IP> - streaming" which does match if Packet Marks contains "pm - streaming" and has set Parent == "<IP> - all traffic" and a restrictive download bandwidth.
~~~~~ Problem ~~~~~
Queue #2 DISABLED -- all OK:
When polling SNMP data on queue #1 and queue #2, then queue #1 shows the exact count of octets passing through the queue, in and out. I get a precise usage graph in rrdtool. queue #2 is always 0 as expected, since it is disabled.
Queue #2 ENABLED - queue #2 OK, queue #1 NOT OK:
When polling SNMP data on queue #1 and queue #2, then both show the count of queue #2. All traffic of <IP> that does not match the "pm - streaming" packets, ie checking email, is not showing up in queue #1 (not even in the webfig graphs and bytecounts), even tough it should. The "Target Download - Max Limit", which is set to 25M in queue #1 is getting ignored, absolutely no limit is applied for queue #1, and only ".googlevideo.com" is getting limited to "Target Download - Max Limit" to 4M in queue #2 as it should. It's the counting in queue #1 that appears to be buggy, as it mirrors queue #2, and the limit in queue #1 which should get applied to all packets not being marked as "pm - streaming" is getting ignored.
\
\
~~~~~ Summary ~~~~~
I think this is a problem in how the octets in the parent queue are getting count. Regardless of packets matching the child queue, the octet count in the parent queue is always the same as the one in the child queue, therefore I get a behaviour where in rrdtool both graphs show only what occurs in the child queue. Also, the rules set in queue #1 have no effect, queue #1 only counts io-bytes of queue #2 and does not impose any of the Max-Limit (also not ones of queue #2)
I think you shouldn’t use the parent / child queue thing for simple queues (but I’m not an expert with queues, so your mileage may vary).
Simple queues get matched in order somewhat like firewall rules - so if you made the current Queue#2 be first in the queue list and set the same target=all IP, but also require the packet marks, then that should cause it to only catch the streaming traffic, and all remaining traffic should hit the other queue. Then set a guaranteed minimum for each queue, and use priorities to prioritize “normal data” over the streaming data when both queues are above limit-at rate. Set both to allow max-limit of full bandwidth (or reduce the streaming queue if you want to - there’s no reason not to let it have the whole pipe if the main queue isn’t requiring service)
When you set the parent/child relationship, all traffic must first flow through the parent queue before reaching the streaming queue, which is why the parent queue shows all traffic. You would need to create another “default” child queue - sibling to the streaming queue, and THAT is where you could enforce limits on the non-streaming data. Basically, the parent queue only becomes a “token bank” and since there is no default child queue sibling to the streaming queue, all the packets are just falling out of the system and not being queued anymore.
Thanks ZeroByte for your help, you brought me on to the right track.
This is exactly what doesn’t seem to be true. As I said, the parent queue is only showing the same traffic the pm-streaming queue is showing. All traffic that isn’t a pm-streaming, also doesn’t get counted by the parent queue, which I find is very odd.
I’ve been thinking this over, and came, with your help, to the following conclusion: the parent queue doesn’t have a real queue at all. It only aggregates the summary of its children.
I did as you said, added a second “catchall” child queue, sibling and below the pm-streaming queue, which then is the real queue for all non-pm-streaming packets. The summary of this new queue is then (apparently internally) added to the pm-streaming queue summary, and transferred to the parent queue. So now my SMTP counters on the parent queue show all flowing data, this is what I wanted.
In hindsight this makes sense, because if the parent queue had a real queue, then it would add it’s latency to the child queues, with no real benefit at all, as a “catchall” sibling queue would have the same queuing effect, without the latency (and cpu-processing) getting added.
I think that this behaviour should get a big fat “Note” in the Queue Documentation, as using a parent queue for accounting could then lead to missing bytes, if the children aren’t configured correctly.
On the other hand, it could be kind of beneficial to optionally set the parent queue to have a real queue, which then, after doing all its processing, performs a passthrough for the additional child queues do some more specific queue handling on the already processed data of the parent.
That would save some extra work, if you know you have some base settings for a specific device, and don’t care about the additional latency / cpu overhead.