Re: [manet] SMF in Manet and MPR

If there’s a shorter route, even if more hops, MPRs will find it. So not suboptimal in that regard.

Flooding will try to travel over a shortest route. It might also flood via other routes, because that’s the nature of flooding.

Flooding might be suboptimal in some regards, though not that one. But of course in NHDP/OLSRv2 to want optimality is to put the cart before the horse. We use the MPR flooding to find out remote information. We couldn’t use it - even if we collected the right metrics - to select MPRs as we already need them.

> On 23 Mar 2022, at 20:41, Henning Rogge <hrogge@gmail.com> wrote:
> 
> The problem is there might be a shorter 3-hop path to a single-hop
> neighbor than the direct path to it... which leads to a bad MPR
> choice.
> 
> So I think NHDP-based MPR selection is sub-optimal.
> 
> Henning Rogge
> 
> On Wed, Mar 23, 2022 at 9:04 PM Philippe Jacquet
> <philippe.jacquet@inria.fr> wrote:
>> 
>> If you choose the MPR with a given metric then the routing graph will automatically show the shortest path wrt the metric as the consequence of the 2 hop MPR coverage property. If such path does not exist then the flooding cannot be achieved wrt the metric.
>> 
>> Philippe
>> 
>> ----- Mail original -----
>> De: "Henning Rogge" <hrogge@gmail.com>
>> À: "Christopher Dearlove" <christopher.dearlove@gmail.com>
>> Cc: "manet@ietf.org IETF" <manet@ietf.org>
>> Envoyé: Mardi 22 Mars 2022 09:37:47
>> Objet: Re: [manet] SMF in Manet and MPR
>> 
>> My point about this issue is that as soon as the router knows that
>> there is a better way to a one-hop neighbor than the direct one, it
>> needs to stop using the link neighbor for flooding. But this is not
>> possible based on NHDP information, only with the help of the full
>> routing graph... which gives quite a few additional challenges because
>> of the cyclic dependencies.
>> 
>> It's the same both for TC flooding and Multicast forwarding. Using a
>> VHF connection to flood them is a waste of precious (VHF) airtime if
>> we have a multihop UHF connection. It's just getting worse when we add
>> userspace (multicast) traffic to the issue.
>> 
>> Henning Rogge
>> 
>> On Tue, Mar 22, 2022 at 9:23 AM Christopher Dearlove
>> <christopher.dearlove@gmail.com> wrote:
>>> 
>>> Flooding is done over the VHF interface because the whole point of flooding is to reach everyone. And there might be some routers you can only reach using the VHF interface. If you know that you can always reach someone using only UHF flooding, and you consider that flooding via VHF is a disaster, why is it one of your Manet interfaces? Or if you want one hop transmission but not MPR selection why not set willingness zero (never) on that interface?
>>> 
>>>> On 22 Mar 2022, at 06:31, Henning Rogge <hrogge@gmail.com> wrote:
>>>> 
>>>> On Mon, Mar 21, 2022 at 7:17 PM Christopher Dearlove
>>>> <christopher.dearlove@gmail.com> wrote:
>>>>> 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.)
>>>> 
>>>> I don't think metrics can resolve my problem. The problem arises from
>>>> calculating the MPRs just from the 2-hop neighborhood.
>>>> 
>>>> Let me sketch the problem.... imagine you have a Mesh with both VHF
>>>> (slow long range) and UHR (fast short range) radios.
>>>> 
>>>> Now imagine your router R has a neighbor A on VHF, which is two-hop
>>>> reachable on UHF... if A also has a neighbor even further away, A will
>>>> ALWAYS be a MPR, because the neighbor of A is at least three hops away
>>>> over UHV.
>>>> 
>>>> Unicast routes will still flow over the UHF network, but flooding will
>>>> be done over VHF, which is a problem.
>>>> 
>>>>> 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.
>>>> 
>>>> The OLSR implementation from olsr.org has something like this called
>>>> BMF... it was a disaster. ^^
>>>> 
>>>> Henning Rogge
>> 
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet