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

[Henning Rogge]

Hi,

one of the reason why I prefer the "multiple NetworkGraph/-Route"
objects is that there is no guarantee that every topology has the same
links or even nodes.

Some of them might only participate in one topology, there doesn't
even need to be a "full" topology.

Henning

On Mon, Apr 4, 2016 at 8:24 PM, nemesis <(spam-protected)> wrote:
> 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
>
> _______________________________________________
> bmxd mailing list
> (spam-protected)
> https://lists.bmx6.net/cgi-bin/mailman/listinfo/bmxd