[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Uniform Probabilistic Sampling in PSAMP-PROTO
Sorry for the late reply.
Basically, I agree with your proposal.
Please find comments in line.
--On 07.12.2005 18:29 Uhr +0100 Benoit Claise wrote:
We're trying to model "Uniform Probabilistic Sampling" in [PSAMP-PROTO].
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).
SYNTAX Unsigned32 (0..4294967295)
"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
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!
I support this proposal. If we follow it, setting and reading
the probability would become less error-prone. From reading the
value you can much easier identify a probalility of 0.5: 500000000
or 0.01: 10000000. Still the problem of counting the zeros
remains as problem. The disadvantage is less precision. But I
think the remaining precision of 1 of a billion is still sufficient.
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?
We export the probability with a float, and we approximate this value with the MIB variable.
Approximation is not an issue, because the precision of the Integer
in the MIB would be greater than the precision of a float32 by several
orders of magnitude. So, we do not loose information by converting a
float32 to a 32 bit integer (in this case).
Approximation would be an issue if we chose a float64.
We export the probability with an unsigned32, exactly the same content as the MIB variable psampSampUniProbProbability
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
I am fine with Solution 1 as well as with Solution 2.
Are there any other opinions?
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].
The question is how much precision we need here.
In general, I think that single precision is sufficient.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.