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

[Axel Neumann]

On 05.03.2016 11:17, Henning Rogge wrote:
> On Fri, Mar 4, 2016 at 4:23 AM, Axel Neumann <(spam-protected)> wrote:
>> On 03.03.2016 20:01, Henning Rogge wrote:
>>> On Wed, Mar 2, 2016 at 7:42 AM, Axel Neumann <(spam-protected)> wrote:
>>>> Hi all,
>>>>
>>>> I noted that currently the metric elements are required properties of
>>>> NetworkRoutes and NetworkGraph objects.
>>>
>>> Yes.
>>>
>>>> With bmx6 (also old bmxd and bmx7) the metric to be used for
>>>> establishing routes towards a destination is individually defined by
>>>> each destination node.
>>>
>>> a netjson output should be the local view of the node, so I think this
>>> should still work for bmx7... does it?
>>
>> No! Even the local view of a single node is about many routes to
>> different destinations and each destination can dictate the metric
>> function to be used (e.g. hopcount, etc,..) and some of its parameters.
>> I understand the NetworkRoutes object can be used to represent these
>> with one Route object per local route.
> 
> Still, the metrics the user configured should make sense compared with
> each other...

I don't agree. Thats the point of having different metrics. Of course
DAT has different characteristics than ETX and it's values can not be
directly compared. Actually it would be nice if even the same GW can be
reached via different metrics (eg one path established based on ETX and
another based on DAT), but not compulsory. Think of a VOIP and a
http-proxy GW. The users might prefer different metrics for each.

> otherwise things like the gateway selection will be
> quite a bit "random".
Depends on your GW selection approach. But I think thats another story.

> 
>>> As a Distance-Vector protocol you most likely don't have a full
>>> NetworkGraph anyways.
>>
>> Right. But a local route (next-hop routing entry and corresponding
>> netjson Route object with destination, next, cost, and optimal source
>> address) can not represent the full NetworkGraph anyway.
> 
> That is right...
> 
>> I understand that NetworkGraph objects can be used to represent local
>> topologies. Even with distance-vector protocols :-)
>> And then some kind of collector can fetch all these NetworkGraph objects
>> from all nodes and aggregate them into a NetworkCollection object. Then
>> you have a full NetworkGraph.
> 
> Yes, data aggregation can give you more data... or conflicting data
> (local view is not always the same as the one of the rest of the
> mesh).
> 
>>>> I think also with olsrv2 multi-topology routing this might become
>>>> relevant as different metrics might then be used for different
>>>> destination addresses.
>>>
>>> Olsrd2 just outputs multiple NetworkGraph/NetworkRoute blocks with
>>> different metric/topology-id.
>>>
>>
>> Ok
>>
>>>> I therefore suggest to make the metric property of each route object
>>>> optional and add an optional metric property to the NetworkRoutes and
>>>> NetwokGraph objects.
>>>
>>> I don't think this is a good idea. This makes the whole graph
>>> practically useless for determining which node is close and which is
>>> not.
>>
>> IMO, to get a neutral and global view of the topology NetworkGraph and
>> NetworkCollection objects should be used.
>> To represent the cost of an end-to-end route the decision of those
>> controlling the metric function should be respected.
>>
>> Or let me ask the other way around: How to represent a BMX route to a
>> destination that (for some reason) dictated to be optimized for
>> hop-count? Assume that most other routes are ETX optimized.
> 
> How many metrics do you see to be used on a typical node?

As much as different metrics are used in the whole mesh.
I agree that nowadays usually only a single metric will be used because
the metric working best for scenario A will likely also work best for
scenario B. Exceptions are if one wants to experiment with new metrics
(which would be good). Or if we ever have really good metrics that are
indeed capable to optimize for delay tolerance, throughput,
interference, whatever...

> 
> If its a reasonable amount, you could easily put each of the metrics
> into its own NetworkGraph/-Route object, similar to what I am doing
> with multiple Topologies.

Are multiple NetworkGraph/-Route objects allowed (per node)? I dont see
a schema for an array of such objects.
Anyway, IMO its more clean if there could be simply an optional metric
property for RouteObjects that "overwrites" the "default" metric given
for the parents Network-Routes object.

/axel

> 
> Henning
>