Re: RMON in hardware

[[e-mail]]

>> You say, that you can throw hardware at the problem.  Indeed you'd
>> have to throw enough hardware to do *both* full Ethernet speed routing
>> plus RMON.

>Not true.  The hardware requirements depend heavily on how the product
>is deployed.  Novell's Multi-Protocol Router is used in many cases at
>a LAN-to-WAN boundary - the WAN bandwidth is the limiting factor on
>performance, not the router's CPU bandwidth.  In these cases, there
>is plenty of spare CPU cycles for doing RMON.

Then why have the promiscous mode back off at all?

But I don't believe your assertion.  The LAN side of the router/rmon
can be very busy and not at all limited by the WAN side bandwidth
limitations.  I can easily see a situation in which a busy LAN eats
100% of the box cycles because the box is spending all its time
rmon-ing the LAN side packets.  In that situation, the box is going to
have to load shed the rmon activity for any routed packets, no matter
how few.

 >   > As for your point that the packets at the end of the buffer are lost
 >   > -- I don't get why that somehow changes my conclusion.
 >
 >   It's not random.  In the broadcast storm case I brought up, the slowest
 >   nodes will always end up being the ones that have there packets dropped.
 >   Hence, the counters for fast nodes will be accurate, the counters for
 >   slow nodes will be inaccurate.  Same thing will happen if two machines
 >   have bursty exchanges that overrun the probe - the beginning of the
 >   burst will be accounted for, the end will not be accounted for - not
 >   random at all!

I note that you emphasise my point -- that the methods you are using
are not random.  If you were to have random losses, then on average,
things would be OK.  But your technique introduces a systematic,
non-deterministic error.

Most computers use pretty standard Ethernet controller chips.  So even
wimpy devices can send during the storm.  It's just that they may not be
able to send again.

I've got a tool that can cause enough traffic to melt a FDDI (I know
that this is true because I do it often when testing the Interop
network backbone -- I'm going to try it on an ATM net this weekend.)

Anyway, the heavy traffic is merely the result of a small trigger
flow.  If a monitor were to see the heavy traffic and miss the
triggers it would tell me nothing useful.

> > I don't mind that you are building such a product.  I just feel that
> > you ought to make sure that users don't start believing that it can
> > offer many significant digits of accuracy in all situations.
> > Furthermore I believe it is incumbent upon vendors that make gear of
> > this nature to give the users all the caveats necessary to know when
> > the data is questionable.
 >
> I don't think you need to worry about this.  The marketplace will police
> vendors.  This is what standards are good for - vendors can offer compliant
> products with various price/performance characteristics and the marketplace
> will sort out which ones meet needs and which ones do not.

We already have a lot of garbage SNMP gear in the field.  Network
management stations (at least the ones that have been really used)
usually need special code to weed out information from the "bad"
agents.

I certainly would support accuracy testing or accuracy disclosure
statements by vendors that would give the buyers a chance to be
knowlegable buyers.

It would be nice if the RMON MIB also contained a variable that could
be read by managers to give them at least a qualitative level of data
quality they can expect.  (Although I guess, one could always read the
sysId and look up on a published list of quality versus non-quality
rmon implemenations.)

		--karl--