[Babel-users] A peer-reviewed assessment of OLSR, BATMAN and Babel

[Chun-Ping Wang]

Hi all, 

Many thanks for all your feedbacks.  It will definately help us to improve our work.
However, I think there is quite a bit of confusions at very beginning.  So I would 
like to make some clarifications for this paper.

As it has been mentioned earlier, this paper was to study all the protocols in
their default setting.  In term of "default setting" for OLSR, we used original 
config file shipped in olsr v0.5.5.  As far as I know, this config file is based on 
the LQ mode of OLSR  (i.e. olsrd.conf.default.lq ).  So, correct me if I am wrong, 
we have been using OLSR with ETX to begin with. We only modified the HELLO and
TC interval to improve static node performance. The results shown in our paper is 
actually the performance of OLSR with ETX.  

You may also aware the protocols that we used are already out-dated.  This is because 
this work was done back in 2008.  We are more than happy to undergo another study 
with more recent protocols.

Regards, 
Jerry









________________________________________
From: Henning Rogge [hrogge at googlemail.com]
Sent: Monday, November 09, 2009 8:07 PM
To: Mehran Abolhasan
Cc: Juliusz Chroboczek; babel-users at lists.alioth.debian.org; olsr-users at lists.olsr.org; b.a.t.m.a.n at lists.open-mesh.net; Brett Hagelstein; justin.lipman at gmail.com; Brett Hegelstein; Chun-Ping Wang
Subject: Re: [Babel-users] A peer-reviewed assessment of OLSR, BATMAN and       Babel

On Mon, Nov 9, 2009 at 05:46, Dr. Mehran Abolhasan <mehrana at uow.edu.au> wrote:
> Hi All,
>
> Many Thanks for all your comments. Just a couple of point of clarification.
>
> 1. The aim of this paper was to study all the protocols in their default
> settings. We did not
> switch off ETX with olsr (note we used the olsr version from olsr.org). In
> fact the link quality metric was left to 2 by default. We are well aware
> that ETX provide more stable routes than hop count.
The problem is that the "RFC" mode of olsr.org is not well tested, the
MPR algorithm is broken in 0.5.6 and RFC conform OLSR networks do not
work in practice for non-trivial networks. I'm surprised that you got
results this good.

> 2. In terms of looking at performance using different parameters, we will be
> doing this in our future studies.
> Also, note that the conference papers were limited to 4 pages only.
If you plan to start your tests, feel free to contact the olsr mailing
lists for some suggestions for parameters. ;)

> 3. In terms of overheads, given that this was a small scale indoor test-bed,
> we believed the amount of overhead introduced into the network is not
> signficant enough to adversely affect the network. So we did not look into
> overheads for this paper, however we would do this for larger test-beds.
>
> 4. We previously ran OLSR using various different outdoor and indoor
> test-beds and at the time we were doing the experimentations BATMAN and
> BABEL were more stable.
Noone surprised (without ETX).

Henning Rogge

--
"Wo kämen wir hin, wenn alle sagten, wo kämem wir hin, und niemand
ginge, um einmal zu schauen, wohin man käme, wenn man ginge." (Kurt
Marti)