All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Heinz <creatix@hipac.org>
To: Tobias DiPasquale <codeslinger@gmail.com>
Cc: netfilter-devel <netfilter-devel@lists.netfilter.org>
Subject: Re: iptables as a state machine
Date: Sat, 02 Oct 2004 23:52:00 +0200	[thread overview]
Message-ID: <415F2300.2020609@hipac.org> (raw)
In-Reply-To: <876ef97a0410021401429a429b@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1326 bytes --]

Hi Tobias

You wrote:
> What about using a n-ary PATRICIA trie to solve this problem? That
> would yield O(1)-time matching of rules and the data pointer for each
> node in the tree could be the list of targets that apply to that
> particular IP/subnet? Not sure how ranges would work yet, though if
> they didn't fit into a CIDR block...

Maybe you want to have a look at the following paper.
http://tiny-tera.stanford.edu/~nickm/papers/classification_tutorial_01.pdf

It provides a very good overview of a wide range of different
approaches towards packet classification.

There are two basic trie-based approaches presented in the paper.
1) hierarchical tries
    lookup time:        O(w^d)
    storage complexity: O(n * d * w)

2) set-pruning tries
    lookup time:        O(d * w)
    storage complexity: O(n^d * d * w)

n: number of rules
d: number of dimensions (such as source ip, dest. ip, protocol)
w: bit width of largest header field

As you can see from the performance complexity both approaches
are not desirable for d > 1.


BTW, every range in [0, 2^w - 1] can be expressed by at most
2*(w-1) prefixes. Hence, if you have a single rule with d range
matches, you need at most (2*(w-1))^d rules with prefix matches
to express the _single_ range rule.

Sounds not very promising, does it? ;-)


Regards,

Thomas

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 251 bytes --]

      reply	other threads:[~2004-10-02 21:52 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-01  2:39 iptables as a state machine David S. Miller
2004-10-01  3:47 ` shemminger
2004-10-01  4:01   ` David S. Miller
2004-10-01  8:24     ` Thomas Heinz
2004-10-01 19:46       ` David S. Miller
2004-10-01 20:26         ` Thomas Heinz
2004-10-01 20:33         ` Stephen Hemminger
2004-10-01 11:12     ` Henrik Nordstrom
2004-10-01 12:06       ` Henrik Nordstrom
2004-10-02  8:44   ` Roberto Nibali
2004-10-02 14:42     ` Henrik Nordstrom
2004-10-04 10:04     ` Jozsef Kadlecsik
2004-10-04 15:51     ` Stephen Hemminger
2004-10-01 20:06 ` Gonzalo A. Arana
2004-10-02 21:01 ` Tobias DiPasquale
2004-10-02 21:52   ` Thomas Heinz [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=415F2300.2020609@hipac.org \
    --to=creatix@hipac.org \
    --cc=codeslinger@gmail.com \
    --cc=netfilter-devel@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.