Re: [manet] SMF in Manet and MPR

[Christopher Dearlove <[e-mail]>]

On 21 Mar 2022, at 13:06, Henning Rogge <[e-mail]> wrote:
> I am reacting to the talk during the IETF meeting (chat didn't worked
> for me for some reason).
> 
> My trouble with the MPR optimization for SMF (and a bit with SMF in
> general) is that we currently have no good MPR algorithm for
> heterogeneous Manet (Manet with multiple different types of radios).
> 
> The only described MPR algorithm (OLSRv2 appendix) works separately
> for each interface... which means it always selects MPRs on long-range
> (and slow) interfaces, which is really not what we want.

This depends on how you set up your link metrics. Flooding MPRs have
the option to use or not use link metrics. But if your interfaces are different
enough that you’d rather use multiple hops on a better interface rather
than fewer hops on a poorer interface, then you should be using link metrics.
If you aren’t, you will have problems. (They probably show up even faster
with routing.)

How to create those metrics? Now that is an unspecified problem. But the
problem is that, not the MPR algorithm itself.

Now is there a problem with the MPR algorithm? No and yes. No, it does
what it should. Yes, in that there are things that it doesn’t consider that
could improve it. One of those is whether it’s better to distribute or
concentrate MPRs, which depends on factors beyond where OLSRv2
could go, including the nature of your MAC layer, on the battery limitations
of your devices, and on your mobility (is a critical node destined to always
be a critical node, or does that keep changing?) Also, when your topology
changes, should you try to make minimal changes to your MPR selection
or should you try to always be maximally efficient? (My implementation,
which I no longer have access to, offered you at least three options there.)

> Of course there is also the problem that SMF completely ignores
> routing metrics... and the problem that we lack a good dataplane for
> SMF, which often results in horrible "raw socket trickery"...

And so the problem here is with that SMF predates link metrics, and hasn’t
been updated. It was even worse when I - and others - tried multicasting
by intercepting packets in the stack, wrapping them up as a new OLSR (v1)
message type and reinjecting into UDP (OLSR port), plus the reverse at
reception. Fun days.

> So in general I would not suggest to people using SMF because I have
> yet to find an use-case where SMF is doing well. Often an
> application-specific forwarding strategy is much better than a generic
> IP one in terms of multicast in Manet.