[Olsr-users] OLSR Questions

[Markus Kittenberger]

Am 30.12.2009, 18:34 Uhr, schrieb Randy Buck <(spam-protected)>:

> Thanks for the quick reply.
>
> Can you define 'G' for me.  I'm relatively new with OLSR.
*G should just be something like :-)
>
>
> We are using version 0.5.6 r7.   I've attached three files to help with  
> the
> analysis.  As you can see in the middle of routes.txt, there are several
> cases where a route is deleted and then added 2+ seconds later.  These
hmm this should be new enough (as no fixes in the routing code where made  
since than)

> files
> are each partials of the "sending" node in a 100 MB file transfer.  They
> show the topology, Dijkstra events, and Links.  The file transfer was  
> over a
> "chain" starting at node 10 and ending at node 6.  The "chain" is 10 ->  
> 11
> -> 12 -> 13 -> 3 -> 6.  Because we are using OLSR, this isn't necessarily
> the order in which packets are sent.  For example, 10 can see 11 and 12,  
> 11
> can see 10, 12, and 13, etc.  There are several potential routes between
> nodes 10 and 6.  Let me know if you need more explanation here.
hmm so theese problem only occurs if u stress the network with an file  
transfer at full available speed?

this may lead to big problems if you don`t have any QOS protecting olsr  
traffic,..
>
>>
>>
>>> 3) Why does OLSR sometimes change route when the mesh has no traffic?
>>>
>> why not?, olsrd does not care about traffic

but unluckily this does not mean that traffic will not have side effects,..

>
> Coupled with issue #2 above, constantly changing routes is a problem;
> albeit, a small problem.
depends on what type of route change

most route changes should result in no problems, or just a small tcp  
packet reordering

but some route changes, result in packet loss (an loops), usually only  
theese are problems

but in theory they do not happen, if no huge dramatic topology changes  
occure (or there are inapropriate configurations (or a bug *G))
>
>>
>>
>>> 4) Why does OLSR change routes when it gets only a minimal cost
>>> improvement?
>>>
>> why not?, any received change is relevant, the only hysteresis in olsrd
>> (only in new versions aswell) is done when sending packets
>>
>> there used to be an imcoming hysteresis aswell, but i hope no parts of  
>> it
>> are active any more,...
>
>
> Hysteresis is turned off.  Again, this is an issue when we have to wait  
> 2+
> seconds for the route to reappear.  Can we set some sort of threshold  
> that
> has to be hit before a route is considered bad/better?
as there is no way to ensure that this local thresholds do not sum up to  
different routing decission through the network, local hysteresis on  
imcoming data is a bad idea

(btw there is already an 10% hysteresis on the lq values a node sends out)  
-> and if nothing helps we could try to change this...

such incoming stuff exists for historical reasons (but only for the  
default route)
but in general it just makes new problems, so we better find out the cause  
of your problems.
before trying to cure it,.. .(-;
>
>
>
> The links in the above mentioned "chain" all show ETX of 1.0 when there
> isn't a file transfer occuring.  So I am under the assumption with that
> information that we have good links.

This even more sounds to me like olsr traffic is not priorized against  
other traffic.
Am i right?

So when u have much traffic, olsr traffic gets partly discarded (by your  
routers kernel), resulting in somewhat dramatic cost changes for oslr, and  
usual undesireful behaviour of olsr in this case,...

lg Markus