[OLSR-users] unstable routing tables with 0.4.8

[lee hughes]

also if you have lots of 802.11 hidden nodes, then your making the
whole situation worse, at low traffic loads , everything will seem to
be fine, as more traffic appears then broadcast traffic will collapse
first (not automatic retransmit), unicast traffic will degrade. the
more hidden nodes you have, and the more hidden nodes try to transmit
traffic, the problem will get worse and worse (quite quickly).

you can avoid this by

* good planing of nodes and good placement (i.e. all nodes can hear
all other nodes)

* back to back nodes connected via ethernet on different radio
channels (backhaul)

*use of p2p links with tight beamed directional ant's (no change of a
hidden node)

* reduce power on some nodes, if they are very close together.

* enable rts/cts and a small frag , although in practise I've not seen
that do much to combat hidden nodes, but this may of been buggy
software/drivers.

* reprogram the mac layer of 802.11 and do some sort of time sharing
protocol , rather than the free-for-all of 802.11  CSMA/CA  and use
some other timesharing/alhoa protocol... (not easy!!)

* less use of onmi's, onmi's not only have a short range, but the
noise they create beyond the range the a 802.11 radio can get a lock
and decode the packet is quite large.

* in siuatuation where you cant avoid hidden nodes, like a single onmi
node (on top of a mountain), with multiple directional , you must use
something like frottle (a layer 3 solution to a layer 2 problem)

http://aqua.comptek.ru/test/HiddenNode/hidden_node_en.html
http://frottle.sourceforge.net

* increase the speed of broadcast traffic, usually broadcasts and
multicast in 802.11 are always done at the lowest speed (so that all
stations in range of the ap can hear the broadcast), fixing this to
higher rate can have effect (I have to play with this more!), if your
packets is 'in the air' for less time, then there is less chance of
another node 'talking over your conversation without asking to
interupt'. This mode of thought make more sense in infrastructure
mode, where all clients are using the central ap at layer 2 to
communicate with the wired network and other wireless clients, in
adhoc setting this is different, we are using routing and olsr to do
that function at layer 3.

although I've not tested it myself yet, or seem to notice what effect
it has on olsr packets either.......

distributed frottle is what is needed, so the network can cope with
load, all nodes, even hidden or partial hidden nodes can fairly
transmit in peace and harmony...

802.11 currently a room full of people shouting at each other , trying
to be heard, without being polite and asking to talk... sounds like
goverment don't it ;-)..

Laters,
Lee


On 8/2/05, Thomas Lopatic <(spam-protected)> wrote:
> Hi Franca,
> 
> Your application traffic is probably unicast traffic, whereas OLSR
> traffic is broadcast traffic. For unicast frames 802.11 uses
> acknowledgements and retransmits a frame if it is not acknowledged. For
> broadcast frames no such mechanism exists. Hence, in 802.11 unicast
> traffic is inherently more reliable than broadcast traffic. If there's
> packet loss on a link, broadcast packets are more prone to loss than
> unicast packets.
> 
> What you experience might be that your application traffic increases the
> load on your wireless links substantially, which in turn leads to an
> increasing number of lost frames on your links. As menioned above, OLSR
> traffic will suffer more than your application traffic from this decay
> in link quality. Apparently, in your scenario, hardly any OLSR broadcast
> packets make it through the air, once your application starts sending
> unicast traffic.
> 
> What you might want to do:
> 
> * Decrease the intervals for OLSR message emission, e.g. the HELLO
> interval, so that OLSR nodes transmit OLSR packets more often.
> 
> * Increase the validity times for OLSR messages, e.g. the HELLO validity
> time, such that a couple of lost messages do not result in expired links.
> 
> Could you send your configuration file? I'll then be able to come up
> with more detailed suggestions.
> 
> -Thomas
> _______________________________________________
> olsr-users mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-users
>