Hello to all,
As some of you may remember, I made a few comments about the BATMAN routing protocol, as described in the draft of 7 April 2008 (the so-called ``mark 3'' version). These comments can be found on
http://mid.gmane.org/7itzdzzero.fsf@lanthane.pps.jussieu.fr
I have received a few replies, some of which were public but many of which were private. Unfortunately, no one of these replies appears to be an authoritative reply of the BATMAN developers, so there is no easy-to-quote document I can reply to.
Before I engage in a point-by-point reply, I'd like to mention that there appears to be a ``mark 4'' protocol and a ``BMX'' protocol in development, which apparently solve some of the issues I mentioned. This is good to hear, and I'd like to see a specification of these mythical protocols.
1. Exponential convergence **************************
My claim that there exist topologies in which average-case convergence of BATMAN is exponential in the number of hops has been confirmed by two of the BATMAN developers. I still believe this to be a very significant flaw of BATMAN.
Elektra claimed that this is the desired ``fish-eye'' behaviour. I disagree with that -- exponential convergence is exponential convergence, whatever name you give to it.
Axel Neumann spoke about TCP inefficiencies in the presence of packet loss. I do not understand how that relates to the issue at hand.
I'd like to remind everyone that all of OLSR, AODV and Babel exhibit linear-time convergence in all cases.
2. Lack of loop avoidance *************************
A few of my correspondents have pointed out that BATMAN does in fact have a loop avoidance mechanism. I therefore retract my claim that BATMAN causes persistent routing loops.
Unfortunately, none of the mails I received described the loop avoidance mechanism, and the few hints that were given do not appear to correspond to anything that's described in the draft. Hence, I am unable to evaluate BATMAN's loop avoidance mechanism, and in particular I cannot determine whether it causes starvation or leads to sub-optimal routing.
I am looking forward to a detailed description of BATMAN's loop avoidance mechanism.
3. Unrealistic metric *********************
This was confirmed by a few people, and is apparently worked around in the next version of the protocol. I am eagerly looking forward to a complete description of the ``mark 4'' version of the BATMAN protocol.
4. Lack of aggregation **********************
This is apparently fixed in the next version of the protocol. I am eagerly looking forward to a complete description of the ``mark 4'' version of the BATMAN protocol.
5. Jitter is not compulsory ***************************
This was confirmed. It is still unclear to me whether the BATMAN implementation does apply jitter.
Juliusz