Efficient use of Dummynet pipes in IPFW

[Brett Glass]

At 10:08 AM 9/19/2005, Jeremie Le Hen wrote:

>OTOH, I agree with Luigi about the "resume" keyword.  This introduces
>a kind of linked-lists, but this is just syntactic sugar and I can't
>see any performance improvement with this.

I think that a few examples might show why it'd be more than
syntactic sugar. Let's take the one I just sent to Luigi:

pipe 17 tcp from 0.0.0.1 to any 80 in via tun* established resume 5000

Let's look at how would you render this without the "resume 5000" at
the end. There are really three ways:

1) You could duplicate all of the conditions in a "skipto" rule, which
would be inefficient because all the matching would be done twice.

2) You could do a "skipto around a skipto", but this would require at
least four rules (including a final jump target) if you generated it 
automatically in one pass or wanted it to be maintainable by hand
without tedious manual renumbering.

3) You could DeMorganize, which is very inefficient on matching
packets and generates extremely complex rulesets. 

>This might be worth to have
>but I'm a little but scared about adding such options because there
>would be no reason then to not add other syntactic facilities, which
>would end up messing the whole syntax.

I am concerned about this too, and that's why I suggested "resume" as a
trailing option. IPFW rules currently have all kinds of trailing options,
involving everything from test for arcane TCP flags to "verrevpath"
(a firewall function which incurs a lot of overhead but is quite powerful).
A "resume" option wouldn't introduce any backward incompatibilities, and 
if the user didn't know about it, it would not get in the way.

I agree with you that the ability to negate the "AND" of all conditions
in the rule would greatly clarify some rulesets. I know it would help
with many of mine!

--Brett Glass