[Olsr-dev] OLSRd 0.5.4 and 0.5.5 with ETT available

[Hannes Gredler]

Erik Tromp wrote:
>> Jens Nachtigall wrote:
>>> Hence, best way to do it is PacketPair atm, at least for a generic 
>>> routing daemon like olsrd that should be working independent of what's 
>>> below the IP layer.
>> if your target OS does not support what *should* be around, 
>> then we could fallback to packet/pairing.
>>
>> or let me ask the question in a different way:
>> if one OS in the wireless mesh does not support wireless APIs 
>> and cannot compute 'good' metrics, why should we squash the 
>> rest of the network to that lower limit.
> 
> With 'that lower limit' you mean 'use PacketPair'? And with 'squash'
> you mean 'force'?

your understanding is correct

>> actually i am more in favor of a reflection of this in the metric.
>>
>> if the target OS can do good airtime estimation (by means of 
>> reading out wireless stats) its offered links should be more 
>> attractive than a link offered by a system that needs to do 
>> heuristics.
> 
> IMHO, PacketPair is just as much heuristics as ARF.

its not just packet-pair ... it is actually packet-pair plus
statistics/heuristics - i have some concerns (altough no proof) that the 
required statistics (if not specified carefully) might get us into
non-interoperable implementations. it is IMO much cleaner to define
a metric calculatin formula based on some counters that the hardware
delivers.

> OLSR is designed as a pure layer 3 protocol. If we rely on
> layer-2 information we might as well remove the complete HELLO
> protocol.

i do not agree. most routing protocol implementations have a variety
of sources for determining the metric.

for example a link is removed (= metric infinity) based on

layer-1 information e.g. interface down)
layer-2 information e.g. loss of PPP LCP/802.1ag/802.1h keepalives
layer-3 information e.g. loss of hellos.

> Is it ok to conclude that we *need* a PacketPair link metric
> estimation (purely layer 3), and that we *would like* to use
> any (other) information we can read out the radio layer, if
> available?

that sounds a fair statement to me.

/hannes