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

[Sven-Ola Tuecke]

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