[olsr-dev] Re: [OLSR-users] Differing metrics for route decision

[Sven-Ola Tuecke]

Thomas et al,

fiddeling with different ETX calculations will not have any reliable effect. 
The current math operator ("+") is sufficent for the real situation. What's 
more critical (as we all know): There is a fundamental measurement error, 
since packet loss is calculated using broadcasts while data traffic/routes 
are meant for unicast. Remember: Wifi drivers tend to send that stuff on 
differing rates e.g. OLSR-broadcasts with the multicast rateset using 1Mbit 
B-Mode and Data traffice with unicast rateset using 28 Mbit G-Mode.

While I'am at it: Have a little patch for that ETX calculation which seems 
to run well. Only meaningful when you use Windowsize > HelloInt * HalloVal 
as with Freifunk/Berlin Mesh: WinSize is 100, Hello is 5 sek, HelloVal is 90 
sek. Patch is located here:

http://olsrexperiment.de/sven-ola/nylon/olsrd-bb-files-for-nylon/files/olsrd-fixes.patch

(Ah - that will also change the Fish-Table. Changed table is prepared for 
the forced fish since no ttl=0xff is used any more. Makes it possible to put 
TTL=0xff into /dev/null one day. For the IPv6-Size-Change I'am not too 
sure...)

LG Sven-Ola

"Thomas Lopatic" <(spam-protected)> schrieb im Newsbeitrag 
news:(spam-protected)
> [...]
>
>> If I'm correct OLSRD today have three methods to calculate
>> metric/routing: OLSR, ETX and Fisheye.
>
> Well, I wouldn't count Fish Eye as a separate metric. It just limits the
> number of hops that a TC message is allowed to travel, i.e. its time to
> live, so that not every node sees every TC message, so that close nodes
> get updated about my status more often than nodes that are a couple of
> hops away from me. The information contained in the TC messages is the
> same as with "pure" ETX, though.
>
>> Would it be simpler to maintain (less code duplication and so on) if
>> olsrd had a common generic framework for the metric/routing calculation
>> and plugin-like support for the actual calculation? Just an idea..
>
> Yes, I believe it would. However, one of the things that we'd need to
> think through for this is the following. Metrics come in a couple of
> variants. They differ in how the metric of a multi-hop path is derived
> from the metrics of the individual hops. I think that we have three
> different kinds.
>
>  * Additive metrics. Simply add the metrics of the individual hops to
> obtain the metric of the full path. An example for this is ETX. If we
> have a two-hop path from node A via node B to node C, the ETX for the
> path from A to C is the sum of the ETX between A and B and the ETX
> between B and C.
>
>  * Multiplicative metrics. Packet loss is multiplicative, I'd say. If
> 50% of the packets make it from A to B and 40% make it from B to C then
> the probability of a successful packet transmission on the path A -> B
> -> C is 50% * 40% = 20%.
>
>  * Minimum metrics. If we look at the bandwidth of a path then the hop
> that has the lowest bandwidth is the bottleneck and dictates the
> bandwidth of the complete path. The bandwidth of A -> B -> C then is
> minimum(bandwidth(A -> B), bandwidth (B -> C)).
>
> For additive metrics the Dijkstra algorithm applies. But does it also
> apply to the other two types? What about combinations of metrics of
> different kinds, e.g. something based on ETX and the bandwidth? Hmmm.
> Anyone?
>
> [...]
>
> -Thomas
>
> _______________________________________________
> olsr-dev mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-dev