Subject: Re: [Roll] [roll] #20: Question on Metric ID

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

Hi, again,

Now the #20. As I mentioned in #18, throughput and latency may be
better expressed in unsigned integers.
And I confirmed that there is no IEEE 8 bits floating point format. So
encoding of ETX needs to be reconsidered. I think we may use 16 bits
half precision IEEE 754 format or 8 bits unsigned integer. Any better
idea? Please post your opinion to close on this issue soon.

Thanks,
Mijeom.

On Thu, Dec 3, 2009 at 8:54 PM, roll issue tracker <[email-masked]> wrote:
> #20: Question on Metric ID
> --------------------------------+-------------------------------------------
>  Reporter:  jpv@…               |       Owner:  mjkim@…
>     Type:  defect              |      Status:  new
>  Priority:  major               |   Milestone:
> Component:  routing-metrics     |     Version:
>  Severity:  Active WG Document  |    Keywords:
> --------------------------------+-------------------------------------------
>  Question on the METRIC ID asked during IETF-76
>
>  - Throughput and latency should be IEEE 32 floating point?
>
>  -  Is there IEEE 8 floating point format?
>
> --
> Ticket URL: <https://wiki.tools.ietf.org/wg/roll/trac/ticket/20>
> 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:14:33 +0100

> better expressed in unsigned integers.

Hmm... integers of milli-seconds would loose the micro-second precision 
of latency on e.g. 802.11g.  Maybe micro-seconds?  Maybe nano-seconds?

I believe the

> And I confirmed that there is no IEEE 8 bits floating point format.

We may invent one if we needed and propose to IEEE, no?  1 sign, 5
mantissa, 2 exponent, or something else.

> So encoding of ETX needs to be reconsidered. I think we may use 16
> bits half precision IEEE 754 format or 8 bits unsigned integer. Any
> better idea? Please post your opinion to close on this issue soon.

What's the range of reported values?  What values did the implementers 
encounter?  On what links?

IMHO,

Alex

>
> Thanks, Mijeom.
>
>
> On Thu, Dec 3, 2009 at 8:54 PM, roll issue
> tracker<[email-masked]>  wrote:
>> Type:  defect              |      Status:  new Priority:  major
>> |   Milestone: Component:  routing-metrics     |     Version:
>> -- Ticket URL:<https://wiki.tools.ietf.org/wg/roll/trac/ticket/20>
>> 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 17:02:33 +0900

Hi, Alex,

The range of ETX value is not defined since it depends on
implementation. But, ETX is the number of transmission a node expects
for successful transmission, thus, it should be higher than 1 and we
can guess it cannot be so big number. If a node never delivers a
packet successfully, the number can be infinite, but this is an
extreme case. So it is not a bad idea to coin our own 8 bits floating
point type.

Mijeom.

On Sat, Feb 20, 2010 at 6:14 AM, Alexandru Petrescu
<[email-masked]> wrote:
> Hmm... integers of milli-seconds would loose the micro-second precision of
> latency on e.g. 802.11g.  Maybe micro-seconds?  Maybe nano-seconds?
>
> I believe the
>

---

From: Henning Rogge <[email-masked]>
Date: Tue, 23 Feb 2010 09:13:42 +0100

> extreme case. So it is not a bad idea to coin our own 8 bits floating
In practice an ETX of more than 10 is close to infinity. A maximum value of 100 
for a single hop ETX is more than enough.

The current draft of Christopher Dearlove for the OLSRv2 metric encoding 
suggests a 8 Bit floating point for metrics with a range of 16 to 1015808, 
which can be easily used for ETX (multiplied with a constant factor to prevent 
the need for real floating point calculations). My suggestion for ETX=1 in this 
encoding would be 256, but that's still a point which has to be discussed.

If you choose your own encoding I would suggest NOT to set ETX=1 as the best 
possible metric value. My experience from our OLSR networks tells me that this 
is a really bad decission which can hurt you later.

Henning

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-263,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

---

From: Henning Rogge <[email-masked]>
Date: Tue, 23 Feb 2010 09:15:51 +0100

On Tue February 23 2010 09:13:42 Henning Rogge wrote:
> In practice an ETX of more than 10 is close to infinity. A maximum value of
>  100 for a single hop ETX is more than enough.
> 
Sorry, forgot to include a link to the current draft:
http://bgp.potaroo.net/ietf/idref/draft-dearlove-olsrv2-metrics/

Henning Rogge

---

From: Omprakash Gnawali <[email-masked]>
Date: Tue, 23 Feb 2010 02:13:15 -0800

> is a really bad decission which can hurt you later.

Are you suggesting that the representation of the metric value "1"
should not be 1, and it should be 256?

Does your bad experience related to metric representation from running
OLSR network have to do with metric precision?

- om_p

---

From: Henning Rogge <[email-masked]>
Date: Tue, 23 Feb 2010 11:22:36 +0100

> should not be 1, and it should be 256?
Yes, at least if you use the suggested encoding of the draft. Using a factor 
of 256 for the ETX allows for better links than ETX 1 but still have a huge 
range of values for ETX >1.
 
> OLSR network have to do with metric precision?
No, we discovered that we could not represent ethernet links (connecting 
multiple devices) better than a "perfect" wireless link in our metric 
encoding, so our routing agent prefers a single wireless link with some packet 
loss over an ethernet-hop plus a perfect wireless link, which is BAD.

It's a good idea to keep a little bit room for "better links".

We use 1 byte for LQ with a factor of 255 to shift the floating point value 
(0.0 - 1.0) into a pure integer one. It's very difficult to change the encoding 
of the routing metric later without reinstalling the whole network at once.

Henning Rogge

---

From: Omprakash Gnawali <[email-masked]>
Date: Tue, 23 Feb 2010 09:00:52 -0800

On Tue, Feb 23, 2010 at 2:22 AM, Henning Rogge
<[email-masked]> wrote:
....
> of the routing metric later without reinstalling the whole network at once.

Thanks for sharing this insight. We need to be aware of similar
scenarios also on LLNs.

I think RPL's approach is to have different objective functions that
maximize/minimize or constrain different metrics, and even apply a
series of objective functions for path selection if desired. That
seems like a better approach than overloading many meanings to ETX.
Does OLSRv2 support different metrics such as data rates and energy?
If it does, are there still advantages to overloading ETX?

- om_p