Re: [manet] SMF in Manet and MPR

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