Tue Nov 13 17:02:50 CET 2012
It would be a nice goal being able to have less network-wide dependencies on configuration. Having TLVs or msg types let us break compatibility on a user-friendly way. Not extremely useful, but better than manual control over all nodes on using same lq plugin and no tool for migration.
My preference is a generic feedback from receiver to sender, with hello. The nlq feedback could be derived from lq_etx, lq_rssi, lq_else. Sender defines link cost from lq and nlq and send it with TC.
We could come up with new hello message type to do this. Even with new tc message type, with just the link costs, instead of 1/(nq*nlq). To be verified, it was some couple of years ago when I checked this.
If we change, we could use olsrv2 encoding. Better: do it right in olsrv2 and forget clean-up in olsrd. How to implement ETX/RSSI/else link metrics is under discussion, my preference is noted.
Op 13 nov. 2012, om 14:01 heeft Ferry Huberts het volgende geschreven:
> On 13/11/12 13:44, Henning Rogge wrote:
>> On 11/13/2012 01:42 PM, Ferry Huberts wrote:
>>> On 13/11/12 13:40, Henning Rogge wrote:
>>>> On 11/13/2012 01:37 PM, Ferry Huberts wrote:
>>>>> The function 'default_lq_serialize_hello_lq_pair_ffeth'
>>>>> puts the lq and nlq values on bytes 2 and 3 while all the other plugins
>>>>> put those values in bytes 0 and 1.
>>>>> Is there some special reason for this that I'm not aware of?
>>>> Could be a way to make sure you don't mix up the different routing
>>>> metrics, similar to the trick we did for the etxff_eth metric (it also
>>>> used byte 2/3 I think).
>>> that makes no sense, we have several different lq plugins, each with
>>> different semantics in these bytes...
>> We have a couple of standard metrics (etx_float, etxff, etxfpm) which
>> use the bytes 0/1 and are all compatible with each other.
>> And we have one/two experimental metrics (which accidently both use byte
> also, the readme says
> 'The message format of etx_ff is compatible with etx_fpm and etx_float.'
> It seems to me that we need to include (missing now!) a value in the packet to indicate which plugin is used to handle the LQ values...
> Ferry Huberts
> Olsr-dev mailing list
More information about the Olsr-dev