Re: RE: High Speed Firewalls

[Crispin Cowan <crispin () wirex com>]

David Newman wrote:

> >    * if the power of the toll both is sufficient, then all
> > cars/packets get
> >      their own booth upon arrival, and throughput is not affected
>
> Cars slow down when approaching and toll booth speed up going away from it,
> and that affects their "throughput." Ditto packets traversing firewalls.

Not if the acceleration lanes are wide enough:  20 lanes of traffic moving at
10 MPH has the same throughput as 5 lanes of traffic moving at 40 MPH.
Similarly, a "full speed" firewall may need to have several NICs on each side.
Parallelism solves many throughput problems, but rarely benefits latency
(except for reduced queue length).


> On some highways in Colorado (and probably elsewhere, but this is where I
> saw them) cars with toll passes pass through tollbooths *at speed.* I'd love
> to see something like this applied to firewalls. However, all the
> implementations I'm aware of today do some kind of slow-path
> inspection/learning/path selection before setting up a high-speed flow.

Working our analogy some more, this is akin to reducing the compute load on the
firewall.  "high speed flow" == "low effort flow".  Do that as much as you
(securely) can.  When you can't think of anything else, and you still want it
to provide more throughput, then throw parallelism at it.

> From a brief glance at the Rainnet web site, it appears that this is what they
do.  The art is in how well they do it such that the parallelism actually does
deliver enhanced throughput.  Poorly placed interlocks (think of pipelined CPUs
or SIMD computers) can reduce a very parallel machine to its sequential speed.
At this point we return to actual benchmarking of products, where I ascede to
Newman's benchmarking experience.

Crispin
-----
Crispin Cowan, CTO, WireX Communications, Inc.    http://wirex.com
Free Hardened Linux Distribution:                 http://immunix.org
                  JOBS!  http://immunix.org/jobs.html