I would agree here. Things like maximum concurrent connections and how many
connections/second need to be considered as well. Personally I prefer
hardware simply for the stability factor. There's nothing like having to go
reboot the firewall server at 2am...grrr. Been there, done that, burned the
t-shirt.
----- Original Message -----
From: "Howard C. Berkowitz" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, February 01, 2001 11:28 AM
Subject: "Wire speed" (wasRe: What should I block???)
> >PIX is wire-speed, hardware based! Checkpoint is based on the box you
have
> >it installed, which could be better than PIX's box... agreed!, but it is
> >also software based.
> >
> >CheckPoint does have an embedded hardware based box made by NOKIA, but
that
> >market is not doing so well.
> >
> >Khalid Khan
>
> "Wire speed" and "hardware based" come up often in many discussions,
> but need to be taken with MANY grains of salt. By and large, they are
> marketing hype.
>
> *************************************
> On Wire Speed (but what about fiber?)
> *************************************
>
> Start by considering that the packet rate _must_ be less than the
> "wire" transmission rate on "wires" using encoding such as 4B/5B or
> 8B/10B.
>
> There's been a recent discussion thread on the IETF Benchmarking
> Methodology Working Group mailing list about whether "wire speed" is
> a terribly useful or meaningful term. The consensus is that it is
> not. A couple of expert comments:
>
> >At 8:27 PM -0500 1/19/2001, Scott Bradner wrote:
> >
> >
> >> RFC 2544 and its' parent 1944 don't use the term wire-speed.
> >
> >and I think that was an omission
> >too many people are using the term "wire speed" in their own ways
> >
> >Internet average packet size, Internet packet size mix, and minimum
> >sized packets are all definitions I've seen - to me its only the last
> >one that makes sense
>
> At 7:41 AM -0500 1/22/2001, Jim McQuaid wrote:
> >I agree with Scott. The only meaningful definition is handling the
maximum
> >possible frame rate, i.e. the minimum size packets. This is the
"implied"
> >definition of wire speed, even if the reality is quite different.
> >
> >Every so often there has been discussion of "average" traffic or
"typical"
> >traffic. It is possible to imagine coming up with some defined 'bag of
> >frames' that represents "typical traffic" but in reality the consensus is
> >never there. There is no such thing as ""typical" traffic for testing
> >purposes. The well-defined (if artificial) traffic loads of 2544 and
others
> >are the workable, implementable and consensus ways to do this, it seems.
> >
> At 8:47 AM -0800 1/22/2001, David Newman wrote:
> > > I would say the wire rate is 10Gbps because the physical interface
> >> is able to forward 10Gbps.
> >
> >No
> >
> >Some physical media ALWAYS operate at X bits per second, regardless of
> >whether they carry packets. A measurement that says "this interface
operates
> >at X bit/s" isn't terribly meaningful if the forwarding rate is 0 pps.
> >
> At 3:07 PM -0800 1/25/2001, Ramesh Menon wrote:
> >>I posed this question originally but had to drop out of
> >>the thread for a bit. Jambi, thanks for guiding it back
> >>to the original question.
> >>
> >>Jim, you asserted in an earlier mail:
> >>"Let's focus on the goal. If it is to benchmark for router
> >>performance, we have what we need."
> >>
> >>Routers are not the only interesting devices our there that
> >>need benchmarking. The great thing about 2544 is that it can
> >>used for benchmarking NICs, analyzers etc. The design (and
> >>price point) for a lot of these are different from routers.
> >>Some of these have no concept of forwarding and as such are
> >>are optimized for other metrics, including price/performance.
> >>While it may do less than 100% at 64 byte frames it can keep
> >>up with every situation out there bar synthetic traffic.
> >>
> >>The reality on the ground is that it is not easy for engineers
> >>in companies with marketing departments to go out and say that their
> >>card (not *router*) can keep up with only 75% at the smallest frame
size.
> >>This is even if none of their customers would care.
> >>
> >>Quoting Jim again "... "implied" definition of wire speed, even if the
> >>reality is quite different". I have spent quite a bit of time on
standards
> >>bodies before and I would argue that if we don't take *reality* into
> >>account,
> >>we are quickly going to be written off to oblivion. DUT vendors that can
do
> >>100% will report at every frame size, those that cant must have the
option
> >>to
> >>report for a mix. I would urge this group to adopt a more pragmatic and
> >>practical approach to this issue.
>
> ***********************
> On Being Hardware Based
> ***********************
>
> Ummm...I hate to say it, but there is very little practical software
> that isn't hardware based. People also rarely make the distinction
> of whether something is running a real-time operating system (IOS,
> VXworks, etc.) versus a general purpose operating system (e.g.,
> MacOS, UNIX, NT). For that matter, what if the OS is kernelized? Is
> MACH hardware based? What if the routing processes run over pthreads
> in a multiprocessing environment (i.e., all the processors are
> general purpose RISC or CISC, not ASIC).
>
> Which of the following is software based? Hardware based? Which is fast?
Slow?
>
> 1. An ASIC for route lookup which has been loaded with a lookup table
> computed on a 68000 processor?
>
> 2. The RISC processor in a VIP, using a FIB created in a RISC RSP8?
>
> 3. Optimum switching in an RSP, given the lookup uses a CAM with content
> set up by a RISC?
>
> 4. CEF on a 7200 with a NPE-300?
>
> 5. Silicon switching on a 7000 with a 68040 CPU?
>
>
> _________________________________
> FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
> Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
