[B.A.T.M.A.N.] Diversity in BATMAN [was: Battlemesh v5 tests]

[Juliusz Chroboczek <jch@pps.jussieu.fr>]

> They just decide upfront a set of alternative interfaces, and then
> choose the best interface that it is not the incoming one among this
> set, for each packet.

Can you confirm that, Simon?

> You have no way to declare that two different wifi interfaces interfere, for
> instance; it is roughly similar to babel -z1.

Unlike in Babel, however, where that happens at the metric level, in
BATMAN it appears to be implemented at the route selection level.  I'd
like to better understand all of the tradeoffs involved.

On the one hand, doing things at the route selection level makes
BATMAN's approach to diversity completely metric-agnostic, and avoids
tricky issues of metric compositionality.  On the other hand, encoding
the diversity information in the metric has the advantage of propagating
the information to other nodes.

Consider the following topology (all links assumed lossless), where
we're trying to route from A to S:

      B---C
     /     \\
    /       \\
   A          S
    \        /
     \      /
      B'---*C'  (C' has just a single interface)

In Babel, even with just Z1,the diversity information is encoded in the
metric, and so B announces a smaller metric than B'; this causes A to
prefer the ABCS route to the AB'C'S route.  Unless I'm misunderstanding
something, in BATMAN no information is propagated to A -- the information
about the extra diversity in the upper route is purely local to C.

(Note that this is completely orthogonal to explicitly propagating
diversity information in addition to the metric, which only happens in
Babel-Z3.)

-- Juliusz