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

From: Benoit Claise <[email-masked]>
Date: Mon, 19 Dec 2005 15:25:42 +0100

Andrew, Thomas,
> Find my comments inline.
>
> -- 
> Thomas Dietz
> Network Laboratories, NEC Europe Ltd., 69115 Heidelberg, Germany
>
>
> > -----Original Message-----
> > From: majordomo listserver 
> > [mailto:[email-masked]] On Behalf Of Andrew Johnson
> > Sent: Thursday, December 15, 2005 6:47 PM
> > To: [email-masked]
> > Subject: [ipfix] Floating point numbers in IPFIX
> > 
> > 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.
>
> Fine with me if all the others agree.
>   
I think it makes sense.
> > 
> > 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].
> > 
>
> I guess the definition is ok.
>
> > 
> > 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 
>
> Note the section says "Integer Types", so I would propose to have a seperate
> section. This would also make clear that the reduzed size encoding of floats
> is different than those of integers.
>   
Ok.
> > 
> >   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]@@
>   
So we would need some new definitions in the information model draft for 
signed64, signed32, and signed16, right?
> > 
> >   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 ...
>
> I think we still need to elaborate this a little bit more, because we have
> to explain how mantissa and exponent can be mapped from float64 to float32.
>   
As always, feel free to propose some text.

Regards, Benoit.

> Regards,
>
> Thomas
>
> > 
> > 
> > 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/
> > 
> Dear 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: Stewart Bryant <[email-masked]>
Date: Mon, 19 Dec 2005 14:48:47 +0000

Benoit Claise wrote:

>> > From: majordomo listserver > [mailto:[email-masked]] 
>> On Behalf Of Andrew Johnson
>> >    >   If reduced sizing is used, it MUST only be applied to the 
>> following >   integer types: unsigned64, signed64, unsigned32, 
>> signed32, >   unsigned16, signed16.  ...
> So we would need some new definitions in the information model draft 
> for signed64, signed32, and signed16, right?

I think that we need the full set of signed types 8/16/32/64 bits

> As always, feel free to propose some text.

Why do we need this?

Surely the canonical object is a number, so the conversion is
a matter of implementation rather than protocol or object definition.

- Stewart

>
> Regards, Benoit.
>
>> Regards,
>>
>> Thomas
>>
>> > > > Andrew
>> > > > --
>> > Help        mailto:[email-masked] and say "help" > in 
>> message body