Subject: [OPSAWG] Fw: I-D Action:draft-presuhn-floats-01.txt

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 2 Dec 2010 21:24:00 -0800

Hi -

Diffs are at http://tools.ietf.org/rfcdiff?url2=draft-presuhn-floats-01

Yes, I forgot to change the time-stamps in the MIB module.
Any other issues?

Randy

> From: <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, December 02, 2010 9:15 PM
> Subject: I-D Action:draft-presuhn-floats-01.txt
>

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> Title           : Textual Conventions for the Representation of Floating-Point Numbers
> Author(s)       : R. Presuhn
> Filename        : draft-presuhn-floats-01.txt
> Pages           : 7
> Date            : 2010-12-02
> 
> This memo defines a Management Information Base (MIB) module
> containing textual conventions (TCs) to represent floating-point
> numbers.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-presuhn-floats-01.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
...

---

From: Robert Story <[email-masked]>
Date: Sun, 5 Dec 2010 08:44:20 -0500

- As long as we're defining floating point TCs, should we also include
  a TC for a standard representation for textual floating point numbers?

  e.g. http://www.mingrentb.com/remote/pixmet_mibs/PIXMET-GLOBAL-TC.mib

- I'm guessing that the binary representation isn't defined such that a
  byte-wise comparison results in correct ordering, so should we say
  something about using these TCs as indexes so that nobody is
  surprised by ordering?

-- 
Robert Story
Senior Software Engineer
SPARTA (dba Cobham Analytic Soloutions)

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 5 Dec 2010 14:54:39 +0100

>   e.g. http://www.mingrentb.com/remote/pixmet_mibs/PIXMET-GLOBAL-TC.mib

Which problem does this solve?

>   something about using these TCs as indexes so that nobody is

Yes, I agree. Adding a warning about using these TCs as indexes seems
appropriate.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 5 Dec 2010 15:37:25 -0800

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "Robert Story" <[email-masked]>
> Cc: "Randy Presuhn" <[email-masked]>; <[email-masked]>
> Sent: Sunday, December 05, 2010 5:54 AM
> Subject: Re: [OPSAWG] Fw: I-D Action:draft-presuhn-floats-01.txt
>

My personal preference would be to keep this document very narrow.

> Yes, I agree. Adding a warning about using these TCs as indexes seems

Ok, I made up some text.  A new draft will soon appear.

Randy

---

From: Robert Story <[email-masked]>
Date: Mon, 6 Dec 2010 09:37:33 -0500

On Sun, 5 Dec 2010 14:54:39 +0100 Juergen wrote:
JS> On Sun, Dec 05, 2010 at 08:44:20AM -0500, Robert Story wrote:
JS> > - As long as we're defining floating point TCs, should we also include
JS> >   a TC for a standard representation for textual floating point numbers?
JS> > 
JS> >   e.g. http://www.mingrentb.com/remote/pixmet_mibs/PIXMET-GLOBAL-TC.mib
JS> 
JS> Which problem does this solve?

The exact same problem the other TCs do.. defining a standard way of
representing a float, so everybody doesn't have to make up their own
TC. If it helps, I'm fine with saying implementations SHOULD use the
binary representations for floats, and MAY use the text one.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Dec 2010 16:50:17 +0100

> binary representations for floats, and MAY use the text one.

Having two ways to represent the same data does not seem to be helpful
unless there is a strong technical reason for supporting two formats
and then it should be explained how to choose between them. So unless
someone brings up a technical argument, I vote for one representation
of floating point numbers in MIB modules.

/js

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 6 Dec 2010 09:15:16 -0800

Hi Robert,

What would be the value of having a ASCII encoding of floats in  
addition to a binary one?

     Juergen Q.

Am 06.12.2010 um 06:37 schrieb Robert Story:

> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: Robert Story <[email-masked]>
Date: Mon, 6 Dec 2010 14:02:55 -0500

On Mon, 6 Dec 2010 09:15:16 -0800 Juergen wrote:
JQ> What would be the value of having a ASCII encoding of floats in  
JQ> addition to a binary one?

People are already using ascii floats, and with no standard, there are
lots of different ascii formats being used. This means that managers
must deal with special cases. If we define a TC, future modules can use
it and be interoperable with more agents.

I understand there was lots of contention about floats in past working
groups. I'm guessing one of them was that small resource constrained
agents didn't want to have to include full ieee 754 support when all
they want to do is report a temperature of 98.6. In addition to
resource constraints, licensing and distribution issues might be a
concern. Are there freely available and license free implementations
for 754?

---

From: Robert Story <[email-masked]>
Date: Mon, 6 Dec 2010 14:07:40 -0500

On Thu, 2 Dec 2010 21:24:00 -0800 Randy wrote:
RP> Any other issues?

While googling around for IEEE 754 libraries, I found some messages
that led me to believe that the IEEE specification does not say
anything about byte order. I don't have a spare $30 to buy a copy of
the specification... Any IEEE members out there that can grab a copy
and verify this?

If it's true, we should probably say something about it. I'd recommend
specifying network byte order.

---

From: "Brad Schoening -X (braschoe - Piepeople Consulting, Inc. at Cisco)" <[email-masked]>
Date: Mon, 6 Dec 2010 13:16:36 -0600

Endianness doesn't appear to be part of the IEEE standard.  That would
make sense, since the float values must be in host-byte order.

Wouldn't it be desirable for values like temperature to be reported in
fixed point, not floating point? 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Robert Story
Sent: Monday, December 06, 2010 2:03 PM
To: Juergen Quittek
Cc: [email-masked]
Subject: Re: [OPSAWG] Fw: I-D Action:draft-presuhn-floats-01.txt

I understand there was lots of contention about floats in past working
groups. I'm guessing one of them was that small resource constrained
agents didn't want to have to include full ieee 754 support when all
they want to do is report a temperature of 98.6. In addition to resource
constraints, licensing and distribution issues might be a concern. Are
there freely available and license free implementations for 754?

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Dec 2010 20:47:24 +0100

> fixed point, not floating point? 

This is what the ENTITY-SENSOR-MIB is doing.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Dec 2010 20:56:03 +0100

> concern. Are there freely available and license free implementations

Using the 754 number representation does not mean that a device needs
to implement floating point arithmetic. This continues to be a common
misconception. Whether to use floating point numbers or not should be
the decision of the MIB module author.

For the details of the representation, I suggest we use the same
format as is used by the standard XDR representation for floating
point numbers (see sections 4.6, 4.7 and 4.8 of RFC 4506).

/js

---

From: Robert Story <[email-masked]>
Date: Mon, 6 Dec 2010 15:39:36 -0500

On Mon, 6 Dec 2010 20:56:03 +0100 Juergen wrote:
JS> For the details of the representation, I suggest we use the same
JS> format as is used by the standard XDR representation for floating
JS> point numbers (see sections 4.6, 4.7 and 4.8 of RFC 4506).

Do you mean reference 4506, or cut-and-paste those sections? RFC 4506
references IEEE 754-1985. Anyone know if there were changes to the
binary interchange format between 754-1985 and 754-2008?

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Dec 2010 21:51:47 +0100

> binary interchange format between 754-1985 and 754-2008?

Cut-and-paste what is relevant. My point is that we are not the first
to exchange IEEE 754 format numbers over the network. Those who have
access to IEEE Xplore can download the 2008 version of the standard.

	http://dx.doi.org/10.1109/IEEESTD.2008.4610935

I do have access to this document but I can't share it openly due to
the copy being licensed to my university.

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 6 Dec 2010 13:07:18 -0800

Hi -

> Cc: <[email-masked]>
> Sent: Monday, December 06, 2010 11:56 AM

I'm not sure what you mean by "license free".   There certainly were
freely available implementations the last time I had to do this stuff
in software.  But if all an agent needs to do is report a value, the
process of converting an internal fixed-point or scaled integer representation
into a float is rather straightforward.  Any decent article on floating point
arithmetic will make clear what needs to be done.

> the decision of the MIB module author.

Yup.
 
> point numbers (see sections 4.6, 4.7 and 4.8 of RFC 4506).

But *not* actually referring to or copying the RFC 4506 text, since
the useful parts are just a recapitulation of the IEEE spec, and it
confuses the question of byte ordering, since XDR just uses whatever
the sender internally prefers.  I specifically said "interchange format"
for IEEE floats, since that *does* specify that the sign bit comes
first.  For a freely-available secondary reference, see
http://en.wikipedia.org/wiki/IEEE_754-2008#Interchange_formats

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Dec 2010 22:18:00 +0100

On Mon, Dec 06, 2010 at 01:07:18PM -0800, Randy Presuhn wrote:
 
> the sender internally prefers.

Recapitulation of some of the IEEE spec might be useful if we can't
assume everyone has access to it.

Are you sure that XDR allows different byte ordering? What makes you
believe this?

> I specifically said "interchange format" for IEEE floats, since that
> *does* specify that the sign bit comes first.

Isn't this what RFC 4506 says?

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 6 Dec 2010 13:38:12 -0800

Hi -

> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, December 06, 2010 1:18 PM

Faulty memory.  :-)  My mistake.

> Isn't this what RFC 4506 says?

If the IEEE specification is sufficient (I think it is) I'd rather not add
a level of indirection by citing or extracting text from RFC 4506.
If we reference or copy the RFC 4506 text, it opens the rathole of
whether that summary is a sufficient and exhaustive description.
If one still needs the IEEE spec for "the whole story", then the
objection that "you need to pay money to get the spec" doesn't
really hold water.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Dec 2010 23:15:07 +0100

> objection that "you need to pay money to get the spec" doesn't

Personally, I am fine with just referencing the IEEE spec. The TC
definitions that triggered this work apparently were all doing just
that. If, however, there is a chance of ambiguity how the bits are
ordered, I think having a simple ASCII layout in the DESCRIPTION
clause may be helpful advice for implementors (who might just be too
lazy to get and read the IEEE spec ;-).

My motivation behind the pointer to RFC 4506 was simply to make it
clear that there are existing IETF protocols happily exchanging
numbers in binary IEEE floating point format.

/js

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 06 Dec 2010 15:19:08 -0800

>>>>> On Mon, 6 Dec 2010 16:50:17 +0100, Juergen Schoenwaelder <[email-masked]> said:

JS> Having two ways to represent the same data does not seem to be helpful
JS> unless there is a strong technical reason for supporting two formats
JS> and then it should be explained how to choose between them. So unless
JS> someone brings up a technical argument, I vote for one representation
JS> of floating point numbers in MIB modules.

Different TCs are useful for different reasons.  Some may want text
representations sent because that's what they're parsing out of /proc
on the agent side so why convert it at all when it's going to be
unconverted at the management side?

We're already defining a new format in the first place that differs from
the first float implementation.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 7 Dec 2010 00:31:30 +0100

> unconverted at the management side?

The value of standard protocols lies in agreeing on a common
representation of bits on the wire. Once you write a MIB module, you
fix the format on the wire irrespective of whether the data on a
certain device implementing the MIB module exists in exactly that
format or a different format. This has always been the case with MIB
modules.

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 6 Dec 2010 15:33:04 -0800

Hi -

> From: "Wes Hardaker" <[email-masked]>
> Sent: Monday, December 06, 2010 3:19 PM
> Subject: Re: Fw: I-D Action:draft-presuhn-floats-01.txt
...
> unconverted at the management side?

But are those really floats?  I suspect some of these things really
end up being fixed point decimal numbers, which I'd hope to keep out
of scope of *this* document.

If the information is defined as "the foo field parsed out of /proc",
then the syntax isn't really going to be defined in terms of a
generic fixed / floating format, but rather in terms of what
/proc can put in that field, which could be more or less constrained.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 7 Dec 2010 12:09:31 -0800

I agree with Juergen that there should be just 1 style of encoding.
Since SNMP PDUs are binary, there doesn't seem to be much point in
a human-readable encoding for floats.

I do not see any need for Float128 either.
Are there opensource implementations like there
are for Float32 and Float64?

Are there any guidelines for MIB authors as to which flavor of
numeric data type they should use?  What are the use cases for
32 bit, 64 bit, and 128 bit floats?

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 7 Dec 2010 13:40:15 -0800

Hi -

> From: "Andy Bierman" <[email-masked]>
> To: "Wes Hardaker" <[email-masked]>; "Robert Story" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, December 07, 2010 12:09 PM
...
> I do not see any need for Float128 either.

I just included it because Juergen suggested it in his message
that said that it would be nice to have an I-D.  My suspicion is
that in MIB-ish situations, the primary value of Float128 would
be in the larger exponent range, rather than the increased
precision.  But if no one has a use for it, I'd be happy to drop it,
if doing so will get this document through the process faster.
It would be easy enough to add it to a -bis version in the future
when someone runs into a use case.

> are for Float32 and Float64?

If you have an opensource C / C++ compiler that supports
"double double", you'll probably have Float128 in software.
The last time I dug into compilers at this level was over a
decade ago, but I think a good place for the curious to look
would be in the source code for the run-time libraries that come
with your favorite open-source C compiler.

> 32 bit, 64 bit, and 128 bit floats?

That's a rather large topic.  An introduction to some of the issues
is available at http://www.validlab.com/goldberg/paper.pdf
I think such a discussion would belong in an RFC 4181bis,
since it also fits in with the whole signed/unsigned/32-bit/64-bit
integer discussion, as well as the use of UNITS and scaled
fixed-point representations.

Randy

---

From: Robert Story <[email-masked]>
Date: Tue, 7 Dec 2010 16:53:11 -0500

On Tue, 7 Dec 2010 12:09:31 -0800 Andy wrote:
AB> Since SNMP PDUs are binary, there doesn't seem to be much point in
AB> a human-readable encoding for floats.

But the end result is displayed to humans... Using that logic, we could
argue with doing away with DisplayString as well.. :-)

There doesn't seem to be support in the wg for it though, so I'll just
repeat myself one last time and then be quiet. I think people are going
to continue to use strings to represent floats,  and it would be nice
if they could all use the same format. A float TC mib is the perfect
place to define that format.

Ok, I'm done.

AB> Are there any guidelines for MIB authors as to which flavor of
AB> numeric data type they should use?  What are the use cases for
AB> 32 bit, 64 bit, and 128 bit floats?

I was thinking this too. If we do keep all 3 sizes, I also wondered if
we shouldn't do something like was done for the INET-ADDRESS-MIB
(type/generic/specific TCs), so that mib authors could use a
type/generic pair, and implementations could use the appropriate size.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 8 Dec 2010 00:29:33 +0100

> I do not see any need for Float128 either.

I believe it is easy to define all three binary IEEE 754 floats; just
doing two instead of all three seems an arbitrary choice.

> Are there opensource implementations like there are for Float32 and
> Float64?

I think so. C99 has long double which on some platforms is a Float128
(but not on all). Gcc also seems to have __float128. Apparently, XDR
(RFC 4506) has them as well.

> numeric data type they should use?  What are the use cases for 32
> bit, 64 bit, and 128 bit floats?

The floats differ in precision and size of the exponent and as a
consequence in the size of the encoding.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 7 Dec 2010 16:13:49 -0800

Adding TCs to the standards track without any use cases seems like a
bad idea to me.

I am not suggesting we revisit the Counter64 debates.
That led to the logic that a 'rule' is needed to tell implementers
which data type to use (i.e., wrap in < hour: use Counter64).
I can imagine WGs defining lots of numbers as Float128 "just in case"
it is ever needed.  This has an impact on agent performance,
assuming the agent can even support Float128 at all.

In NETCONF, we got rid of floating point numbers since they
are rarely needed and not commonly supported in routers and switches.
I think the decimal64 data type is a good compromise (fixed point).

Andy

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Tuesday, December 07, 2010 3:30 PM
To: Andy Bierman
Cc: Wes Hardaker; Robert Story; [email-masked]
Subject: Re: [OPSAWG] Fw: I-D Action:draft-presuhn-floats-01.txt

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 7 Dec 2010 18:00:09 -0800

Hi -

> To: "Juergen Schoenwaelder" <[email-masked]>
> Cc: <[email-masked]>; "Robert Story" <[email-masked]>
> Sent: Tuesday, December 07, 2010 4:13 PM

draft-ietf-ipfix-psamp-mib-02.txt is an example of a use case.
Whether it is a good example or a bad one is another question.
 
> assuming the agent can even support Float128 at all.

Which will it be?  If you want this (or some other) document to provide
"advice", the nature of the IETF is that that advice will end up being
what looks like a bunch of rules, and those rules will almost certainly
be both over-engineered and short-sighted, like the rules for integer
types in SMI.  Codifying "common sense" is a notoriously difficult thing.

I think the performance argument is really a strawman.  If something is
in a MIB as a floating type, that's presumably because that is the
natural representation for the information, and consequently that
is the most likely internal form anyway.  That's a lot cheaper than
converting it to a human-readable character string, or even 
converting it from an interal float to a scaled integer for SNMP.

> I think the decimal64 data type is a good compromise (fixed point).

Fixed point is the wrong answer for data with a potentially large dynamic
range.  Floating point is the wrong answer for data, for example, that
is truly decimal / can be handled adequately by re-thinking the UNITS.
Maybe we need a reference to Knuth vol. 2 chapter 4, though I'd hope
anyone writing code would be aware of these CS basics and could
evaluate the trade-offs.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 9 Dec 2010 00:15:40 -0800

Hi Randy,

I think all 3 TCs (32, 64, 128) are fine.
The usage rule should be the same as for other numbers...
Use the smallest size number that you need.
MIB reviewers should check Float128 objects to see if Float64
could be used instead.

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Randy Presuhn
Sent: Tuesday, December 07, 2010 6:00 PM
To: [email-masked]
Subject: Re: [OPSAWG] Fw: I-D Action:draft-presuhn-floats-01.txt

Hi -

 

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 9 Dec 2010 09:36:43 +0100

> MIB reviewers should check Float128 objects to see if Float64

I think it makes sense to include some discussion in the document that
helps MIB authors to decide whether the use of floating point numbers
is a good choice. Right now, the document says an exhaustive
discussion is beyond the scope of this document. While an exhaustive
discussion is beyond scope, I think some discussion is in scope. Here
is an attempt to rewrite the last paragraph of section 1, based on
contributions to the mailing list discussion:

OLD:

   The selection of a floating-point format involves many considerations
   and trade-offs, and an exhaustive discussion of these is beyond the
   scope of this menu.  However, one consideration peculiar to the SNMP
   environment bears mentioning here: the SNMP "lexicographical"
   ordering for INDEX objects using these textual conventions will
   simply be that of the octet strings corresponding to the floating
   point representations, which will not in general reflect the
   numerical ordering of the corresponding floating point values.

NEW:

The selection of a floating-point format involves many considerations
and trade-offs. The following list highlights some of the issues to
consider:

- Floating point numbers are useful if the number space needs to cover
  a large and dynamic range. For number spaces with a limited range,
  fixed point numbers are typically more efficient and more precise.

- Floating point numbers are the typically the wrong answer for data
  that is truly decimal / can be handled adequately by re-thinking the
  units and representing scaled numbers as integers.

- The SNMP "lexicographical" ordering for INDEX objects using these
  floating point textual conventions will simply be that of the octet
  strings corresponding to the floating point representations, which
  will not in general reflect the numerical ordering of the
  corresponding floating point values.

- Software on embedded systems may not have floating point number
  support, which can complicate the implementation of MIB objects
  using floating point numbers.

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 9 Dec 2010 10:11:46 -0800

Hi -

> To: "Randy Presuhn" <[email-masked]>; <[email-masked]>
> Sent: Thursday, December 09, 2010 12:15 AM
> Subject: RE: [OPSAWG] Fw: I-D Action:draft-presuhn-floats-01.txt
...
...

I'll add a (brief and explicitly non-exhaustive) section of usage hints,
since the questions that came up in this thread seem surprisingly
persistent.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 9 Dec 2010 10:13:40 -0800

Hi -

> To: "Andy Bierman" <[email-masked]>
> Sent: Thursday, December 09, 2010 12:36 AM

Took the words right out of my mouth.  :-)
This will do nicely.

Randy