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

Uniform Probabilistic Sampling in PSAMP-PROTO

Dear all,

We're trying to model "Uniform Probabilistic Sampling" in [PSAMP-PROTO].

[PSAMP-MIB] specifies:
5.2.5. Uniform Probabilistic Sampling

Capability objects are not specified for the uniform probabilistic
sampling method. It has only one parameter in the
psampSampUniProbParamSetTable, the psampSampUniProbProbability. This
object gives the probability that a packet is sampled. The
probability is equal for every packet. The given value must be
divided by 4294967295 (=2^32-1), so a value of 0 means no packet is
sampled (probability is 0) and a value of 4294967295 means every
packet is sampled (probability is 1).

psampSampUniProbProbability OBJECT-TYPE
SYNTAX Unsigned32 (0..4294967295)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object gives the probability that a packet is sampled.
The probability is equal for every packet. The given value
must be divided by 4294967295 (=2^32-1), so a value of 0
means no packet is sampled (probability is 0) and a value of
4294967295 means every packet is sampled (probability is
1)."

First of all, I've got an issue with the psampSampUniProbProbability MIB. How do we represent a probability of 1/2 as this number not even?
Should we use a different number (1000000000), specifying a range in the SYNTAX. I think so!

Initially we wanted to model the probability in [PSAMP-PROTO] with a float, which is allowed by [IPFIX-PROTO].
However, we've got the issue that SMIv2 doesn't support floats.

What to do now?

Solution 1:
We export the probability with a float, and we approximate this value with the MIB variable.

Solution 2:
We export the probability with an unsigned32, exactly the same content as the MIB variable psampSampUniProbProbability

Solution 3:
We export the probability with two values N, M.
    This means 2 inter-dependent I.E.s and 2 MIB variables instead of one.
    I don't like it too much

I'm clearly in favor of solution 1. It's not right that we would limit IPFIX because of the limitations of SMIv2
Feedback?

Side question: if we go for the float solution, should we have a float64? This would give us more precision
Note: not yet defined in [IPFIX-PROTO].

Regards, Benoit.