Traffic shaping

Posted Mar 27, 2009 18:35 UTC (Fri) by kaber (guest, #18366)
In reply to: Traffic shaping by dion
Parent article: Nftables: a new packet filtering engine

Yes, I really want to have something useable for both myself.

I agree on the "designing to death" risk, but this is something that affects the API and because of that needs to be considered from the beginning. I'm about to finish the second-to-last missing part of the API (an API for maintaining sets independently of rules), hooking it up to TC will be the next and probably last bigger part.

Traffic shaping

Posted Mar 27, 2009 23:37 UTC (Fri) by rmayr (subscriber, #16880) [Link] (1 responses)

And please, please, *please* hook into ingress shaping as well. Yes, IMQ had bad code
quality, but it was understandable from a user point of view. IFB isn't and it doesn't work in
many cases important in practical scenarios. I have been dealing with ingress shaping for
the past 2 years and managed to get many Linux gateways deployed because of the
flexibility that combining netfilter marks with IMQ gave me. IFB so far doesn't seem to be a
capable replacement, and IMQ is broken with >= 2.6.27.

Traffic shaping is becoming more important by the month. It's time to let it become
manageable under Linux.

Traffic shaping

Posted Mar 28, 2009 13:25 UTC (Sat) by dion (guest, #2764) [Link]

I'd *so* like to second that! I've had the displeasure of having to do downstream traffic shaping systems with several downward interfaces and that means having to deal with an IFB interface or the silly limitations Linux has on ingress shaping at the moment.

Why is it that I can't simply pipe traffic via a queue from any arbitrary firewall rule?