Subject: [Roll] draft-ietf-roll-routing-metrics-03.txt

From: Adrian Farrel <[email-masked]>
Date: Tue, 10 Nov 2009 01:34:45 +0000

Hi,

Thanks for presenting today.

Something jumped out.

In the common header you have...

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Routing-Ob-Type|Res|R|G| A |O|C|   Object Length (bytes)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                        (Object body)                        //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 2: Routing Metric/Constraint common header format

Are you worried that you have only two more unused bits? Is there a risk 
that you will run out very soon?

On the other hand, do you really need 16 bits for the length in bytes of the 
object? Are you tied to this format by the RPL spec, or could you create 
yourself 8 more flag bits by reducing the Object Length to 8 bits?

Cheers,
Adrian

---

From: [email-masked]
Date: Tue, 10 Nov 2009 10:20:02 -0500

I mentioned it during the roll meeting Tuesday, but I think it's probably 
worth documenting the thought in a little more technical detail.  The 
routing metrics right now include 32-bit floating point numbers for 
latency and throughput.  Since these numbers are much more likely to be 
added or compared rather than multiplied, fixed point rather than floating 
point is likely to be a better choice of representation.  For example, for 
normalized positive 32-bit IEEE 754 numbers, the maximum number is about 
3.4e38 and the minimum is about 1.2e-38.  For reference, the age of 
universe in milliseconds (taking the high end of NASA's most recent 
estimate) is only 4.4e20 and the time it takes to travel the distance 
across an electron (Lorentz diameter for you physics heads) is about 
1.9e-20 ms.  A negative latency would seem to imply that packets appear 
before they're sent which is probably not practical.  If instead, latency 
were a 32-bit unsigned integer in units of milliseconds, we'd still be 
able to go from 0 or 1 milliseconds up to almost 1200 hours if my math is 
right.  That should be plenty for any practical network.  I haven't done 
so but I suspect that we could do the same thing with throughput.

Ed Beroset

---

From: JP Vasseur <[email-masked]>
Date: Tue, 10 Nov 2009 16:55:16 +0100

Hi Edward,

On Nov 10, 2009, at 4:20 PM, [email-masked] wrote:

>
> I mentioned it during the roll meeting Tuesday, but I think it's  
> probably worth documenting the thought in a little more technical  
> detail.  The routing metrics right now include 32-bit floating point  
> numbers for latency and throughput.  Since these numbers are much  
> more likely to be added or compared rather than multiplied, fixed  
> point rather than floating point is likely to be a better choice of  
> representation.  For example, for normalized positive 32-bit IEEE  
> 754 numbers, the maximum number is about 3.4e38 and the minimum is  
> about 1.2e-38.  For reference, the age of universe in milliseconds  
> (taking the high end of NASA's most recent estimate) is only 4.4e20  
> and the time it takes to travel the distance across an electron  
> (Lorentz diameter for you physics heads) is about 1.9e-20 ms.  A  
> negative latency would seem to imply that packets appear before  
> they're sent which is probably not practical.

Indeed ;-)

> If instead, latency were a 32-bit unsigned integer in units of  
> milliseconds, we'd still be able to go from 0 or 1 milliseconds up  
> to almost 1200 hours if my math is right.  That should be plenty for  
> any practical network.  I haven't done so but I suspect that we  
> could do the same thing with throughput.
>

Absolutely. It will be reflected in the next revision.

Another question is whether we want to make the metrics inversely  
proportional to the throughput in order to compute least cost path.  
Opinion ?

Thanks.

JP.

> Ed Beroset_______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Michael Richardson <[email-masked]>
Date: Tue, 10 Nov 2009 11:25:40 -0500

>>>>> "edward" == edward j beroset <[email-masked]> writes:
    edward> I mentioned it during the roll meeting Tuesday, but I think
    edward> it's probably worth documenting the thought in a little more
    edward> technical detail.  The routing metrics right now include
    edward> 32-bit floating point numbers for latency and throughput.
    edward> Since these numbers are much more likely to be added or
    edward> compared rather than multiplied, fixed point rather than
    edward> floating point is likely to be a better choice of

  I mostly agree, but gotta point out this is a bike shed.

  If we can agree that, should we need sub-milisecond latencies in the
future (when RPL is used by dust-mote nanites..) that we would simply
create a new metric with different units.

    edward> which is probably not practical.  If instead, latency were a
    edward> 32-bit unsigned integer in units of milliseconds, we'd still
    edward> be able to go from 0 or 1 milliseconds up to almost 1200
    edward> hours if my math is right.  That should be plenty for any
    edward> practical network.  I haven't done so but I suspect that we
    edward> could do the same thing with throughput.

  If we express throughput as a power of 2, then likely 8 bits works!
That gives us values from 2^0=1 bits/second to 2^(256)=10^77
bits/second.

  If we use 32-bits as integer, in units of kilobits, we get
1kbit/second up to 4 terabits/second, also acceptable.

  But, this is NOT the interesting question.
  We also need to think about the error bar/stddev on the numbers!!!

  The question is: what metrics do we need, how many can be determined 
at runtime (without explicit configuration), what are the errors on the
numbers, and what are the formulae that put them together.

- -- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: [email-masked]
Date: Tue, 10 Nov 2009 11:25:43 -0600

Not to mention that some of the base
hardware platforms that may be used  - -  do not support 32 bit
floating point in certain markets.

Ted

From:

[email-masked]

To:

[email-masked],
[email-masked]

Date:

11/10/2009 09:20 AM

Subject:

[Roll] numeric ranges in routing metrics

I mentioned it during the roll meeting Tuesday, but I think it's probably
worth documenting the thought in a little more technical detail.  The
routing metrics right now include 32-bit floating point numbers for latency
and throughput.  Since these numbers are much more likely to be added
or compared rather than multiplied, fixed point rather than floating point
is likely to be a better choice of representation.  For example, for
normalized positive 32-bit IEEE 754 numbers, the maximum number is about
3.4e38 and the minimum is about 1.2e-38.  For reference, the age of
universe in milliseconds (taking the high end of NASA's most recent estimate)
is only 4.4e20 and the time it takes to travel the distance across an electron
(Lorentz diameter for you physics heads) is about 1.9e-20 ms.  A negative
latency would seem to imply that packets appear before they're sent which
is probably not practical.  If instead, latency were a 32-bit unsigned
integer in units of milliseconds, we'd still be able to go from 0 or 1
milliseconds up to almost 1200 hours if my math is right.  That should
be plenty for any practical network.  I haven't done so but I suspect
that we could do the same thing with throughput.

Roll mailing list

[email-masked]