Subject: Re: [Roll] [roll] #18: Numeric Ranges in Routing Metric

From: MiJeom Kim <[email-masked]>
Date: Fri, 19 Feb 2010 17:49:54 +0900

Hi, all,

It's time to close on the #18. I think that throughput and latency can
be better presented by unsigned integers as the below justification
wrote.
Latency can be expressed in units of milliseconds and throughput can
be expressed in bytes per second.
If you don't have any objection, let me close it.
Please send me your comments on the issue.

Thanks,
Mijeom.

On Sun, Nov 15, 2009 at 7:30 PM, roll issue tracker <[email-masked]> wrote:
> #18: Numeric Ranges in Routing Metric
> --------------------------------+-------------------------------------------
>  Reporter:  jpv@…               |       Owner:  jpv@…
>     Type:  defect              |      Status:  new
>  Priority:  minor               |   Milestone:
> Component:  routing-metrics     |     Version:
>  Severity:  Active WG Document  |    Keywords:
> --------------------------------+-------------------------------------------
>  This ticket is related to the Numeric Ranges in Routing Metric.
>
>  Here is the original thread:
>
>  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.
>
> --
> Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/18>
> roll <http://tools.ietf.org/wg/roll/>
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 19 Feb 2010 22:06:30 +0100

I hope I get this straight... you're proposing to express latency in
units of milliseconds, i.e. micro-second precision may get lost or so(?)

Le 19/02/2010 09:49, MiJeom Kim a écrit :
> Hi, all,
>
> It's time to close on the #18. I think that throughput and latency
> can be better presented by unsigned integers as the below
> justification wrote. Latency can be expressed in units of
> milliseconds and throughput can be expressed in bytes per second. If
> you don't have any objection, let me close it.

Sure I object to expressing latency as units of milliseconds, in a 32bit
integer, because there commonly exist Round-Trip Times for 802.11g in
the range of micro-seconds, i.e. fractions of milliseconds - are they lost?

> Thanks, Mijeom.
> On Sun, Nov 15, 2009 at 7:30 PM, roll issue
> tracker<[email-masked]>  wrote:
>> Type:  defect              |      Status:  new Priority:  minor |
>> Milestone: Component:  routing-metrics     |     Version: Severity:
>> Active WG Document  |    Keywords:
>> 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.

YEs the upper bound of the latency seems to be set straight (max latency
to be a huge number).  A huge latency would correspond to a very slow 
link...

But the lower bound, i.e. a very fast link?  (micro-seconds RTT of 802.11g).

Also, how about expressing something in _baud_ somewhere because it is
very common on the slowest serial links (e.g. 150baud, 300baud,
600baud...)

Whereas latency and throughput are typical metrics for high-speed links
such as 1Mbps, 1GBps, etc.

Alex

   I haven't done
>> -- Ticket URL:<http://trac.tools.ietf.org/wg/roll/trac/ticket/18>
>> roll<http://tools.ietf.org/wg/roll/>
>>
>> _______________________________________________ Roll mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/roll
>>
> _______________________________________________ Roll mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/roll
>

---

From: MiJeom Kim <[email-masked]>
Date: Tue, 23 Feb 2010 16:40:59 +0900

Hi, Alex,

I still think that millisecond is better since micro-second is too
high precision for LLNs considering that most links are relatively
slow in LLNs. Even for the lower bound, difference of 1 millisecond
seems to be fine. Difference between 0 millisecond latency and 1
millisecond latency seems good enough for LLN applications.
Micro-second is okay, but I am just considering the trade-off,
overhead to express that precision and accuracy.

Regarding baud, you mean using it as throughput metric instead of
bytes per second? I prefer bytes per second since baud changes with
modulation methods.

How about listening to more opinions?

Thanks,
Mijeom.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 23 Feb 2010 19:10:20 +0100

Yes, I am interested in listening to more opinions me too.

> overhead to express that precision and accuracy.

WEll I believe the upper bound 2^32 milliseconds may be way too large...
maybe it's the time it takes light to travel the Universe or so.

If the upper bound is too large and the lower bound not large enough
maybe we could move the window to better accommodate both.

Something like uint16_t (unsigned integer on 16 bit) micro-seconds.
Just an idea floating around.

> bytes per second? I prefer bytes per second since baud changes with

And the bytes-per-second don't change with the modulation method?  I
believe they do too (e.g. WCDMA gives 256kbit/s where TDMA offers only a
quarter of it).

Or maybe modulation method means the other typical serial links
parameters like stop bits, data bits (7 or 8), etc.?  I think these
could indeed lead to a different byte-per-second were they applied to
the same baud rate.  In this case we could use them as additional
parameters encoded in the metric.  E.g. two links with same baudrate but
different data bits (7 or 8) give two different preferences for the
routing protocol.

Listening,

Alex

>> I hope I get this straight... you're proposing to express latency
>> in units of milliseconds, i.e. micro-second precision may get lost
>>  or so(?)
>>
>>> It's time to close on the #18. I think that throughput and
>>> latency can be better presented by unsigned integers as the
>>> below justification wrote. Latency can be expressed in units of
>>> milliseconds and throughput can be expressed in bytes per second.
>> Sure I object to expressing latency as units of milliseconds, in a
>>  32bit integer, because there commonly exist Round-Trip Times for
>> 802.11g in the range of micro-seconds, i.e. fractions of
>> milliseconds - are they lost?
>>
>>>>
>>>> Type:  defect              |      Status:  new Priority: minor
>>>> | Milestone: Component:  routing-metrics     | Version:
>>>> 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.
>>
>> YEs the upper bound of the latency seems to be set straight (max
>> latency to be a huge number).  A huge latency would correspond to a
>> very slow link...
>>
>> Also, how about expressing something in _baud_ somewhere because it
>> is very common on the slowest serial links (e.g. 150baud, 300baud,
>> 600baud...)
>>
>> Whereas latency and throughput are typical metrics for high-speed
>> links such as 1Mbps, 1GBps, etc.
>>
>> Alex
>>
>>
>> I haven't done
>>>>
>>>> -- Ticket
>>>> URL:<http://trac.tools.ietf.org/wg/roll/trac/ticket/18>
>>>> _______________________________________________ Roll mailing
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/roll
>>>>
>>> _______________________________________________ Roll mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/roll
>>>
>>

---

From: Henning Rogge <[email-masked]>
Date: Tue, 23 Feb 2010 19:20:43 +0100

> Just an idea floating around.
Why not using an exponential encoding for delay too ? You would only need a 
byte or two and can express both small and large values.

Who cares about microseconds if the delay is three seconds ? But microseconds 
might be important if you can measure them and the total delay is just 1.2ms.

Henning Rogge

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 23 Feb 2010 19:53:38 +0100

Hello Henning,

Le 23/02/2010 19:20, Henning Rogge a écrit :
>>> I still think that millisecond is better since micro-second is
>>> too high precision for LLNs considering that most links are
>>> relatively slow in LLNs. Even for the lower bound, difference of
>>>  1 millisecond seems to be fine. Difference between 0 millisecond
>>>  latency and 1 millisecond latency seems good enough for LLN
>>> applications. Micro-second is okay, but I am just considering the
>>> trade-off, overhead to express that precision and accuracy.
>>
>> WEll I believe the upper bound 2^32 milliseconds may be way too
>> large... maybe it's the time it takes light to travel the Universe
>>  or so.
>>
>> If the upper bound is too large and the lower bound not large
>> enough maybe we could move the window to better accommodate both.
>>
>> Something like uint16_t (unsigned integer on 16 bit)
>> micro-seconds. Just an idea floating around.
> Why not using an exponential encoding for delay too ? You would only
>  need a byte or two and can express both small and large values.
>
> Who cares about microseconds if the delay is three seconds ?

In this precision sense yes, I agree, who cares about microseconds if 
the delay is 3 seconds. (I have yet to see a link having 3seconds delay 
- inter-planetary maybe).

But it's not just lack of precision.  If an RPL node is presented with 
two different directly connected 802.11g interfaces and has to chose 
based on a metric expressing latency then it must be able to choose 
between micro-second values, not rounded-up second values (they'd all be 
equal).

Yes, if delay is 3 seconds then the link is obviously not 802.11g but
something else much slower, should be accommodated too.

> But microseconds might be important if you can measure them and the
> total delay is just 1.2ms.

YEs, one can measure them the microseconds.  Microseconds is what is
used in linux kernel to keep time, and to measure time.

Alex

---

From: Adam Dunkels <[email-masked]>
Date: Tue, 23 Feb 2010 19:57:55 +0100

> - inter-planetary maybe).

FWIW, some low-power 802.15.4 mechanisms that use radio duty cycling to 
reduce the power consumption can have a delay that approaches seconds. 
If the receiver wakes up only once per second, the worst-case delay 
would be one second.

/adam
-- 
Adam Dunkels <[email-masked]> | +46 70 7731614 | http://www.sics.se/~adam/
Book: Interconnecting Smart Objects with IP - http://TheNextInternet.org