[Olsr-users] reduce OLSR bandwidth by tuning emission intervals

[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

On 02/26/2013 12:57 PM, Clauz wrote:
> 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?



-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:(spam-protected) http://www.fkie.fraunhofer.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6169 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20130226/cffc45f8/attachment.bin>