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

[Nemesis]

Hi Axel,

sorry for my late response, I would have liked to answer earlier.

On 03/10/2016 10:26 AM, Axel Neumann wrote:
> Hi Nemesis,
>
> response inline.
> Crossposted (due to relevance) also to bmxd mailing list.
>
> On 06.03.2016 17:14, Nemesis wrote:
>> Hi Axel,
>>
>> On 03/04/2016 04:23 AM, Axel Neumann 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,
>> thank you for joining.
>>
>>>>> 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.
>> Let me understand:
>>
>>   * can a packet start being routed with hopcount metric and then in the
>>     middle of its path take a different route because a node wants to
>>     use a different metric?
> NO! A single (un-tunnelled, unicast) packet has only one destination
> address. So all routes to this destination node (even those inside the
> routing table of other nodes) are based on the same metric (as defined
> by the destination node owning this address). Because your routing table
> contains routes to many different destination nodes, routes could be
> based on a different metric.
>
> Short example for nodes A,B,C,D (A-D is huge-latency-satellite link, A-B
> is lossy wireless link)
>
> A---B---C
>  \  |
>   +-D
>
> Routes in node A:
> To: B, via: D, metric: DAT (something optimizing for TP)
> To: C, via: B, metric: HopCount (minimizing hops)
> To: D, via: B, metric: RTT (minimizing round-trip time)
>
> Routes in node B:
> To: A, via: D, metric: DAT
> To: C, via: C, metric: HopCount
> To: D, via: D, metric: RTT
>
> Routes in node D:
> To: A, via: A, metric: DAT
> To: B, via: B, metric: DAT
> To: C, via: B, metric: HopCount
>
> You can see that all routes in all nodes to a given destination (e.g. C)
> always follow the same metric (for C it's always HopCount).
>
> Note: a) If two routes are pointing to the same destination node then
> both are based on the same metric. b) This works as long as only unicast
>  (not anycast) routing is involved (thus each destination address is
> announced and used only by a single node).
> BMX7 ensures both by using cryptographically generated addresses (CGA)
> that prove the address ownership.

Ok, thx for the explaination.

>>   * how many different metrics are available in bmx7?
> Same as in BMX6. 5 Base functions where each can be a bit parametrized.
> But one shouldn't focus on the '5'. It is more about being conceptually
> able to support multiple metrics in parallel and to give users (node
> admins) the freedom to decide. Currently, most of these 5 are just
> experimental and unfortunately, yet all of them are based on
> broadcast-packet loss statistics which gives only a very limited view of
> a link. So I hope new and better ones could be contributed soon.

Do you know other routing protocols that implement multiple metrics?

@Henning: does OLSRd2 also use multiple metrics?

>
>>
>>>
>>>> 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.
>>>
>>> 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 correct. I have already started working on this idea, a few days ago
>> I just wrote a blog post about it in which I also mentioned the
>> possibility of a generic collector for distance vector routing protocols:
>>
>> http://nemesisdesign.net/blog/coding/network-topology-visualizer-django-netjsongraph/
>> (see "RECEIVE Strategy" and "Next steps" to understand what I'm talking
>> about)
>>
>> This type of implementation is key to understanding the actual
>> limitations of the specification and to understand the priorities that
>> need to be addressed.
>>
>> If you could add a way to retrieve the local NetworkGraph from bmx7, I
>> could already start testing the whole idea and share my findings here.
>
> There is a topology plugin [1] for bmx6 that makes the node, where it's
> loaded, describe the best link to each of its neighbors and update this
> description when links change. Because the descriptions of all nodes are
> kind of flooded over the mesh all other nodes can see them. All
> currently available link descriptions, but also local routes, links, and
> interfaces can then be exported in ASCII table or json format. When
> ported to bmx7 I'll let you know..

Yes, keep us up2date, and let's talk about this idea at the next battlemesh.
I'll likely be working more on this subject in the following months.
Right now i'm mostly focused on implementing the remaining objects of
the NetJSON spec: DeviceConfiguration and DeviceMonitoring.

>>>>
>>>>> 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.
>>>
>>> /axel
>> I understand your concern.
>>
>> netjson allows to define custom properties, Henning is using a few ones
>> to add the "incoming" routing metric in olsrd2, for example; another
>> possibility is to output different /NetworkGraph/ objects for each
>> metric wrapped in a /NetworkCollection/;
>>
>> But I think it would be better to take a step back and ask ourselves:
>> *"why are we are doing this?"*
>>
>> The first thing we must do is to understand why we need standard
>> attributes like "cost", and agree on some common use cases.
>>
>> The spec on this point doesn't currently help very much (so I'll need to
>> improve it):
>>
>>     *cost:* value of the routing metric indicating the outgoing cost to
>>     reach the destination; lower cost is better, it MAY be omitted when
>>     representing static routes; Infinity and NaN are not allowed in
>>     accordance with the JSON RFC [RFC7159]
>>
>> The main goal of having a standard cost attribute in /NetworkGraph/ was
>> to make it possible to determine in a standard way the quality of links
>> in a network.
>> For example: with a standard cost we could show different colors
>> depending on the range of the cost,
>> eg: "very good" could be blue, "ok" could be "green", "problematic"
>> could be orange and "poor" red.
>>
>> In an ideal world, *I would love to have a standard cost attribute* that
>> would mean the same thing (or at least very close) by most protocols and
>> at the same time *I would also like to have a standard way to collect
>> and process different type of metrics* used by each protocol.
>>
>> What do you think? Too utopic or achievable?
> Hmmm, temporarily achievable with compromises.
> I see two challenges for standardizing cost with a single dimension
> and range.
>
> 1) There exist completely orthogonal cost dimensions where each
> completely makes sense. For example Bandwidth is what most users care
> about. Except those that ever used a satellite link and know how
> annoying high RTTs can be. Thinking globally the cost should also
> reflect how much of the overall available network capacity it consumes
> for transmitting over a certain path. And so on...
> The metrics somehow combine several of them into a single-dimension
> value. Agreeing and standardizing "The best" way to calculate this cost
> will be controversy. Also it will change over time as technical
> possibilities increase to obtain certain link characteristics. For
> example I assume that DAT metric would have been harder to implement
> some years ago.
>
> 2) Also the ranges will change over time. So a standardized range for
> blue (best) may become useless in few years where GB wireless links may
> be common.
>
> Think of these energy labels (for e.g. washing machines) starting with
> A,B,C. Nowadays the range got extended with A+ A++, and A+++ to
> represent the better efficiency.
> And they also introduced new dimensions for water consumption, noise,
> speed, cleanness,...
> In that sense I would even argue for being able to express various cost
> values with different dimension for each link. Or, keep the standard a
> bit flexible for future evolutions.

I see.

I think we should have realistic expectations about what we can achieve.
We also need to iterate gradually to improve the spec and the
implementations to obtain anything useful at all: Rome was not build in
a day.

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?

Federico