[Olsr-dev] Too many OLSR messages...

[Markus Kittenberger]

On Sun, Aug 9, 2009 at 9:15 AM, Henning Rogge <(spam-protected)> wrote:

> Hello,
>
> I had a huge cleanup session for the OLSRd development code yesterday and
> discovered something BAD... something that might go back to the original
> OLSRd
> code from the diploma thesis of Andreas Toennesen (I tracked it back to the
> initial checkin in the olsr-ng mercurial repository in September 2004).
>
> OLSRd has the timing configuration for HNA/MID/TCs for each interface,
> which
> does not make really sense because this messages are flooded, so interfaces
> "configured slow" will still get messages from faster interfaces through
> flooding.

Yes it has not much sense, so afaik we talked about changing this, even as
we didn`t know how much traffic we could save doing so,...
i guess in vienna we have an average number of interfaces of about 2 (some
with only one, many with 2 interfaces, some with more interfaces), so we
would save araound 50% of traffic.

a bigger difference will be with hna announces,  if i currently dump for hna
messages from one of our 4 gateways i get about 60 per minute instead of 12
( = 4 gateways * 3 hnas per minute (configured hna interval there is 20
seconds))
as our gateways have more interfaces than average nodes.

>
>
> The really bad thing is that each of the messages send out through the
> multiple interfaces has it's own message sequence number !
>
> So OLSRd is NOT sending a common flooded information through all of it's
> interfaces, it's sending different messages, sometimes with slightly
> different
> content through the interfaces. This means that a node with 4 interfaces
> produce FOUR TIMES as much TCs/MIDs/HNAs per timeslot than anyone thought,
> which are a horror for duplicate detection and network load.
>
> The sollution in the development branch is to pull the timing parameters
> into
> the global section (out of the interfaces) and have one global timer for
> TCs,
> one for HNAs and one for MIDs which send messages through ALL of the nodes
> interfaces.

it would be only a minimal change to exisiting gui configurations, as they
(afaik) also use only one timing for all interfaces, but write it multiple
times into the generated config.

>
>
> Do we want this change backported into the stable branch ? I think yes.

Yes *g

> But how shall we do it without breaking too much stuff ? Do you think it's
> enough
> to have a "sane" TC/MID/HNA timing default and just ignore the settings in
> the
> interfaces ?

this may be desireful for many insane settings out there, but i think it`s
too bad to do so,..
.
i would let the first interface-timing settings configured in olsrd.conf
overrule all other interfaces. This would in most cases lead to the
completely same timings as an old olsr would have with this config file,..
(as most configs contain same timings for all interfaces)
.
and maybe integrate the interfaceunspecific timing options like in the
tiptip already in 0.5.6
which if they are used, will overrule all timings in interface blocks
Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20090809/40434f6d/attachment.html>