[olsr-dev] Status olsrd-0.4.10

[Andreas Tønnesen]

Hi Elektra,

I agree with you that the concepts in OLSR has not proved to be very
usable in real world scenarioes. And I _very_ much agree with your
comments on hopcount weight in one of your previous posts! My take on this
is that we will continue the 0.4 series as is, with rfc3626 conpability in
mind. But the 0.5 series should learn from all of this and implement new
ideas without beeing held back by compability issues. So yes, I guess it
will no longer be much OLSR left in olsrd 0.5 :-)
Let's start working on this next year!

- Andreas

> Hi -
>
> apart from the issues with the HTTP plugin 0.4.10 cvs should be ready to
> go on linux machines, as far as I was told from Thomas.
>
> I'm confident the LQ fisheye mechanism will improve olsrd a lot, like
> ETX did. It is likely that the succession of TTL values that is
> hardcoded at the moment will benefit from some tweaking based on
> experiences we'll gather when LQ-fisheye will be in use on bigger meshes
> than the local testbed.
>
> There is not much left from the INRIA ideas in olsrd as far as the
> Berlin mesh is concerned. We dropped hysteresis and replaced it with
> ETX. We dropped MPRs in Berlin, too - by now we are telling every node
> that it is a MPR. I suggest we'd better go for an option to switch off
> MPRs and MPRs messages completely. Every node should forward TCs as long
> as the TTL of the TC is valid. This is nothing new - it is the fisheye
> algorithm that was available in mobilemesh several years ago. I believe
> it is superior to MPRs regarding CPU overhead and routing loops.
>
> MPR information is a unneccesary message class in my opinion. A network
> with lossy links needs redundancy to keep information in sync on a local
> level. Adding another message class increases the headaches by
> introducing another source of failure that must be kept in sync.
>
> Like I wrote in previous posts there is no need to have routing
> information in sync in every node for the whole mesh. This is only
> useful for source routing. In fact a node needs only a vague idea what
> is going on 6 hops away and can trust the information of nodes that are
> nearer to a distant destination. A node needs to know who is out there
> and in which direction. It should have decent information abould
> adjacent nodes.
>
> Thus, I believe by using the fisheye mechanism we can reduce CPU
> overhead and gain stability. In a huge mesh with 250 routes TC messages
> arrive every 1 or 2 milliseconds because they are forwarded all the time.
>
> TC messages that have their origin several hops away have a lot of
> packet loss until they reach the oppposite end of the mesh cloud. That's
> fine as long as a few TC messages make their way and their validity time
> is long enough.
>
> Of course there is no guarantee that I'm right. But the feeling in my
> stomach says: Go for it! ;-)
>
> Btw: There is a nice 4-page article about olsrd and the Berlin mesh in
> the isssue of the german c't-magazin that was published this week.
>
> It would be nice to announce 0.4.10 before christmas and do a press
> release. I would volunteer to write it in english and german.
>
> But with all the recent changes it is hard to claim it is still olsr...
> ;-)
>
>
> cu elektra
>
>> We have a release candidate ready, but we are still awaiting
>> verification
>> from use on various OSes. I hope we can have it ready before Christmas.
>>
>> (hmmm... perhaps the internal buffersize of the HTTP plugin should be
>> user
>> configureable...)
>>
>> - Andreas
>>
>>
>>>Hey,
>>>
>>>what's the status of the release? We now have 250~280 routes in the
>>> berlin
>>>mesh and experience some probs. I would like to deplay a fixed version,
>>>because:
>>>
>>>- httpinfo-plugin uses fixed buffer too small for that route count
>>>- we would like to give the fisheye routing feature a chance
>>>
>>>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
>>
>>
>
>