[olsr-dev] MRP selection (all OLSRd versions)

[Andreas Tønnesen]

Sven-Ola,

Ok, in the scenario you drew the clouds must be connected for this MPR
selection to happen since all two hop neighbors must be covered by an MPR.

I guess the problem is that there is only intermittent connections between
the two clouds? If this scenario is combined with very large message
intervals, then detection of broken links leading to MPR recalculation
will take a long time. I guess you suggestion makes good sense in this
case making it not nessecarry to "wait" for MPR recalculation triggered by
link loss detection.
Given that my understanding of the problem is correct, let's put it on our
to-do list "Calculate MPRs pr. interface" :-)

- Anderas

> Andreas,
>
> (Mail with pdf attachment obviously halted. PDF is here:
> http://styx.commando.de/sven-ola/mprcoverage.pdf )
>
> If no control packets are forwarded between the two meshes (see attached
> pdf) no routing will occur AFAIK. And you are right: We normally
> circumvent
> this behaviour (wrong/unoptimal MPR selection) by setting a high
> MPRCoverage. Additionally, those links are often ethernet based/managed,
> so
> they have very low packet loss which will prefer them in the MPR selection
> process.
>
> MPR selection is a dynamic process, they change with the network topology
> and weather conditions of course. In the scenario drawn in the pdf, no
> routing / very slow routing will happen between those two clouds AFAIK.
> For
> this reason at minimum one MPR on each iface may be required.
>
> LG, Sven-Ola
>
> "Andreas "Tønnesen"" <(spam-protected)> schrieb im Newsbeitrag
> news:(spam-protected)
>> Hey Sven-Ola,
>>
>> The only way MPR selection has any impact on regular data
>> routing(remember
>> MPRs are only used to forward OLSR packets, and has no effect on regular
>> data forwarding) is by the effect of the TC redundancy set in nodes.
>> This
>> value specifies if a node should announce all links or just
>> MPRs(selected
>> or selectors). As I have understood it, most uses of OLSR LQ sets TC
>> redundancy to max(which will be the default value in 0.5) so that all
>> links in the network are known to all nodes, meaning that MPR selection
>> has no impact on route selection.
>> Now since MPRs are only used for forwarding OLSR control packets, not
>> regular data traffic and it has no effect on routes being chosen as long
>> as you use TC redundancy 2, I don't think changing the MPR selection
>> would
>> yield the results you want unless I missunderstand something(which I
>> very
>> well might do :-) ).
>>
>> - Andreas
>>
>>
>>> Thomas, Andreas,
>>>
>>> while I do not want you guys to disturb while playing with new
>>> features,
>>> I
>>> have a moderate urgent bugfix request. Normally, I would do it for my
>>> own,
>>> but this one evt. needs some internal data changes and I am not too
>>> familiar
>>> with that.
>>>
>>> OK. I am not happy with the MPR selection done in LQ and in RFC mode.
>>> Investigated only the lq_mpr() so far, but the RFC mprselect() may do
>>> it
>>> the
>>> same way. With multihomed hosts (nodes with more than one radio or
>>> nodes
>>> bound to ether backbones and wifi) at least *one* MPR should be
>>> selected
>>> on
>>> each interface. Otherwise inter-suburb routing may be dead /
>>> unrealiable
>>> /
>>> really slow.
>>>
>>> Example: We connect 2 suburbs with a long distance managed link running
>>> on
>>> a
>>> double radio node. Other radio is Ad-Hoc. If all MPRs (due to LQ/ETX
>>> values)
>>> are selected on the Ad-Hoc radio, no routing info is tranmitted over
>>> the
>>> managed link. Same for RFC, if e.g. all AdHoc neighbours have high
>>> willingness values configured. Very slow routing happens, if a really
>>> unreliable ad-hoc parallel link exists between those suburbs.
>>>
>>> Investigated the code in lq_mpr(). There is a chance, that more than
>>> MPRCoverage MPRs are selected (due to hashing) but I would call that a
>>> feature not a bug. More neighbours, more MPRs. Thats OK :) But at least
>>> one
>>> MPR for every interface - that code does not guarantee this.
>>>
>>> Comments?
>>>
>>> LG
>>> Sven-Ola
>>>
>>>
>>>
>>> _______________________________________________
>>> olsr-dev mailing list
>>> (spam-protected)
>>> https://www.olsr.org/mailman/listinfo/olsr-dev
>>>
>>
>>
>>
>> _______________________________________________
>> olsr-dev mailing list
>> (spam-protected)
>> https://www.olsr.org/mailman/listinfo/olsr-dev
>
>
> _______________________________________________
> olsr-dev mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-dev
>