Re: RE: High Speed Firewalls

[Paul Boyer <paul.boyer () paulboyer org>]

Crispin Cowan wrote:
>
[...]
> You need a precisely measurable amount of parallelism to handle that.  If the
> cars go from 65 MPH to 6.5 MPH (on average through the toll gate) then you need
> to go from 2 lanes to 20 lanes.  Is that "a hell of a lot"?  Sure, it's more
> than most toll plazas that I've ever seen, but most traffic authorities are not
[...]

The problem with cars is the same with packets: the enemy is collision
;-)

The observed maximum throughput on a motorway is reached at
approximately 15 MPH, when the cars are best driven bumper next to
bumper, minimizing the dreadfull congestion impact of sudden collision
or near collision effect, causing a total stop for a few moments.
This is a French data indeed, maybe the US drivers drive slightly
closer at higher or lower speed.

This can be seen as a consequence of fluid mecanichal theory, showing
that speed depends on pressure the opposite way : when speed increase,
pressure decrease, and vice versa.

All this is only to illustrate that latency affects throughput in
several ways that are not always intuitive.
For example, in some special cases a not null latency firewall could
increase throughput by simply discarding some duplicated (reemissions)
packets. Also packet reassembly, provided by every decent firewall
will play a major role at increasing throughput in some cases, let
alone discarding dumb "lost" packets.

I agree with Crispin that with enough CPU and memory, a firewall will
not be a throughput bottleneck, while it will always be contributing
to the latency. 
However, one counter example was the (totally harshly not RFC
compliant and buggy...) implementation of the syn gateway on old FW-1
that was sending Syn/Ack before forwarding the syn to the target
server, and sending the initial Syn to the target host only when the
third packet (the final ack of the 3 way handshake) came. In many
cases, that was reducing latency.

Paul