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

[nemesis]

 On Mon, 4 Apr 2016 12:38:51 +0200, 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?
>
> 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).

 It could mean the preferred default metric, BUT... Henning is right in 
 asking:
 why do we need this?

 We should try to not do stuff just because we can, but because we need 
 it.

 Henning is right when he writes that if you want you can already output 
 different NetworkGraphs and NetworkRoutes and wrap them in a 
 NetworkCollection,
 BUT I have tried already to write consumer tools with NetworkCollection 
 objects in a few implementations, and it's not as easy to deal with 
 them. Plus iterating over the same links twice or more times is slow. 
 And if you have to return that kind of output via HTTP to show different 
 metrics on a web visualizer it's even worse.
 One of the goal of NetJSON is to  allow organic development of a 
 software ecosystem around the specific object types, but for this to 
 happen convenience and usefulness is a key factor.

 What kind of achievable implementation that it's worth it do you have 
 in mind?

 I could improve the collector/visualizer so it can track and visualize 
 the different metrics;
 I could also think about a way of visualizing metrics at glance in the 
 graph (with different colors indicating good and bad links for example, 
 as suggested by Bastian Bittorf) and add a switcher to change the link 
 quality visualization to yse a different metric.
 This would be useful, I believe.
 Do you have time to implement a simple tool that would return the 
 modified NetworkGraph and NetworkRoutes output? If you do I will set 
 some time aside to implement this idea.

 Without implementations, I believe we are just doing nice speculations.

 Let me know what you guys think!

 Thanks
 Federico