[Olsr-dev] [OLSR-dev] OLSR for Windows Mobile platforms by Moviquity

[sebastian sauer]

Wed 15 Jul 2009 11:14, Henning Rogge wrote:
> Am Wed July 15 2009 11:01:39 schrieb Victor Gras Valenti:
> > We discovered the same issue when testing... so, ok, we are going to check
> > ETX, in order to compare it with the ideas we had.
in general it's not trival to find a suitable metric for a highly dynamic "loss 
network" like our mesh nets.

hop count and ETX has some nice properties like "monotonicity" (some papers
call that "isotonicity" -- dunno why.) 

in practice things are even thougher -- none of the bigger OLSR mesh
setups work without ETX cheating. Hence on guarantee that the metric of
any randomly chosen path is really monotonic -- in a real life setup.


> The problem with hopcount metric is easy to explain. Hopcount metric based 
> routing tries to minimize the number of hops to the destination. This works 
> well in wired networks, but with mesh networks it tries to use links 
> connection stations far away.
yep, hop count is an idiotic choice for a dynamic "loss network". because
the bandwidth of the "edges" / links is not stable over time.

hop count works well for static wired routing, because the bandwidth of
the links is constant over time. 

hop-count metric only works well for trival stuff like cable breakage and 
death of a node.

> This links are typically lossy and unstable, so you don't get a working mesh.
Full ACK. 

> You can try to reduce this problem with better hysteresis (filtering links 
> with signalstrength & lossrate parameters), but this might split the net 
> because you don't propagate the only link (it was "too bad") connecting two 
> parts of a mesh cloud.
yep.