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

[Axel Neumann]

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?

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).

/axel