[OLSR-users] willingness vs. LQ routing

[Andreas Petersson]

Thomas Lopatic wrote:
> Hi Stefan,
> 
> Currently the willingness is not considered when creating the routing 
> table or when selecting MPRs when LQ extensions are enabled. But, as you 
> say, it probably makes sense to include the willingness in the link 
> quality determined by a node. The lower the willingness, the worse the 
> announced link quality for each link in the direction from the neighbour 
> to the node should be.
> 
> This would then affect the ETX and hence the routing table as well as 
> MPR selection. Strictly speaking, we would not need the willingness 
> anymore, as a node's willingness is reflected by the announced link 
> qualities.
> 

hi!
i am glad that this suggestion is brought up now, because i have some 
concerns towards the bandwidth scalability of dense asymetric olsr mesh 
networks.

the LQ metric is a great improvement towards a strict hop-count metric, 
but it is not the final solution.

at funkfeuer our topology consits basically of four types of links:

http://subway.funkfeuer.at/topo/

1)wired ethernet links - 100mbit
2)wireless coulds of omnidirectional antennas - varying from 1 mbit to 
18 mbit
3)wireless point-to-point links - typicall from 18mbit to 48mbit, but at 
quite constant speed.
4)vpn tunnels through the internet - typically 2mbit but with quite high 
delays of 20-100 ms, and by definition, without packet loss (since 
openvpn handles this)

the nodes "ag5" and "kh" have vpn links to the central router.

XXXomni means it is an onmidirectional antenna

XXXtoYYY means it is a point-to point link (directional to directional 
antenna)

nodes with the same prefix are connected via ethernet links

every node has typically 2 interfaces (one wired and one wireless), 
although some of them are not in use.

if we just look at the topology  and the packet losses then we have the 
following situation: a lot of traffic is routed though the vpn tunnels, 
since they have by definition a packet loss of 0. we could have much 
better speeds if we could somehow define the vpn tunnels as a backup line.

I would suggest the following: instead of a "expected transmission 
COUNT" metric one could use a "expected transmission TIME" metric.

keep the etx calculation as it works now.
configure one link_speed parameter per interface.
when calculating the edge values of the graph, divide the etx value with 
the link_speed. this is the new edge cost.

how difficult would it be to implement such a metric?

i have two ideas how this could be accomplished:

idea A)
when olsr sends out messages for which he assignes sequence numbers, he 
could voluntarily *skip* message numbers. that would trick the other 
nodes into thinking he has a lossy link. the amount of numbers skipped 
is indirectly proportinal to the assiged link speed.
so we would need to define a "maximum Speed" -> mS parameter and a link 
Speed -> lS. each sequence number will be increased by mS/lS (as a float 
value),but sent out rounded. that would automatically lead to a 
calculation of edge values how i proposed it, since the normal physical 
packet loss applies as normal.

idea B)
the link_speed information could be published via MID messages. the 
definition of MID messages needs to be changed in order to allow this.

greetings
andreas