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

[Don Fedyk <[e-mail]>]

Hi Jens

I'm sure this was discussed some time in the past. I recall a solution was
to round up when you do the initial conversion from a integer value to
Floating point for Bandwidth objects (not the requests but the available
bandwidth).  Like other have said real accuracy is not required and floating
point is more future proof. The only test that must work in TE is that X
must fit into Y and you don't want Y to have lost resolution such that the
test fails.

I fail to see the need to increase accuracy for this purpose.

Don


> -----Original Message-----
> From: Nelke, Jens [mailto:[e-mail]]
> Sent: Thursday, July 29, 2004 7:42 AM
> To: [e-mail]
> Subject: Question regarding the IEEE floating point format
> used in RFC 363 0
>
>
> 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:   [phone]
> Fax:  [phone]       < mailto:[e-mail]
> <mailto:[e-mail]> >
> < http://keymile.com/ <http://keymile.com/> >
> --------------------------------------------------------------
> --------------
> ----------------
>