Re: RMON in hardware

[Stephen Grau <[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.
> 
> 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!
> 
> Essentially, my point, is that you should label the RMON in your
> product with a warning to its users that says "The data collected by
> this RMON device can be highly inaccurate under the following
> conditions..."
> 
> 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.

Steve
[e-mail]