[OLSR-users] willingness vs. LQ routing
Tue Feb 8 15:29:09 CET 2005
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
i am glad that this suggestion is brought up now, because i have some
concerns towards the bandwidth scalability of dense asymetric olsr mesh
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:
1)wired ethernet links - 100mbit
2)wireless coulds of omnidirectional antennas - varying from 1 mbit to
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
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:
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.
the link_speed information could be published via MID messages. the
definition of MID messages needs to be changed in order to allow this.
More information about the Olsr-users