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

From: Yoav Ben-Yehezkel <[email-masked]>
Date: Tue, 23 Feb 2010 20:36:28 +0200

Hi,

Just a thought.

How about assigning a few bits to the exponent of seconds (so for example,
-9 would mean resolution of nanoseconds, and 0 would mean resolution of
seconds), and the rest for the value itself.

If the upper bound becomes too small, consider lowering the number of bits
for the exponent such that each increase would represent a scale of 1,000
or so up or down instead of 10 (so for -1 resolution is for millisec, for
-2 the scale is microsec, etc.).

Thanks,
Yoav

Date: Tue, 23 Feb 2010 16:40:59 +0900
From: MiJeom Kim <[email-masked]>
Subject: Re: [Roll] [roll] #18: Numeric Ranges in Routing Metric
To: Alexandru Petrescu <[email-masked]>
Cc: [email-masked]

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.

On Sat, Feb 20, 2010 at 6:06 AM, Alexandru Petrescu
<[email-masked]> wrote:
> 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?
>
>> 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.
>
> 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
>>>
>>> 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
>>>
>> _______________________________________________ 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: Philip Levis <[email-masked]>
Date: Tue, 23 Feb 2010 11:28:42 -0800

> -2 the scale is microsec, etc.).

Floating point can cause problems with gradient calculations. If the dynamic range of values is greater than the dynamic range of the floating point, then it can be that A + B = A when B > 0. This can cause problems when transforming routing metrics to Rank unless we are careful. That is, the min rank increase requirement will have to operate on the mantissa independently of the exponent.

Phil

---

From: MiJeom Kim <[email-masked]>
Date: Fri, 26 Feb 2010 17:32:15 +0900

Hi,

To summarize up to now, for latency metric,

1. Better to express both in millisecond and microsecond
2. 2 bytes may be enough
3. Floating point needs to be avoided

So how about using 2 bytes with the first bit to express the unit
(millisecond or microsecond) and the rest 15 bits for the value
(unsigned integer)?

And for throughput, for simplicity, how about using bytes per second
presented by unsigned integer using 32 bits? That is my first
suggestion.
Regarding baud, I meant that given the same bandwidth, changing
modulation methods (e.g. BPSK or QPSK) changes baud rate, but not
bytes per second.

Mijeom