[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: question on draft charter



Rae,

> Since there is a limit, (i.e. it can't be infinite) I'd suggest it
> be just one.  Let the downstream collector create the multiple logical
> report streams for their potentially multiple network analysis stations 
> based on a single physical report stream coming from each linecard.

Having the collector create the illusion of multiple report streams
may be workable for some situations but may sacrifice accuracy too
much for others.  Suppose one application is tracking a very small
subset of traffic (e.g., a single customer or a single Web site).
Then, it would be appealing to have a high sampling rate (coupled
with a very fine-grain selection operation).  Suppose another application
is simply computing general statistics on the overall traffic.  Then,
it would be appealing to have a very low sampling rate over the entire
traffic.  Supporting both of these applications from a single configuration
could give you very poor accuracy for the fine-grained application.

> What is to be done for example if a single packet is sampled by
> multiple rulesets in a linecard and must go out on several different
> report streams?

Conceptually, it is appealing to have the packet independently sampled
by each ruleset.  Granted, this may be hard to do for more than four
or so rulesets in parallel.  Still, this would allow the analysis
applications to operate completely independently (perhaps even on
different machines).  There are ways to handle the apparent
complexity, such as round-robin sampling.  If one ruleset does 1/2
sampling and another does 1/2 sampling, you could alterate between
packets -- sending the odd packets through one ruleset and the even
packets through the other.  You do not necessarily have to implement
a parallel match against *all* of the rule sets.

Besides, this gives vendors an opportunity to differentiate themselves
by supporting more parallel samplers than the other guy... ;)

-- Jen

--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/psamp/>