From: buck on
Andrew Gideon <c182driver1(a)gideon.org> wrote in news:hGh6o.553$au.494
@news.usenetserver.com:

> On Wed, 04 Aug 2010 17:37:35 +0000, buck wrote:
>
>> I dislike IFB.
>
> Why? How is IMQ better/different [for shaping over multiple
interfaces]?
>
> - Andrew

Did you visit the link I provided? Also have a look at the IMQ wiki:
http://wiki.nix.hu/cgi-
bin/twiki/view/IMQ/ImqFaq#What_can_I_do_with_IMQ

See also
http://www.linuxfoundation.org/collaborate/workgroups/networking/ifb

The short answer is that IMQ allows everything availabe to an egress
QoS while IFB does not.

The reason that IMQ still exists is that many people consider it to be
superior to IFB. Were that not true, nobody would take the time to
maintain patches for IMQ.
--
buck
From: Arimus on
On Aug 5, 10:33 pm, buck <b...(a)private.mil> wrote:

> See alsohttp://www.linuxfoundation.org/collaborate/workgroups/networking/ifb
>
> The short answer is that IMQ allows everything availabe to an egress
> QoS while IFB does not.
>
> The reason that IMQ still exists is that many people consider it to be
> superior to IFB.  Were that not true, nobody would take the time to
> maintain patches for IMQ.


I'd forgotten IMQ - the last time I played with tc in anger it was on
systems with mixed bandwidth interfaces so each interface needed its
own (bandwidth and protocol) specific parameters, but if each
interface has a common set of properties then IMQ is certainly the way
to go - lot simpler maintaining a single set of queues rather than one
per interface...

From: Andy Furniss on
buck wrote:

> The short answer is that IMQ allows everything availabe to an egress
> QoS while IFB does not.

AFAIK the only case where IMQ is ever needed over IFB is if you are
nat-ing onto a single ip address both traffic from the shaping box and
forwarded traffic, and you then want to shape the ingress traffic from
the nat-ed interface taking it's destination into account. Because IMQ
hooks after it has been de-nated you can tell the difference between
packets headed for a local process and that to be forwarded to lan. With
IFB you can't as it hooks before the de-nat.

If you are not in that position, IFB can do anything IMQ can - you can
redirect from ingress or egress to ifb and thus use any qdisc you like.
From: Andy Furniss on
Andy Furniss wrote:

> AFAIK the only ...

Maybe only was wrong - if you use connmark or similar and need to shape
inbound to a local process the same would apply - if you are forwarding
however, you could still use IFB.