[OLSR-users] LQ Routing and 802.11b Link Speed

[Bruno Randolf]

hi holger!

this sounds like a good improvement to the current LQ algorithm! but i think 
it's not so easy to implement on top of the current mechanisms we have. to 
get the expected transmission times we would have to send unicast packets to 
each neighbor (the current HELLO packets are broadcast with the lowest basic 
rate) which can result in a lot of additionally used bandwidth. we (well, 
actually thomas ;)) tried something similar before in an attempt to measure 
the round-trip time (RTT) - if i recall correctly the big problem was that 
the RTT varied considerably depending on the speed and utilization of the 
CPU.

another option may be to read the current rate (physical link speed) from the 
wlan driver and multiply the ETX with that value. but this approach is also 
flawed because the driver will send packets to each destination node with a 
different rate, some drivers may even retry packets with multiple rates (say 
1. attempt: 54Mbps, 2. attempt: 36Mbps 3. attpemt: 24Mbps 4. attempt: 6Mbps). 
drivers could expose this information to userspace programs in some way, but 
then we are bound to specific drivers and specific operating systems.

could you send a link to the ETT paper?

bruno



On Wednesday 15 June 2005 10:09, Holger Mauermann wrote:
> Holger Mauermann wrote:
> > What about measuring not only the packet loss, but also the round
> > trip time to the neighbors?
>
> Forget my last post. The RTT depends on the link load and leads to very
> frequent route changes...
>
> However, recently I read something about Packet-Pair based bandwidth
> estimation and Expected Transmission Time (ETT) and it looks very
> interesting. Consider the following real life example with 3 links:
>
> A-B: 24 Mbps, ETX 1.0
> A-C:  1 Mbps, ETX 1.5
> B-C: 11 Mbps, ETX 1.0
>
> To reach C from A olsr currenty prefers the short, bad 1 Mbps link. With
> ETT it could use the two fast links A-B and B-C because the total ETT is
> only 2.5 ms instead of 15 ms:
>
> ETT = ETX * S / B       S = Packet size, B = Bandwidth
>
> A-B: ETT 0.8 ms (S = 1 KByte, B = 1200 kByte/s)
> A-C: ETT  15 ms (S = 1 KByte, B =  100 kByte/s)
> B-C: ETT 1.7 ms (S = 1 KByte, B =  600 kByte/s)
>
> Any ideas if this could be implemented in olsr?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20050615/df60fede/attachment.sig>