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

From: "Nelke, Jens" <[email-masked]>
Date: Thu, 29 Jul 2004 13:42:17 +0200

Hi everybody,

I have some questions on the IEEE floating point format. The format contains
a mantissa of 23 Bits. As I understood the floating point format is
calculated by using the 23 Bits beginning with the most significant Bit of a
value together with an appropriate exponent. All values which can be stored
within the 23 Bits (0x7FFFFF->) will be precise, larger values may lead to
rounding errors. Let me show you an example for unreserved bandwidth of what
I mean:

Gigabit Ethernet Interface -> 1000000000 Bits/s -> 125000000 Bytes/s ->
0x7735940 Bytes/s this value fits into the 23 Bit long mantissa.

On this interface a 1 MBit/s LSP is established:

1 MBit/s -> 1000000 Bits/s -> 125000 Bytes/s -> 0x1E848 Bytes/s

After establishing the LSP the unreserved bandwidth would be:

Unreserved Bandwidth -> 124875000 Bytes/s -> 0x77170F8 Bytes/s we would need
a mantissa of 24 Bits to represent this value correct. Because we only have
23 Bits available the value stored in the floating point format would be:

0x77170F0 Bytes/s -> 124874992 Bytes/s

This value would be passed to all other OSPF-TE routers in the network and
would lead to a wrong picture of the bandwidth available.

Does anybody know if during the standardization process this fact was taken
into concern? And how large the bandwidth changes were estimated to be, am I
thinking to small ;-)?

The second problem with the IEEE floating point format is the maximum size
of the interface. Future networks will contain not just 100 MBit and Gigabit
interfaces but also be 10 or 100 Gigabit interfaces. Even 10 Gigabit
interfaces cannot be used correctly with the current format. Example:

10 Gigabit interface -> 10000000000 Bits/s -> 1250000000 Bytes/s ->
0x4A817C80 Bytes/s this leads to 24 Bits being needed to represent this
value. A neighbor would see the following unreserved bandwidth:

0x4A817C00 Bytes/s -> 1249999872 Bytes/s -> 9999998976 Bits/s

This problem is the same as shown above and leads to errors during bandwidth
calculation.

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.

Is there currently any work done on this issue?

I know that some of the problems can be reduced by using rounding
calculations, but the nicer solution in my opinion would be to use kilobits
per second as a unit for the bandwith stored in a 32 Bit value.

Regards

Jens

----------------------------------------------------------------------------
----------------
Dipl.-Ing. Jens Nelke             KEYMILE GmbH
Entwicklung                         Wohlenbergstr. 3, 30179 Hannover
----------------------------------------------------------------------------
----------------
Phone:   +49 511 978197-657
Fax:  +49 511 978197-671       < mailto:[email-masked]
<mailto:[email-masked]> >
< http://keymile.com/ <http://keymile.com/> >
----------------------------------------------------------------------------
----------------

---

From: Dave Katz <[email-masked]>
Date: Thu, 29 Jul 2004 07:56:11 -0600

> I remember correct this kind of encoding is used in some of the MPLS TE

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.