[Interop-dev] [BMXd] make metric a optional property of NetworkRoutes, NetworkGraph, and each Route object

[Henning Rogge]

On Mon, Apr 4, 2016 at 12:38 PM, Axel Neumann <(spam-protected)> wrote:
> On 03.04.2016 19:40, Nemesis wrote:
>
>> Do you know other routing protocols that implement multiple metrics?
>
> Yes! Olsr was initially based on hop-count metric before moving to ETX
> and now suggesting DAT.
> Not sure if babelZ metric, a version to take radio frequency
> interference into account, is different from standard babel metric.
>
> And NO! As far as I know, none of them support different metrics at the
> same time. Not by a single protocol process. Rather I expect other
> protocols to be able to identify and strictly discard any protocol
> message based on a different metric. Because if different metrics
> (functions interpreting metric values) would be considered (maybe
> accidentally due different code revisions or metric configurations of
> individual nodes) between protocol processes running in different nodes
> this could cause route inconsistencies and loops.
>
> [...]
>> Thinking about the possibility to include different metrics, this kind
>> of structure could work:
>>
>> {
>>     "type": "NetworkGraph",
>>     "protocol": "sample",
>>     "version": "0.9.9",
>>     "metric": "etx",
>>     "nodes": [
>>         { "id": "10.0.0.1" },
>>         { "id": "10.0.0.2" }
>>     ],
>>     "links": [
>>         {
>>             "source": "10.0.0.1",
>>             "target": "10.0.0.2",
>>             "metrics": {
>>                 "etx": 1.000,
>>                 "dat": 232.0,
>>                 "fancy": 1.34
>>             }
>>         }
>>     ]
>> }
>>
>> In the preceding example, we have one link between two nodes, the main
>> metric is "etx", but other (totally made up by me for example purposes)
>> metrics are shown in the "metrics" object of the link.
>>
>> This could replace the single "cost" attribute.
>>
>> Regarding the human readable metrics, we could write in the spec that
>> the human readable values SHOULD go in the properties object, named
>> exactly as the ones present in the "metric" object, eg (forgive me for
>> making up the human readable values):
>>
>> {
>>     "type": "NetworkGraph",
>>     "protocol": "sample",
>>     "version": "0.9.9",
>>     "metric": "etx",
>>     "nodes": [
>>         { "id": "10.0.0.1" },
>>         { "id": "10.0.0.2" }
>>     ],
>>     "links": [
>>         {
>>             "source": "10.0.0.1",
>>             "target": "10.0.0.2",
>>             "metrics": {
>>                 "etx": 1.000,
>>                 "dat": 2024.0,
>>                 "fancy": 1.34
>>             },
>>             "properties": {
>>                 "etx": "low packet loss",
>>                 "dat": "2 mbit/s",
>>                 "fancy": "1.34 whatever"
>>             }
>>         }
>>     ]
>> }
>>
>> I think this is doable, clean and easy to read. Same concept can be
>> applied to the NetworkRoutes object.
>>
>> This change would make it necessary to update current implementations,
>> but I'm willing to invest time in it if you guys think it's worth it.
>> And since the draft has not been sent to the IETF yet, better to do this
>> type of change now rather than later.
>>
>> Opinions?
Why do we need this?

> To me it seems worth. Also because replacing cost with metrics would
> allow to use metric values that do not represent a more-meanse-worse
> "cost" value like "2mbit/s".
>
> Just regarding the "main" metric member I wonder if its value then
> depends on the process creating the object (or collection of objects).

Olsrd2 NetJSON output already does multiple metric by just outputting
multiple Graph/Route objects, each with its own metric value.

That is why the "metric" is declared in the header field... if you
have two metrics, you just output two complete Graph/Route objects.

We don't need to be "short/efficient" with NetJSON because it is a
local exchange format, not something we send over the air every few
seconds.

Henning