reduce OLSR bandwidth by tuning emission intervals

[Clauz]

Hello, list.
As you might now, as ninux.org we are running some community networks in
Italy. Some of these are interconnected through DSLs, using a tinc VPN
over which OLSRd is running.

However, many people complain about the bandwidth used by OLSR traffic
over the DSLs.

My suggestion is to increase the emission intervals and validity times
(e.g. multiplying them x15) on the interfaces that talk on the VPN. This
is something expected in the RFC [*] and should get rid at least of some
HELLO traffic.

From a small emulation that I did, it looks like it works well: On the

"slowed down" link I see OLSR packets coming out at more or less the
smallest emission interval (i.e. the x15 HelloInterval), but with a
bunch of delayed TC and HNA messages inside (pcap here [^]). I think
that things work as long as the smallest validity time on the network is
smaller than the biggest emission interval.

Do you think there might be drawbacks in such setup in the real world on
a ~150 nodes network? For example RAM usage (we are using mostly
embedded devices)? Or perhaps because of the amount of TCs and HNAs
there will be no significant bandwith decrease?

cheers and thanks,
Clauz

[*] RFC 3626 paragraph 18.1:
"""
- the emission intervals (section 18.2), along with the
advertised holding times (subject to the above constraints)
MAY be selected on a per node basis.
"""

[^] http://zumbi.netgroup.uniroma2.it/~clauz/tmp/bigemission3.pcap

[Henning Rogge]

Hi,

I agree this would be possible.

But I don't see you will reduce the amount of data by a significant
factor, because HELLOs are not flooded through the mesh network. This
means you are only seeing Hellos from your neighbors, but you see MIDs,
HNAs and TCs from every node.

Which means that the traffic used up by the Hellos is not really large,
most of the Hellos will be put together with a TC/MID/HNA by the message
aggregation anyways.

Henning Rogge

Post by Clauz
Hello, list.
As you might now, as ninux.org we are running some community networks in
Italy. Some of these are interconnected through DSLs, using a tinc VPN
over which OLSRd is running.
However, many people complain about the bandwidth used by OLSR traffic
over the DSLs.
My suggestion is to increase the emission intervals and validity times
(e.g. multiplying them x15) on the interfaces that talk on the VPN. This
is something expected in the RFC [*] and should get rid at least of some
HELLO traffic.
From a small emulation that I did, it looks like it works well: On the
"slowed down" link I see OLSR packets coming out at more or less the
smallest emission interval (i.e. the x15 HelloInterval), but with a
bunch of delayed TC and HNA messages inside (pcap here [^]). I think
that things work as long as the smallest validity time on the network is
smaller than the biggest emission interval.
Do you think there might be drawbacks in such setup in the real world on
a ~150 nodes network? For example RAM usage (we are using mostly
embedded devices)? Or perhaps because of the amount of TCs and HNAs
there will be no significant bandwith decrease?

[Saverio Proto]

Post by Clauz
"""
- the emission intervals (section 18.2), along with the
advertised holding times (subject to the above constraints)
MAY be selected on a per node basis.
"""
[^] http://zumbi.netgroup.uniroma2.it/~clauz/tmp/bigemission3.pcap

is it correct that the values in the configuration file are for the
OLSR messages generated by the router ?

the OLSR messages that are forwarded (i.e. originator id is another
router) are forwarded asap without respect of EmissionInterval.
correct ?

ciao,

Saverio

[Russell Senior]

We have a network of about 60 nodes talking olsr primarily over VPNs.
We used to see about 10kbps with only IPv4, but it tripled to 30kbps
when we turned on IPv6 in parallel (~10 + ~20, i guess those 128-bit
addresses add up!). Any suggestions for interval parameter tweaks to
reduce that traffic?

Post by Saverio Proto

Post by Clauz
"""
- the emission intervals (section 18.2), along with the
advertised holding times (subject to the above constraints)
MAY be selected on a per node basis.
"""
[^] http://zumbi.netgroup.uniroma2.it/~clauz/tmp/bigemission3.pcap

is it correct that the values in the configuration file are for the
OLSR messages generated by the router ?
the OLSR messages that are forwarded (i.e. originator id is another
router) are forwarded asap without respect of EmissionInterval.
correct ?
ciao,
Saverio
--
Olsr-users mailing list
https://lists.olsr.org/mailman/listinfo/olsr-users

[Henning Rogge]

The timing parameters only depend on the change-rate of your network.
If your network is very stable, you can get away with longer timings.

Of course to grab an idea from above, a variable timing of the
TCs/HNAs/MIDs would be better.

Henning Rogge

On Wed, Feb 27, 2013 at 8:40 AM, Russell Senior

Post by Russell Senior
We have a network of about 60 nodes talking olsr primarily over VPNs.
We used to see about 10kbps with only IPv4, but it tripled to 30kbps
when we turned on IPv6 in parallel (~10 + ~20, i guess those 128-bit
addresses add up!). Any suggestions for interval parameter tweaks to
reduce that traffic?

Post by Saverio Proto

Post by Clauz
"""
- the emission intervals (section 18.2), along with the
advertised holding times (subject to the above constraints)
MAY be selected on a per node basis.
"""
[^] http://zumbi.netgroup.uniroma2.it/~clauz/tmp/bigemission3.pcap

is it correct that the values in the configuration file are for the
OLSR messages generated by the router ?
the OLSR messages that are forwarded (i.e. originator id is another
router) are forwarded asap without respect of EmissionInterval.
correct ?
ciao,
Saverio
--
Olsr-users mailing list
https://lists.olsr.org/mailman/listinfo/olsr-users

--
Olsr-users mailing list
https://lists.olsr.org/mailman/listinfo/olsr-users