3 Aug
2009
3 Aug
'09
10:21 a.m.
On Thursday 30 July 2009 22:32:04 Yang Su wrote:
1. Similar to what Marek proposed. But push it to the
extreme: switch to a
neighbor only when it has the best tq AND it has the newest seqno. This
fix along seems to already solve the looping problem in the test cases. It
reduces the rerouting time from more than 1 minutes to less than 15
seconds. Marek: I also tried the patch you sent. It didn't help in this
setup.
Changing the route based on the (fastest) sequence number has some drawbacks
which we experienced before (BATMAN III). It tends to discriminate longer but
better routes and favors short paths. In some asymetric link (worst case)
scenarios it would route against all odds, simply because receiving a fast
packet (newest seqno) does not mean we can send the same way back. If possible
I'd like to avoid this strict seqno check.
I attached another patch which will conduct a route switch only if the TQ of
the sending neighbor is better than our current best route (no negative
switching anymore). I tested the patch here and it works so far but my
environment is less controlled than yours. Could you perform the same test on
your setup ?
If you intend to experiment with other ideas watch out for the sequence number
as it will overflow. A simple "greater than" check might lead to strange
results. Also, updates_routes() checks for changed HNA messages even if the
next hop does not change.
2. Relaxed echo cancellation. This is based on the
following observation:
the TQ value that a node puts into OGM is completely decoupled with "from
which neighbor this OGM is received". As a result, the TQ value contained
in the echoed OGM represent the real TQ value at the neighbor which echoed
this OGM. The current echo cancellation implementation just drops all the
echoed OGM. This may prevent the node from updating the information towards
the neighbor that echos the OGM. In the extreme case, the information
towards that neighbor may becomes completely stale (similar to what happens
in case 2). The change I made: Always check the TQ contained in the
echoed OGMs. When it is worse than the avg TQ towards that neighbor, we use
this TQ reading to update the avg TQ towards that neighbor. This change
didn't show any effect during the chain tests. However, I still include
this change in the patch to bring up the discussion.
Right, every node will emit his currently best TQ value but I did not
understand how we can use that. If we send him a better TQ he will send back
that number. If we send a bad TQ he will send his good number. Furthermore,
each hop will apply some asymetric / hop / wifi penalty that we pull into our
routing database ?
Regards,
Marek