Topology link quality

Dear all,

regarding the olsr-quality extension, in file tc_set.c in function 
olsr_tc_update_mprs() the following code snippet can be found:

      COPY_IP(&new_topo_dst->T_dest_addr, &mprs->address);
      new_topo_dst->T_time = GET_TIMESTAMP(msg->vtime*1000);
      new_topo_dst->T_seq = msg->ansn;

          if (olsr_cnf->lq_level > 0)
            {
              new_topo_dst->link_quality = mprs->neigh_link_quality;
              new_topo_dst->inverse_link_quality = mprs->link_quality;

              new_topo_dst->saved_link_quality = new_topo_dst->link_quality;
              new_topo_dst->saved_inverse_link_quality =
                new_topo_dst->inverse_link_quality;
            }

Can someone explain why the new_topo_dst->link quality is set equal to 
mprs->neigh_link_quality and vice versa?
IMHO, i think new_topo_dst->link_quality must be set equal to 
mprs->link_quality.  Am I missing something? Can someone clearify this 
for me?

Look for instance at this simple example:

node ip = 10.3.246.1

       *** olsr.org - 0.4.10 (Feb  2 2006) ***

Olsr quality extensions metric

Dear all,

In process_package.c the following can be found:

                      // path link quality = link quality between us
                      // and our one-hop neighbor x link quality between
                      // our one-hop neighbor and the two-hop neighbor

                      // let's compare this to ETX:

                      // 1 / LQ1 + 1 / LQ2 < 1 / LQ3 + 1 / LQ4 <=>
                      // LQ1 * LQ2 > LQ3 * LQ4

                      // so comparing path link quality values with ">" is
                      // equivalent to comparing ETX values with "<"

Can someone explain this? Why can this be stated? Is this true in all cases?

Regards,
Dries

Re: Olsr quality extensions metric

Ha! I got it. At least the 1-hop path versus 2-hop path thing. Suppose
that we have two hops, one between node A and node B, another between
node B and node C. Then node A re-sends its packets until it gets an
acknowledgement from B. That's why the ETX for the complete 2-hop path
is not 1 / (total link quality of the 2-hop path), I guess.

The rest is still beyond me, though. 

-Thomas

Re: Olsr quality extensions metric

Hi Dries.

> In process_package.c the following can be found:
> 
>                      // path link quality = link quality between us
>                      // and our one-hop neighbor x link quality between
>                      // our one-hop neighbor and the two-hop neighbor
> 
>                      // let's compare this to ETX:
> 
>                      // 1 / LQ1 + 1 / LQ2 < 1 / LQ3 + 1 / LQ4 <=>
>                      // LQ1 * LQ2 > LQ3 * LQ4
> 
>                      // so comparing path link quality values with ">" is
>                      // equivalent to comparing ETX values with "<"
> 
> Can someone explain this? Why can this be stated? Is this true in all
> cases?

Well, this is a relic from when we migrated from the initial metric
based on our links' packet loss to ETX. I was a little lazy and
therefore, internally, we still use packet loss at some places, based on
the above conjecture, and use ETX mostly for Dijkstra.

I never verified this mathematically, but my intuition was that a first
two-hop path with a better link quality than a second two-hop path has a
lower ETX than the second two-hop path.

I've just checked this numerically and my intuition seems to have been
wrong for about 2% of all cases. One such failure is, for example, LQ1 =

Re: Topology link quality

Hi Dries.

[code questions deleted, it should be possible to clarify this by means
of the debug output]

> node ip = 10.3.246.1
> 
>       *** olsr.org - 0.4.10 (Feb  2 2006) ***
> 
> --- 06:54:31.25 ---------------------------------------------------- LINKS
> 
> IP address       hyst      LQ     lost   total  NLQ    ETX
> 10.3.245.1       0.000  0.100  0      20     1.000  10.00
> --- 06:54:31.25 ------------------------------------------------ NEIGHBORS
> 
> IP address       LQ     NLQ    SYM   MPR   MPRS  will 10.3.245.1      
> 0.100  1.000  YES     NO    NO    3 
> --- 06:54:31.25 ------------------------------------------------- TOPOLOGY
> 
> Source IP addr   Dest IP addr     LQ     ILQ    ETX
> 10.3.245.1       10.3.246.1       0.098  1.000  10.20
> 
> 
> In the topology the link from 10.3.245.1 to 10.3.246.1 states LQ as
> 0.098, but IMHO it should be 1.000 and vice versa, not?

The LQ column in the "LINKS" section says how good the link from our
neighbour to us is. As there aren't any acknowledgements in OLSR, we can
only measure the packet loss among the packets that we receive. So, the
value 0.1 is for packets sent across the link 10.3.245.1 -> 10.3.246.1.

Re: Olsr quality extensions metric

I think , you intuitively stated that 1/LQ1 + 1 /LQ2 is equal to 1/(LQ1 
* LQ2). There's the catch. ETX is not equal to 1/(LQ1 * LQ2). Let's 
clear this out.

Say,
ETXa:  ETX for two hop path1
ETXa1: ETX of first link of two hop path1
ETXa2: ETX of second link of two hop path1

ETXb:  ETX for two hop path2
ETXb1: ETX of first link of two hop path1
ETXb2: ETX of second link of two hop path1
LQ1 = ]0,1]
LQ2 = ]0,1]
LQ3 = ]0,1]
LQ4 = ]0,1]

So,

ETXa > ETXb   <=>
ETXa1 + ETXa2 > ETXb1 + ETXb2 <=>
1/LQ1 + 1/LQ2 > 1/LQ3 + 1/LQ4 <=>
(LQ1 + LQ2)/ LQ1*LQ2 > (LQ3+ LQ4)/ LQ3*LQ4  <=>
LQ1*LQ2 < LQ3*LQ4 * ((LQ1 + LQ2)/(LQ3 + LQ4))

In case (LQ1 + LQ2)/(LQ3 + LQ4) = 1 e.g., it is equal to LQ1 * LQ2 < LQ3 
* LQ4.
In case (LQ1 + LQ2)/(LQ3 + LQ4) > 1 e.g,  then you have eg LQ1 * LQ2 < 
LQ3 * LQ4 => ETXa > ETXb

olsrd-0.4.10 RPM

I wanted to rebuild the olsrd-0.4.10-1.src.rpm (from
http://www.olsr.org/index.cgi?action=download) on FC4 on x86_64.
The attached patches were necessary to make olsrd find it's plug-ins.
[ One should actually go into the CVS BTW. ]

BTW the result can be found ATM on
http://bernd.petrovitsch.priv.at/olsrd-0.4.10-1.x86_64.rpm

	Bernd
--

-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

_______________________________________________
olsr-dev mailing list
olsr-dev <at> olsr.org
https://www.olsr.org/mailman/listinfo/olsr-dev

hna table only for other hnas?

Hello,

	It seems to me that the internal hna table only contains hna reported by 
other nodes. If the current node has itself one or more hna, they aren't 
stored in this table. 

	My questions then are :

	* do you agree with what i've said?
	* is that as you expect it to be ?
	* is that conformant with the rfc ?

Thank you for your help,
Thomas
--

-- 
Thomas Capricelli <orzel <at> freehackers.org>
http://orzel.freehackers.org/

Re: hna table only for other hnas?

The HNA table stores HNA entries received from remote hosts. Local HNA
entries are stored in the hna[4|6]_entries tables.
The routing capabilities announced in HNA messages are _external_
routes(to olsrd), therefore such local HNA entries are never added to the
routing table by olsrd since they are not olsrds responsibility to
maintain.(The route to the GW is ofcause olsrds responsibility - hence it
maintains the routes in the HNA set).

- Andreas

>
> Hello,
>
> 	It seems to me that the internal hna table only contains hna reported by
> other nodes. If the current node has itself one or more hna, they aren't
> stored in this table.
>
> 	My questions then are :
>
> 	* do you agree with what i've said?
> 	* is that as you expect it to be ?
> 	* is that conformant with the rfc ?
>
> Thank you for your help,
> Thomas
> --
> Thomas Capricelli <orzel <at> freehackers.org>
> http://orzel.freehackers.org/
>
> _______________________________________________

Olsr quality extensions metric

Hello

Please let me know if this metric(ETX) be finally available as plugin .

thank you