Subject: [babel] directional airtime metric

From: Dave Taht <[email-masked]>
Date: Mon, 16 May 2016 10:19:48 -0700

looks interesting:

https://tools.ietf.org/html/rfc7779

-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 16 May 2016 19:54:10 +0200

> https://tools.ietf.org/html/rfc7779

Yeah, I know.  Look at the acknowledgments ;-)

It's basically a slightly simplified version of ETX (the simplifications
make it dependent on OLSRv2, while pure ETX is protocol-agnostic) multiplied
by the expected data rate.

-- Juliusz

---

From: Ferry Huberts <[email-masked]>
Date: Mon, 16 May 2016 20:34:27 +0200

So Juliusz,

Is it also implemented in Babel?

On 16/05/16 19:54, Juliusz Chroboczek wrote:
> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel
>

-- 
Ferry Huberts

---

From: Henning Rogge <[email-masked]>
Date: Tue, 17 May 2016 08:21:22 +0200

> by the expected data rate.

I am not sure I would call a conversion from symmetric to directional
a simplification. If your routing protocol calls for a symmetric
metric you would go for something like ETT, if it can work with
asymmetric metrics for links you can use DAT. Most of the work in the
draft is "window dressing" and a sliding window based averager for the
frame loss that works reasonable well.

Henning Rogge

---

From: Ferry Huberts <[email-masked]>
Date: Wed, 18 May 2016 14:51:18 +0200

> Is it also implemented in Babel?

This is meant as a serious question. Nothing else.
Is it implemented in Babel?

-- 
Ferry Huberts

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 18 May 2016 18:36:37 +0200

>> Is it also implemented in Babel?

Babel is the protocol.  Babeld is one of the implementations.

Babel (the protocol) is sufficiently extensible to implement DAT or ETT
(which I think is a better idea).

Babeld (the implementation) currently only implements ETX and Z3, which is
a refinement of ETX.  I think that doing a metric that takes time into
account, such as ETT is a good idea.

I'll be glad to implement ETT if somebody volunteers to do the experimental
evaluation (which is the bit that takes time when working on metrics).
I don't want to be in the same situation as with Z3, which I implemented
four years ago but still haven't had time to evaluate.

-- Juliusz

---

From: Ferry Huberts <[email-masked]>
Date: Wed, 18 May 2016 18:39:45 +0200

I was asking because at BattleMesh 2015 olsrd2 with ETT seemed to 
perform much better than other protocols without it.

I think batman has also switched to ETT now.

Disclaimer: I was not at WBM 2015 but this is what I heard at WBM 2016

-- 
Ferry Huberts

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 19 May 2016 02:50:12 +0200

> I was asking because at BattleMesh 2015 olsrd2 with ETT seemed to perform
> much better than other protocols without it.

My interpretation is that all protocols performed fine, with the exception
of BATMAN.  OLSRv2 performed very well under load, which I explain as it
being more resilient to loss of control packets, while OLSRv1 collapsed
under load, which I'm unable to explain.  Perhaps a limitation of the
implementation.

  http://docs.battlemesh.org/v8/1-the-mesh-of-death-adversity.html#results
  http://docs.battlemesh.org/v8/2-the-crossed-streams-jeopardy.html#results
  http://docs.battlemesh.org/v8/3-blowing-up-the-network.html#results

We didn't do any long-range tests, which is where DAT should shine, so
please don't conclude from these tests that DAT is not useful.

There's no doubt that DAT performs better than hop count, which is what
Standards Track OLSRv2 uses (DAT is experimental).  DAT/ETT should in
principle perform better than ETX (which is what Babeld uses by default),
but we need more empirical data before we take the complexity hit.

There's also the metric used by Lamparter in his hacked-up version of
IS-IS, which has a lot of potential but tends to mis-estimate the quality
of idle links.  I could be wrong, but I believe it might be more promising
than ETT/DAT, and more fun to implement.

I'll definitely be working on this kind of issues, but don't hold your
breath -- first item on my TODO is doing a formal evaluation of Z3.

-- Juliusz

---

From: Henning Rogge <[email-masked]>
Date: Thu, 19 May 2016 07:14:26 +0200

> but we need more empirical data before we take the complexity hit.

I think you are wrong on this point... OLSRv2 (RFC7181) defines the
metric as an external process, it does say nothing about hopcount
because everyone in the WG (now) knows that hopcount is really bad.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Thu, 19 May 2016 07:51:36 +0200

> Op 19 mei 2016, om 07:14 heeft Henning Rogge <[email-masked]> het volgende geschreven:
> 

(the WG == MANET WG)

Without an (external) process providing link metric data, OLSRv2 (and others...) fall back to hop-count.
In fact, RFC7181 specifies hop-count as tie-breaker, if path costs are equal.

Let us not discuss implementation details on MANET stuff and DAT/ETX/ETT metrics over here, this is the Babel protocol mailing list.

We discussed metric encoding a lot in MANET. We decided a 16-bit field for path costs is not sufficient. So in Babelv2 we could think of a 32-bit metric field.

Teco

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 19 May 2016 23:34:10 +0200

> Let us not discuss implementation details on MANET stuff and DAT/ETX/ETT
> metrics over here, this is the Babel protocol mailing list.

Well, Babel claims to work in hybrid networks, so it's important for us to
know of the experiences in the MANET space.  I always listen very
carefully to what Henning has to say.  And then disagree with him ;-)

> We discussed metric encoding a lot in MANET. We decided a 16-bit field for
> path costs is not sufficient.

I'd be interested to read up this discussion, I seem to have missed it.

> So in Babelv2 we could think of a 32-bit metric field.

RFC 6126 describes Babel version 2 (which is the third incompatible
revision, since I started counting at 0).  If we're designing an
incompatible revision, it's going to be 3.

-- Juliusz

---

From: Teco Boot <[email-masked]>
Date: Fri, 20 May 2016 10:20:21 +0200

> Op 19 mei 2016, om 23:34 heeft Juliusz Chroboczek <[email-masked]> het volgende geschreven:
> 

Henning posted outcome of our private discussions.
   https://www.ietf.org/mail-archive/web/manet/current/msg11751.html
>> Teco Boot mentioned a fourth disadvantage of the constants. 
>> The range between minimum and maximum metric is only a factor 
>> of ~ 2^16. If we want to keep the option to calculate all 
>> metric operations with 32 bit integer, 2^16 is still much 
>> lower than the maximum single hop metric of (2^32-1)/255 ~= 2^24.

My reason for having a wider field is that in a highly hybrid network, links can have very slow and lousy links and having very high-speed and reliable links. I personally have to deal with handheld satcom and multi-gig fiber. 

We ended up in encoded link metrics, uncompressed 24 bits. Path costs are 32 bits. The OLSRv2 compressed encoding is not appropriate for DV protocols, although it can be used.

> incompatible revision, it's going to be 3.

Yes, I remembered just after clicking on send :(

Teco