Re: Question regarding the IEEE floating point format used in RFC 363 0

Dave Katz <dkatz@JUNIPER.NET> Thu, 29 July 2004 13:56 UTC

Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11670 for <ospf-archive@LISTS.IETF.ORG>; Thu, 29 Jul 2004 09:56:19 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00E2D77C@cherry.ease.lsoft.com>; Thu, 29 Jul 2004 9:56:20 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 28135812 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 29 Jul 2004 09:56:18 -0400
Received: from 207.17.137.64 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 29 Jul 2004 09:56:18 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i6TDuHBm090422 for <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 29 Jul 2004 06:56:17 -0700 (PDT) (envelope-from dkatz@juniper.net)
Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i6TDuHe97770 for <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 29 Jul 2004 06:56:17 -0700 (PDT) (envelope-from dkatz@juniper.net)
Mime-Version: 1.0 (Apple Message framework v618)
References: <FE7A715E1037D711830A0002A5512D9A01BC29D2@exchange1.ke-elektronik.de>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.618)
Message-ID: <0C97428A-E167-11D8-80EE-000A95A55D88@juniper.net>
Date: Thu, 29 Jul 2004 07:56:11 -0600
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Dave Katz <dkatz@JUNIPER.NET>
Subject: Re: Question regarding the IEEE floating point format used in RFC 363 0
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To: <FE7A715E1037D711830A0002A5512D9A01BC29D2@exchange1.ke-elektronik.de>
Precedence: list
Content-Transfer-Encoding: 7bit

On Jul 29, 2004, at 5:42 AM, Nelke, Jens wrote:

> Why weren't the values stored in unsigned long with the units
> Kilobits/s if
> I remember correct this kind of encoding is used in some of the MPLS TE
> MIBs.


The really short answer is that we did it the same way as IS-IS in
order to keep the drafts aligned.

The slightly longer answer is that 23 bits of mantissa gives roughly
seven significant figures of accuracy, which ought to be good enough
for most purposes.  It does not allow for taking 300 bps reservations
out of a 10 Gbps link, but that level of granularity was not
envisioned.  Also, IEEE floats are easy to work with in practice.

The problem with fixed point is that it's fixed point.  32 bits is
generally not enough to future-proof anything.  I suppose both OSPF and
ISIS could have been defined as 64 bit fixed-point integer bps, though
this wouldn't work for longwave submarine communications or something,
and it would have been viewed as overkill.

If it turns out that the world really needs more than seven orders of
magnitude of granularity in TE reservations, it would be simple enough
to create a new TLV that has the same semantics as the current scheme
but is formatted differently.