Subject: [manet] Discussion about details of OLSRv2

From: Henning Rogge <[email-masked]>
Date: Wed, 11 May 2011 11:13:28 +0200

Hello,

since the new olsrv2 draft seems to be coming later, I would like to open a 
discussion about some (in my opinion) important points of the current OLSRv2 
and Linkmetric drafts. 

I would like to start with the link metric encoding. There are some other 
important points, but we have to start somewhere.

Link metric encoding
--------------------

1) encoding range

The current metric draft does include the idea to allow metric path 
calculation in 32 bit integer, which will limit the range of a link metric to 
0 - 2^24-1. I support this idea, there are a lot of embedded devices out there 
without floating point circuits and 64 bits.

But the compressed metric tlv suggested in the draft does limit the link 
metric value to 16 - 1015808, which reduce the available range to roughly 1 to 
2^16.

I think this is a bad idea, the metric encoding should use as much range as 
possible within the 24 bit.

In additon to this it might be worthwile to add an uncompressed metric 
encoding (just a 3 byte integer), either by using the length field of the 
metric TLV to change between the two formats or use a different TLV.

An uncompressed metric value would be a great tool to work on new metrics in 
realworld networks without the influence of the compression function, which 
simplifies debugging the behaviour of metrics.

2) link metric value 0

I would like to hear the opinions of the working group about an encoding for 
link metric 0. Its a common use case in protocols with multiplicative metrics 
to have a metric value of 1, the inclusion of 0 into our metric range would 
allow a similar feature in OLSRv2.

To get a stable dijkstra result most of our existing implementations should 
already use a tie-breaker to choose between equal path costs in a stable way, 
so a link cost of 0 should not add to the complexity of our implementations.

3) link metric default value

The link metric draft suggests to set the default metric value directly in the 
middle (logarithmic) of the metric range.

In my opinion this even further restricts the useful metric values. The 
default link cost corresponds with the hopcount metric, which does not 
calculate metric values at all.

In practice I see a lot of reasons why I have links better than a hopcount 
link and very few for links that have a higher cost. If normal link metrics 
and hopcount metric should be able to work together, it would be better to 
place the default link metric value in the upper range of the metric.

My suggestion would be to use MAXIMUM_METRIC/16.

Henning Rogge

-- 
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-961,   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: Teco Boot <[email-masked]>
Date: Fri, 27 May 2011 15:20:04 +0200

It took some time to respond. Not because this subject has no priority. In the
contrary!

> important points, but we have to start somewhere.
Ack.

> metric value to 16 - 1015808, which reduce the available range to roughly 1 to 
I highly prefer a change, which allows full range of 2^24. I have to deal with
network infrastructures, where links vary from multi-Gig to sub-kilo. And link
can have very different costs ($$$), shared/fdx, high loss/high reliable, and
high/no delay. 
I need metric exchanges between different subsystems. This could be in the 
netwerk layer (e.g. OSPF-OLSR) or middleware (use network topology info).
I am able to map what I have in 2^24. 2^10 is hard.

> possible within the 24 bit.
Ack, as explained above.

> metric TLV to change between the two formats or use a different TLV.
Having multiple options in a single network is a bad idea. With 8-bits,
we loose some granularity. I don't see this as a problem. This applies to 
the dimensionless additive metric only.

> simplifies debugging the behaviour of metrics.
At the cost of overhead. We need averaging and hysteresis anyway, to 
stabilize the network. This also helps loop prevention. 

More on encoding: I prefer having values 1, 2, 3, ... 10. And integers only. 

> allow a similar feature in OLSRv2.
With 2^24 range, a minimum value of 1 will do. I really want the protocol 
to work nicely on a high speed wired network (e.g. GB Ethernet). It must be 
able to select multi-GB over 1GB and 1-hop over multi-hop.

> so a link cost of 0 should not add to the complexity of our implementations.
I don't think so. With multi-path and multi-hop zero-cost links, I think tie-
breakers easily break.

> calculate metric values at all.
Maybe we discuss different defaults.
1) OLSR messages without a metric, therefore the protocol uses a default 
   metric.
2) There is no information for getting metric data available, therefore the 
   protocol uses a default metric.
The metric draft discusses 1). It also says that if all nodes don't send 
metrics, the result is exactly as it was before, with hopcount.
I think you want to combine 1) and 2), because you want to use "useful 
metrics" and discuss this in relation with the DEFAULT_METRIC value.

> link and very few for links that have a higher cost.
I see a lot of reasons for not using hopcount at all :-)
More serious: your scenario is using a mix of defaults and specified metric 
values, right? And the default is used for nodes that are unaware of link 
type, rate, loss etc. The metric is used on nodes that have better knowledge,
or just assume something that is not default.
But what prevents you to configure a high default, e.g. 2^20, for links with 
type "unknown"? 

> If normal link metrics 
We don't have hopcount metrics anymore. We may face nodes that are unaware of 
link type and therefore use a (configured or coded) default or the OLSRv2 link 
metric default (coded). 

> My suggestion would be to use MAXIMUM_METRIC/16.
The outcome should be an integer, OK?
If we have a range of 1 to 2^24-1 (or somewhat nearby maximum value), I think
a default of 2^16, 65536 (or nearby), will do. Or the 2^20 as suggested above.

Thanks, Teco