Subject: Re: [ipfix] Floating point numbers in IPFIX

From: Benoit Claise <[email-masked]>
Date: Thu, 09 Feb 2006 11:17:23 +0100

Dear all,

In an attempt to summarize all this thread conclusion, I have inserted 
the following text.

Regards, Benoit.

6R6.2 Reduced Size Encoding of Integer and Float Types

Information Elements containing integer, string, float, and octetarray 
types in the information model MAY be encoded using fewer octets than 
those implied by their type in the information model definition 
[IPFIX-INFO], based on the assumption that the smaller type is 
sufficient to carry any value the Exporter may need to deliver.  This 
reduces the network bandwidth requirement between the Exporter and the 
Collector.  Note that the Information Element definitions [IPFIX-INFO] 
will always define the maximum encoding size.

For instance the information model [IPFIX-INFO] defines byteCount as an 
unsigned64 type, which would require 64-bits.  However if the Exporter 
will never locally encounter the need to send a value larger than 
4294967295, it may chose to send the value instead as an unsigned32.  
For example, a core router would require an unsigned64 byteCount while 
an unsigned32 might be sufficient for an access router.

This behavior is indicated by the Exporter by specifying a type size 
with a smaller length than that associated with the assigned type of the 
Information Element.  In the example above the Exporter would place a 
length of 4 versus 8 in the template.

If reduced sizing is used, it MUST only be applied to the following 
integer types: unsigned64, signed64, unsigned32, signed32, unsigned16, 
signed16.  The same signed versus unsigned property MUST be preserved. 
 The reduction in size can be to any number of octets smaller than the 
original type if the data value still fits, i.e. so that only leading 
zeroes are dropped. For example, an unsigned64 can be reduced in size to 
7, 6, 5, 4, 3, 2, or 1 octet(s).

Reduced sizing can also be used on the float64 and float32.  The float32 
not only has a reduced number range, but due to the smaller mantissa is 
also less precise.

The reduced size encoding MUST NOT be applied to dateTimeMicroSeconds or 
to dateTimeNanoSeconds because these represent an inherent structure 
that would be destroyed by using less than the original number of bytes.

> Hi all
>
> In the IPFIX protocol draft, section 3.1.5, we have a definition
> of a floating point number.  This definition allows export of
> floating point numbers using the 32-bit format as specified in
> IEEE.754.  This same standard also allows floating point numbers
> to be defined in a 64-bit format.
>
> I would like to see a float64 type added and the abiltity to
> send float64 fields using float32 using a variation of the
> Reduced Size Encoding as used with the integers.
>
> I would like to propose that at the next editing phase we add
> the following type to the information model:
>
> 3.1.6.  float64
>
> The type "float64" corresponds to an IEEE double-precision 64-bit
> floating point type as defined in [IEEE.754.1985].
>
>
> In the protocol, section 6.2 could also be expanded to encompase
> the Reduced Size encoding for the floating point types. i.e.
>
> 6.2      Reduced Size Encoding of Integer Types
>  Information Elements containing integer, float, string, and ...
>                                           ^^^^^^^
>  octetarray types in the information model MAY be encoded using fewer
>  octets than those implied by their type in the information model
>  definition [IPFIX-INFO], ...
>
>  ...
>    If reduced sizing is used, it MUST only be applied to the following 
>  integer types: unsigned64, signed64, unsigned32, signed32, 
>  unsigned16, signed16.  ...
>
> @@[NOTE: the signed types above are not in the data model]@@
>
>  Reduced sizing can also be used on the float64 and float32.  The
>  float32 not only has a reduced number range, but due to the
>  smaller mantissa is also less precise.
>
>  The reduced size encoding MUST NOT be applied to ...
>
>
> Andrew
>
>
> -- 
> Help        mailto:[email-masked] and say "help" in 
> message body
> Unsubscribe mailto:[email-masked] and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/

---

From: "Thomas Dietz" <[email-masked]>
Date: Fri, 10 Feb 2006 11:15:48 +0100

Hi all,

Assuming that somebody could reduce float64 to float32 even if the precision
is reduced, because they do it on purpose then I would also agree to the
current wording.

Regards,

Thomas

-- 
Thomas Dietz
Network Laboratories, NEC Europe Ltd., 69115 Heidelberg, Germany

> -----Original Message-----
> From: Benoit Claise [mailto:[email-masked]] 
> Sent: Friday, February 10, 2006 11:08 AM
> To: Stewart Bryant
> Cc: Paul Aitken; Brian Trammell; Thomas Dietz; 
> [email-masked]; [email-masked]
> Subject: Re: [ipfix] Floating point numbers in IPFIX
> 
> Hi,
> >>
> >>
> >>
> >> So perhaps Benoit's text could be clearer, eg:
> >>
> >>   Reduced sizing can also be used to reduce float64 to float32.
> >>   The float32 not only has a reduced number range, but due to
> >>   the smaller mantissa is also less precise.
> >>
> >> Cheers.
> Agreed and done.
> 
> Regards, Benoit.
> 
>

---

From: "Thomas Dietz" <[email-masked]>
Date: Fri, 10 Feb 2006 12:17:47 +0100

Carsten and all,

I think Paul is right. This should be taken to the implementation guidelines
since this is not directly a protocol issue.

Thomas

> From: Paul Aitken [mailto:[email-masked]] 
> Sent: Friday, February 10, 2006 11:47 AM
> To: Carsten Schmoll
> Cc: Thomas Dietz; Benoit Claise; Andrew Johnson; 
> [email-masked]; Elisa Boschi
> Carsten,
> > I think the reduction of precision is unavoidable (depending on the 
> > concrete exported value). Therefore I would suggest some text like:
> > 
> > "When using reduced encoding for double or float types make 
> sure that
> > the potential loss of precision due to the smaller mantissa is
> > acceptable for your application."
> 
> That sounds like an appropriate point for the implimentation guide?
> 
> -- 
> Paul Aitken
> Cisco Systems Ltd, Edinburgh, Scotland.
>