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

Axel Neumann (spam-protected)
Thu Mar 10 10:26:27 CET 2016


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.

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

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

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


/axel

[1]
http://bmx6.net/projects/bmx6/repository/revisions/90b162ce24313b06e076bd554f406d704de48e84



>
> Federico
>
>
> _______________________________________________
> Interop-dev mailing list
> (spam-protected)
> https://lists.funkfeuer.at/mailman/listinfo/interop-dev
>







More information about the Interop-dev mailing list