Subject: Uniform Probabilistic Sampling in PSAMP-PROTO

From: Benoit Claise <[email-masked]>
Date: Wed, 07 Dec 2005 18:29:48 +0100

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.

---

From: Andrew Johnson <[email-masked]>
Date: Thu, 08 Dec 2005 16:53:55 +0000

Benoit Claise wrote:
[SNIP]
> However, we've got the issue that SMIv2 doesn't support floats.

Although the floating point type is not a base type in SMI there are
a couple of proposals about how to send them.  This extract is from
the comp.protocols.snmp SNMP FAQ:

  http://www.faqs.org/faqs/snmp-faq/part2/
  ===============================================================
  2.40.04
  SUBJECT: Floating Point Numbers in SMI?

  You cannot add new base types to the SMI.

  For now, the easiest way to have floating point numbers
  in SNMP MIBs is to use the base type OCTET STRING and
  encode the value in ASCII.

  This is not the most elegant approach. However, it will work
  between your agent and your management application and it will
  be compliant to the SNMP SMI and protocol specifications.

  David Perkins
  ===============================================================

Apparently this method is implemented in the NET-SNMP agent and
manager.
  (http://ops.ietf.org/lists/mreview/mreview.2004/msg00083.html)

Whether we use the above suggested method or define a new way of
using unsigned32 the application will have to have some way of
converting that number before it can be used.

> Note: not yet defined in [IPFIX-PROTO].

FYI:
The 32-bit float has 24 bits of precision, i.e. roughly +/-0.000006%.
The 64-bit float has 53 bits of precision, i.e. roughly +/-0.00000000000001%

regards

Andrew

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

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 21 Dec 2005 09:34:00 +0100

Hi Benoit,

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:

> 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].
> Solution 1:
> 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.

> Solution 2:
> We export the probability with an unsigned32, exactly the same content as the MIB variable psampSampUniProbProbability
>
> Solution 3:
> I'm clearly in favor of solution 1. It's not right that we would limit IPFIX because of the limitations of SMIv2
>
> Feedback?

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

The question is how much precision we need here.
In general, I think that single precision is sufficient.

Thanks,

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 21 Dec 2005 12:15:39 +0100

Hi Andrew,

>   http://www.faqs.org/faqs/snmp-faq/part2/

This would be Solution 4.
I still prefer Solution 1 or Solution 2.

> The 32-bit float has 24 bits of precision, i.e. roughly +/-0.000006%.

It is 23 bits we are using. Precision would be    roughly +/-0.00001%
The Unsigned as Benoit suggests it would have     roughly +/-0.0000001%

Thanks,

    Juergen

---

From: Andrew Johnson <[email-masked]>
Date: Fri, 23 Dec 2005 15:12:16 +0000

> It is 23 bits we are using. Precision would be    roughly +/-0.00001%

I think you are correct.  IEEE 764 assumes a top bit of 1 but although
this generates a 24-bit number we only have 23 bits of precission, as
you say.

This precision remains constant as the size of the number varies as the
exponent shifts the mantissa to where the bits have the most accuracy.
This is why I prefer using the float as a solution.

> The Unsigned as Benoit suggests it would have     roughly +/-0.0000001%

The precision scales according to the size of the fraction you are
representing, so for the common small numbers it is quite precise but for
the smaller the fraction the less accurate the method is. For example, for
a 1 in 3 billion sampler the closest we can represent is 1 in 2^32, which
is almost 50% off.

Regards,

Andrew