[B.A.T.M.A.N.] BATMAN routing

Daniele Furlan daniele.furlan at gmail.com
Mon Dec 6 11:40:10 CET 2010


Hi all,

I'm doing a research project on the topic discussed.
I think the solutions proposed can improve the performance of the
protocol, especially its reactivity in case of link failures.
But in my opinion the main cause of performance deficiency is the
route flap problem documented in some research paper. This is a common
problem, especially in dense network. My work focus on finding out
some strategy to reduce this problem maintaining at the same time a
good reactivity in route decision. The first strategy I will try, is
to introduce an hysteresis in route change and then I will study more
sophisticated technique.

As soon as I have some written material I will send it to the mailing
list hoping to receive some suggestion or critiques.

PS. I'm also working on a theoretical analysis on routing overhead in
term of network utilization. Soon I will post some results.

Bye.

2010/12/2 Antonio Quartulli <ordex at ritirata.org>
>
> Hi all*,
>
> On gio, dic 02, 2010 at 11:27:52 +0100, Linus Lüssing wrote:
> > Hi everyone,
> >
> > thanks for having joined the IRC channel, Hlabishi and Chris, that's
> > really speeding the discussions up a lot, I guess :). Just wanted
> > to throw in another idea open for discussions which is refering to
> > Hlabisihi's packet count weighting.
> >
> > What do you guys think about pushing this concept even one step
> > further and removing the local packet count window? And instead
> > using a "smoother" exponential weighted average which got very
> > popular in TCP for it's RTT estimations:
> >
> > RQ_new = f(newseqno, lastseqno, RQ_old, α)
> >        = (1-α) * RQ_old + α * 1 / Δ(newseqno, lastseqno)
> >
> > As in TCP, α is then the parameter for tweaking on how much
> > more priority a newer packet shall have and is chosen between 0
> > (conservative) and 1 (opportunistic).
> >
> > What do you think?
> >
>
> IMHO this is not the best solution. Probably it could better than the
> actual strategy, but, as TCP demonstrates, this is not a really nice way
> of evaluating the RQ.
>
> Imho, since we have more and more information than
> TCP for evaluating the new RQ, we could try to make a better choice
> considering "more values": instead of using only the deltaSEQ and the
> oldRQ, we could try to apply a function that can weight also the previous
> history of the link (of course with a limit).
> Something like
>
> newRQ = f(window[0], ...., window[N-1]) in which, each OGM (received or
> not) can be weighted in a different way depending on its position.
>
> I hope I've been clear.
>
> furland is probably working on this aspect.
>
> Bye!
>
> >
> > Cheers, Linus
> >
> > On Wed, Dec 01, 2010 at 01:30:18PM +0100, Marek Lindner wrote:
> > > On Wednesday 01 December 2010 10:46:10 hlabishi kobo wrote:
> > > > Thank you for considering this concept, i am working on the
> > > > implementation now. I would love to attend your IRC channel
> > > > discussions, just tell date and time.
> > >
> > > The IRC meetings are less formal. Just join us when you have the time. People
> > > hang out there all the time.
> > >
> > > Cheers,
> > > Marek
> > >
>
> --
> Antonio Quartulli
>
> Ognuno di noi, da solo, non vale nulla
> Ernesto "Che" Guevara



--
Daniele Furlan (furland)


More information about the B.A.T.M.A.N mailing list