On Wednesday 12 August 2009 22:34:17 Yang Su wrote:
Given the DV nature of Batman, current strict dropping policy seems to make sense, because sending known OGMs (as suggested) does introduce significant overhead but does not propagate so much new information.
In addition, loosing the dropping policy may introduce new problems which might not be easily predictable at this moment, e.g., stability, looping (propagating stale information within the network might cause even more nasty looping problems).
I agree that this might introduce new problems which is the reason for posting it here. I definitely see the overhead created by that methog. Every better idea will be accepted immediately. :-)
Another way (and maybe simpler ) to fix the problem: instead of loosing the OGM dropping policy, loosing the echo cancellation policy.
It is a very simple fix: in addition to the usual echo cancellation process, I also check the TQ value contained in the echoed OGM. This TQ is announced by the neighbor that broadcasts this echo. If this TQ is worse than my current TQ estimation towards that neighbor, I update the estimation with this TQ.
In your testbed it fixed the issue ? Looking at the example you gave I would expect that the problem is only solved partially. You argued the OGMs from E via A would always arrive faster at B compared to the longer path. Using your method would probably avoid the loop between A and B in the event of a packet loss on the longer path but it would not let route A via the longer path. Am I mistaken ?
Regards, Marek