Subject: [babel] Babel path metric

From: Henning Rogge <[email-masked]>
Date: Wed, 26 Aug 2015 21:54:27 +0200

Hi,

maybe to get the (one?) ball rolling I would like to raise the point
of the "range" of the Babel path metric.

I think in Prague we talked about increasing the possible values for
this metric to a 4 byte integer. This would also align the range of
the path metric to the same values as OLSRv2 from the MANET group,
which means it should be possible to trade link metrics between Babel
and OLSRv2.

Henning Rogge

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 27 Aug 2015 10:26:50 +0300

> which means it should be possible to trade link metrics between Babel

I am not convinced about the need at least in base spec. 

Given e.g. use of of 256 metric values per hop, you run out of hop count values before you run out of metric. How granular do you want to be? I guess one could just use a function to convert the link metrics anyway, and that granularity sounds sufficient. 

In the extension-land, I think it is already possible to use arbitrary length ones..

Cheers,

-Markus

---

From: Henning Rogge <[email-masked]>
Date: Thu, 27 Aug 2015 09:30:18 +0200

> Given e.g. use of of 256 metric values per hop, you run out of hop count values before you run out of metric. How granular do you want to be? I guess one could just use a function to convert the li…

256 step is a limitation as soon as you add link-speed to the metric...

Even if you disregard everything except wifi you have a higher factor
between lowest and highest bandwidth than 256.

> In the extension-land, I think it is already possible to use arbitrary length ones..

Metrics are a CORE part of a routing protocol... changing the format
of metrics later creates an incompatible extension with old routers...
which should be unnecessary if we allocate a few more bytes.

Henning

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 27 Aug 2015 13:05:57 +0200

Henning,

Until now, all extensions to Babel were driven by user requirements:
Babel-Z was done for the needs of the Brussels community, Babel-RTT for
Nexedi, source-specific Babel for the needs of Homenet.  This policy has
served us well.

While I have no strong opinions about whether 32-bit metrics are needed,
I'll note that none of the communities using Babel have requested that
feature.

> of metrics later creates an incompatible extension with old routers...

Not in Babel -- Babel-Z is perfectly compatible with core Babel, although
it uses a different metric.

The way that works is that an extension can define its own metric, in
which case it MUST also announce a primary metric.  A router that speaks
the extension can use the extended metric, while a router that doesn't
uses the primary metric.

Of course, feasibility is only evaluated on the primary metric --
loop-freedom is a global property, and all routers must use the same
metric to ensure loop-freedom.

None of this, of course, is an argument against making the primary metric
32-bits wide.

-- Juliusz

---

From: Henning Rogge <[email-masked]>
Date: Thu, 27 Aug 2015 14:38:29 +0200

> the extension can use the extended metric, while a router that doesn't

So what do you think about using datarate-aware as the primary metric.

With wifi links going from 6 MBit/s to hundreds (or maybe thousands
with 802.11ac2) of MBit/s 16 bit seems to be a little bit tight.

Henning Rogge

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 27 Aug 2015 15:30:25 +0200

> So what do you think about using datarate-aware as the primary metric.

You mean k/datarate additive metric?  That's very specific to wireless,
wired wants widest-path routing (which cannot be used as the primary
metric for other reasons).  I'd much rather the primary metric were
something simple and generic, and anything fancy encoded in an extension
metric.

Henning, I really have no objection to a 32-bit primary metric, but
I don't think it's a strong argument for breaking compatibility with the
deployed base.  If there are other good reasons to break compatibility,
then we'll widen the metric.

-- Juliusz

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 28 Aug 2015 09:14:04 +0200 (CEST)

On Thu, 27 Aug 2015, Juliusz Chroboczek wrote:

> Henning, I really have no objection to a 32-bit primary metric, but I 
> don't think it's a strong argument for breaking compatibility with the 

What worries me is future capabilities.

If I were to set auto metrics related to wired speed, I'd for instance 
today choose:

Speed
10G  metric 1
1G   metric 10
100M metric 100
10M  metric 1000

Wifi would probably go in the 50-1000 range somewhere, depending on speed.

So if the current limit is 256 values per hop, I think that is actually 
more limiting than the total 65535 path limit currently (did I understand 
that correctly btw, babel has 8 bit per hop which is added together to 16 
bits total)?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Gabriel Kerneis <[email-masked]>
Date: Fri, 28 Aug 2015 09:56:29 +0200

Mikael,

> that correctly btw, babel has 8 bit per hop which is added together to 16
Babel distinguishes the cost (per neighbour, ie. hop) and the metric (per
route, ie. path). It currently uses 16 bits for both (RFC 6126
<https://tools.ietf.org/html/rfc6126>, sections 4.4.6 and 4.4.9). You can
see a live example of a babel network with costs and metrics here:
http://babelweb.wifi.pps.univ-paris-diderot.fr:8080/

Best,

Gabriel

---

From: Henning Rogge <[email-masked]>
Date: Fri, 28 Aug 2015 12:47:27 +0200

On Fri, Aug 28, 2015 at 9:56 AM, Gabriel Kerneis <[email-masked]> wrote:
> route, ie. path). It currently uses 16 bits for both (RFC 6126, sections
> 4.4.6 and 4.4.9). You can see a live example of a babel network with costs
> and metrics here:

So if you "limit" your mesh to 16 hops, you could use 12 bit for each link.

As a comparison, Olsrv2 use 24 bit for a link metric and 32 bit for a
path metric.

Henning Rogge