jim @
SmallWorks .
COM (Jim Thompson) said:
> Yet you connect to a network (anything running IP, or even plain old
> ethernet) that often does much worse. Go ahead, load your ethernet
> segment/router/... to the gills and measure just how often you *do*
> drop datagrams on the floor.
> [....]
> I agree with Adam, 3 out of 1,000 is hardly "a lot".
I think you and Adam are interpreting numbers at the incorrect network
level. Quoting from the actual article:
> Strong tpm results alone don't tell the whole story, since they don't
> take into account lost sessions. In our heavy-load scenario,
> firewalls had to field more packets in very rapid succession, with
> each packet having to be examined and forwarded before subsequent
> packets arrived. Firewalls that couldn't respond in time ended up
> dropping packets. If enough packets were dropped, retry limits were
> exceeded, leading to lost sessions
If the NSTL testing methodology descriptions were accurate, then what
we're talking about is TCP connection attempts timing out on the
client side because no (or possibly incorrect) response was received
from the firewall. This is much more serious than the same percentage
of IP packets being dropped on the floor (such as might occur on busy
Ethernets). A 5% packet collision rate on an Ethernet probably
results in only slightly degraded performance for users; however, a 5%
rate of failed connections (and there were several combinations of
vendor products and the number of established virtual circuits in
Table 3 in the article which had that loss rate or higher) would mean
that about 5% of attempts to access a given home page will time out,
and a much higher percentage of Web pages will be displayed with a
missing inlined graphic.
Would you want to be the firewall administrator answerable to your
site's users if that's how often they can't access what they want?
[By the way, my defense that "3 out of 1,000" is in fact quite "a lot"
does not constitute general approval of the assumptions made by the
article's writers about what's important in evaluating firewalls, or
of the NSTL testing methodology as a whole.]
--
Ping Huang <pshuang @
sgi .
com> | Voice (415) 933-6256 | FAX (415) 390-6159
Silicon Graphics, Inc., 2011 N Shoreline Blvd. 1L-945, Mt. View CA 94043
Disclaimer: unless explicitly otherwise stated, my
statements represent my personal viewpoints only.
|
|
