Re: [manet] SMF in Manet and MPR

Maybe I was not clear. By shortest path, I meant the smallest number of hops for paths fitting a given metric. If your metric is "second per bit" (inverse of throughput), you will obtain the shortest path with a given throughput constraint. 

If VHF interface cannot fit the metric you will get a path made of UHF interfaces.

Philippe

----- Mail original -----
De: "Henning Rogge" <hrogge@gmail.com>
À: "Philippe Jacquet" <philippe.jacquet@inria.fr>
Cc: "Christopher Dearlove" <christopher.dearlove@gmail.com>, "manet@ietf.org IETF" <manet@ietf.org>
Envoyé: Mercredi 23 Mars 2022 21:41:11
Objet: Re: [manet] SMF in Manet and MPR

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