Re: psamp vocabulary

[Andy Bierman <abierman@cisco.com>]

At 04:05 PM 9/12/2002 -0400, Rae McLellan wrote:
>> I agree with Nick about keeping PSAMP simple.
>> At a minimum, PSAMP devices (via the MIB?) should advertise
>> their capabilities in detail, so a collector application can
>> decide if result comparisons between 2 samplers are meaningful.
>
>KISS is the way to go...  I was attempting to do that by reducing
>the number of things that needed to be specififed in psamp.
>As the combination of 1 out of N sampling and deterministic
>selectors on the IP header, appears to add complexity.
>
>But since, as Nick pointed out, there are some things that true
>random sampling can provide that hash functions can not,
>it appears that the complexity of covering both types of
>sampling is unavoidable.
>
>> Beyond that, PSAMP can define specific packet selection mechanisms,
>> that (hopefully) vendors will adopt and implement.  There needs
>> to be some leeway here to allow for vendor differentiation,
>> variation in platform capabilities and intended use, and future
>> extensions.
>
>The comparision of two sample streams I mentioned earlier was only
>intended for verification of the sampling implementation and
>conformance with psamp.  I did not envisage a network operator
>comparing two sample streams in normal operation.
>
>Ideally, psamp conformance would be binary information.  Either
>an implementation conformed or it did not.  Levels of conformance
>are a pain to test and operators are then reduced to using the
>least common denominator for their sampling.  I'd much prefer
>the vendor differentiation reside in the analysis aspect of psamp.
>The information, how it is selected, and transported to the
>collector should be interchangable amonst different vendors.
>That's what interoperability is all about after all.
>Leave the vendor differentiation to how the product analyzes
>and uses the psamp information.

There will likely be variance in the packet selection mechanisms
and even some report generation capabilities:
In packet selection:
  - how many different fields can be specified for filters
  - how many filters and how can they be combined
  - min and max random sample rate
  - max line rate of interface being sampled
  - type of interface being sampled
  - sampling algorithms supported
  - how many independent sample streams can be concurrently supported
In report generation:
  - how many bytes of each packet can be captured
  - how much additional info can be collected with the packet slice
  - how many samples can be buffered before a report must be
    sent or samples are dropped
  - how many different collectors can receive the same report

Ideally, everyone will be willing to pay the same amount for HW
resources, and all implementations will be identical, but this
will never happen.  Therefore, it will be useful to allow for
varying capabilities across implementations.


>                                Rae McLellan

Andy



--
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/>