Can DUMMYNET handle weighting of traffic according to firewall rules?

[Patrick Tracanelli]

> On 14/12/2014, at 14:25, Brett Glass <brett at lariat.net> wrote:
> 
> At 11:02 AM 12/13/2014, eksffa at freebsdbrasil.com.br wrote:
>  
>> As I understand the problem, there are many ways to do this without actually using any special feature on dummynet. From tagging a traffic twice and feeding both tagged flows to the same pipe, to the easiest and possibily lighter approach of disabling one pass and feeding the traffic twice to the same pipe.
> 
> Unfortunately, feeding the traffic to the same pipe more than once would have some undesirable side effects. It would mean incurring X times the delay and computational overhead introduced by the pipe.

Yes, it would. But should only be a big deal if you have too much pps and low CPU to deal with the volume.

> This would affect not only latency but also jitter, because DUMMYNET pipes are driven by timer interrupts.

I don’t quite agree, if you have enough CPU to pipe it together. I run a number of setups where a WF2Qp or QFQ setup does the weighting and later an extra pipe imposes other individual limits.

Proper queue and HZ tuning tend to do the job while you have enough CPU to deal with interrupts.

> Even if you set the kernel's HZ setting to a high number, you could have milliseconds of difference in the latency depending upon a packet's precise arrival time and the amount of traffic. If DUMMYNET was in "fast" mode, there would also be a very big jump in latency when the pipe neared capacity.

This is just theory. And I don’t mean it’s wrong. There could certainly be a better way to add an extra cost factor to a flow, but the pure fact is you don’t have it today. Let’s be practical, how much bw are we talking about and how much CPU? 

Even if we are talking about a lot of bandwidth, you have many tuning possibilities and you have netmap-aware dummynet to deal with high pps rate.

> X could only be a whole number unless you fed the pipe multiple times in EACH direction.

As I understand your problem you would need to feed a flow in the opposite direction to the same pipe anyway.
So it’s just a matter of 3 flows instead of 2. I insist, not the beautiful approach, but not a big deal, unless we are talking about 10G/40G connections or a server with 10yo computing power.


> And turning off the "one_pass" feature would add to the overhead of EVERY pipe used in the system.

That’s not true. Having one_pass disable is a mostly a needed feature if you have complex environments with a mix of filtering and queueing, otherwise a single match in a pipe will result in a pass behavior. If you don’t match a traffic twice to a pipe one_pass will make not difference to dummynet at all, adding no overhead. Remember that one_pass is an ipfw feature, not dummynet specific, and if overhead will be added anywhere, it’s on ipfw that will just keep the packet injected and keep processing until a filtering match is found, which can be the next rule. 

> It would be much more desirable to be able to specify a cost factor for a packet entering the pipe, as Luigi mentioned, so that the pipe could simply adjust its "score" to reflect the higher overhead of upstream vs. downstream traffic.

Sure it would be more desirable not just for your needs, but for dummynet feature set as a whole. But that’s just not something you have today.

> If it's really a one-line patch to the kernel, I'd like to try doing this and then submit a patch to add the feature if it works.

That would be great for sure.
But as Luigi mentioned this is not that simple for the UI which seems many times to be more complex to extend than the kernel features itself, without breaking other stuff or requiring .h handling somehow that would make a -STABLE merge not simple.

But anyway, after adding a cost factor and handling UI extending, how would you solve the need to inject both RX and TX traffic to the same pipe? You will need to match it twice against the same pipe anyway. No 3 times but twice at least, no matter with or without one_pass.

> 
> --Brett Glass

--
Patrick Tracanelli