[B.A.T.M.A.N.] Masters thesis

[B.A.T.M.A.N.] Masters thesis

[Vojislav Marinkovic]

Hi!

My name is Vojislav Marinkovic and I am a student of Electrical Engineering at the Royal Institute of Technology in Stockholm. My major is Communication Networks and right now I am looking for an interesting subject for my masters thesis. While browsing the Internet for some interesting topics, I ran into your project which is very similar to (yet better than) one of my own ideas. So I thought "why should I put time on inventing wet water instead of joining the project?",

On your homepage you stated that you have a lot of ideas but you don't have the time to implement them all. My question is, do you have any ideas that would fit to be done as a masters thesis in communication networks? It could be anything from an issue related to the protocol itself or it could be porting an already deployed technology on other types of networks to the B.A.T.M.A.N. (I'm not suggesting anything, but as an example let's say potential issues with live streaming over a B.A.T.M.A.N.-network), comparing B.A.T.M.A.N. some other routing protocol/s or any other topic related to my major subject. I really don't have any idea on what problems you have encountered so please help me find a good topic for my masters thesis.

The thesis will be done during this summer.

Thank you in advance
Vojislav Marinkovic

Re: [B.A.T.M.A.N.] Masters thesis

[elektra]

Hello Vojislav!

I have a personal wish list of things that would be great to have in 
Batman. I don't know if any of these would be suitable/interesting for 
you, but I will use the opportunity to post it to the list now:

*  Modify Batman-0.3.X  in order to support IPv6
*  Improve Batman with regards to protocol overhead and convergence speed
*  Get support for other operating systems working (so far it only works 
with Linux)
*  Implement a minimalistic and power saving Batman client version for 
embedded mobile devices
*  Modify Batman-0.3.X code so we have an option to compile it without 
policy routing support
*  Modify the way that Batman-Advanced (Layer 2) deals with 
broadcast/multicast payload packages (on multihop wireless routes there 
is always packet loss, protocols like DHCP use broadcast or multicast 
messages which are not send redundantly and not acknowledged, so these 
protocols which are not designed to deal with a high level of packetloss 
have difficulties to work on a Layer 2 mesh as the number of hops and 
packet loss on the media increases)

Cheers,
elektra






> Hi!
>
> My name is Vojislav Marinkovic and I am a student of Electrical Engineering at the Royal Institute of Technology in Stockholm. My major is Communication Networks and right now I am looking for an interesting subject for my masters thesis. While browsing the Internet for some interesting topics, I ran into your project which is very similar to (yet better than) one of my own ideas. So I thought "why should I put time on inventing wet water instead of joining the project?",
>
> On your homepage you stated that you have a lot of ideas but you don't have the time to implement them all. My question is, do you have any ideas that would fit to be done as a masters thesis in communication networks? It could be anything from an issue related to the protocol itself or it could be porting an already deployed technology on other types of networks to the B.A.T.M.A.N. (I'm not suggesting anything, but as an example let's say potential issues with live streaming over a B.A.T.M.A.N.-network), comparing B.A.T.M.A.N. some other routing protocol/s or any other topic related to my major subject. I really don't have any idea on what problems you have encountered so please help me find a good topic for my masters thesis.
>
> The thesis will be done during this summer.
>
> Thank you in advance
> Vojislav Marinkovic
> _______________________________________________
> B.A.T.M.A.N mailing list
> B.A.T.M.A.N@open-mesh.net
> https://lists.open-mesh.net/mm/listinfo/b.a.t.m.a.n
>
>   

Re: [B.A.T.M.A.N.] Masters thesis

[Vojislav Marinkovic]

Thank you for your suggestions! 

There are a couple of things in your wish list that could be interesting for me. I'll take a closer look before I make a decision. One thing that I can tell you right away is that support for IPv6 came to my mind, but since I'm really (and I mean REALLY) new to B.A.T.M.A.N. and I don't know what is going on in the community, I thought it might be a good idea to ask.

Once again thank you! 
________________________________________
Från: b.a.t.m.a.n-bounces@open-mesh.net [b.a.t.m.a.n-bounces@open-mesh.net] för elektra [onelektra@gmx.net]
Skickat: den 27 april 2009 18:44
Till: The list for a Better Approach To Mobile Ad-hoc Networking
Ämne: Re: [B.A.T.M.A.N.] Masters thesis

Hello Vojislav!

I have a personal wish list of things that would be great to have in
Batman. I don't know if any of these would be suitable/interesting for
you, but I will use the opportunity to post it to the list now:

*  Modify Batman-0.3.X  in order to support IPv6
*  Improve Batman with regards to protocol overhead and convergence speed
*  Get support for other operating systems working (so far it only works
with Linux)
*  Implement a minimalistic and power saving Batman client version for
embedded mobile devices
*  Modify Batman-0.3.X code so we have an option to compile it without
policy routing support
*  Modify the way that Batman-Advanced (Layer 2) deals with
broadcast/multicast payload packages (on multihop wireless routes there
is always packet loss, protocols like DHCP use broadcast or multicast
messages which are not send redundantly and not acknowledged, so these
protocols which are not designed to deal with a high level of packetloss
have difficulties to work on a Layer 2 mesh as the number of hops and
packet loss on the media increases)

Cheers,
elektra






> Hi!
>
> My name is Vojislav Marinkovic and I am a student of Electrical Engineering at the Royal Institute of Technology in Stockholm. My major is Communication Networks and right now I am looking for an interesting subject for my masters thesis. While browsing the Internet for some interesting topics, I ran into your project which is very similar to (yet better than) one of my own ideas. So I thought "why should I put time on inventing wet water instead of joining the project?",
>
> On your homepage you stated that you have a lot of ideas but you don't have the time to implement them all. My question is, do you have any ideas that would fit to be done as a masters thesis in communication networks? It could be anything from an issue related to the protocol itself or it could be porting an already deployed technology on other types of networks to the B.A.T.M.A.N. (I'm not suggesting anything, but as an example let's say potential issues with live streaming over a B.A.T.M.A.N.-network), comparing B.A.T.M.A.N. some other routing protocol/s or any other topic related to my major subject. I really don't have any idea on what problems you have encountered so please help me find a good topic for my masters thesis.
>
> The thesis will be done during this summer.
>
> Thank you in advance
> Vojislav Marinkovic
> _______________________________________________
> B.A.T.M.A.N mailing list
> B.A.T.M.A.N@open-mesh.net
> https://lists.open-mesh.net/mm/listinfo/b.a.t.m.a.n
>
>

_______________________________________________
B.A.T.M.A.N mailing list
B.A.T.M.A.N@open-mesh.net
https://lists.open-mesh.net/mm/listinfo/b.a.t.m.a.n

Re: [B.A.T.M.A.N.] Masters thesis

[Marek Lindner]

Hi,

> On your homepage you stated that you have a lot of ideas but you don't have
> the time to implement them all. My question is, do you have any ideas that
> would fit to be done as a masters thesis in communication networks? It
> could be anything from an issue related to the protocol itself or it could
> be porting an already deployed technology on other types of networks to the
> B.A.T.M.A.N.

welcome on board.  :-)

I'm very happy that you ask. Elektra already suggested a few things. I'm going 
to extend this list and group it a bit to outline the focus of the 
corresponding tasks. That should give you a good starting point. 
I suggest you choose your candidates out of these before we dive into the 
details. Then you will have an idea what to expect and you can make a decision 
whether you want to do it. :-)

one afternoon of work (at maximum):
*  Modify Batman-0.3.X code so we have an option to compile it without 
policy routing support
*  Modify the way that Batman-Advanced (Layer 2) deals with 
broadcast/multicast payload packages (on multihop wireless routes there 
is always packet loss, protocols like DHCP use broadcast or multicast 
messages which are not send redundantly and not acknowledged, so these 
protocols which are not designed to deal with a high level of packetloss 
have difficulties to work on a Layer 2 mesh as the number of hops and 
packet loss on the media increases)

several weeks of coding effort (including tests):
*  Modify Batman-0.3.X  in order to support IPv6
*  Get support for other operating systems working (so far it only works 
with Linux) -> depends on your knowledge of "other" systems
* merge batman adv userspace & kernelland code to reduce the maintenance 
overhead
* automatic interface bonding for better throughput (layer 2)

requires in depth knowlegde about batman:
*  Improve Batman with regards to protocol overhead and convergence speed

mt. everest:
*  Implement a minimalistic and power saving Batman client version for 
embedded mobile devices (requires extensive knowledge of 802.11 power saving 
mechanisms and how to bring them into the mesh)
* multipath routing (as it always appears over and over again: 
http://en.wikipedia.org/wiki/Multipath_routing)

Regards,
Marek

Re: [B.A.T.M.A.N.] Masters thesis

[Maik Wodarz]

[-- Attachment #1: Type: text/plain, Size: 3518 bytes --]

Hi Vojislav and Electra,

Was the protocol implemented yet on a simulation platform like omnet?
For comparing purposes (for example with OLSR) it could be interesting
to simulate the protocol.

Further the package load will be tunnelled through batman network by an
udp tunnel. There was reasons to do this. But why we can not establish
an tcp-tunel on top of the existing tunnels. So earn more overhead but
the delivery of the related packages are granted.

In respect to IPv6: What is the problem with IPv6? The batman protocol
self should work with ipv6? As payload it could be realized by an tunnel
too.

regards

Maik


elektra schrieb:
> Hello Vojislav!
> 
> I have a personal wish list of things that would be great to have in
> Batman. I don't know if any of these would be suitable/interesting for
> you, but I will use the opportunity to post it to the list now:
> 
> *  Modify Batman-0.3.X  in order to support IPv6
> *  Improve Batman with regards to protocol overhead and convergence speed
> *  Get support for other operating systems working (so far it only works
> with Linux)
> *  Implement a minimalistic and power saving Batman client version for
> embedded mobile devices
> *  Modify Batman-0.3.X code so we have an option to compile it without
> policy routing support
> *  Modify the way that Batman-Advanced (Layer 2) deals with
> broadcast/multicast payload packages (on multihop wireless routes there
> is always packet loss, protocols like DHCP use broadcast or multicast
> messages which are not send redundantly and not acknowledged, so these
> protocols which are not designed to deal with a high level of packetloss
> have difficulties to work on a Layer 2 mesh as the number of hops and
> packet loss on the media increases)
> 
> Cheers,
> elektra
> 
> 
> 
> 
> 
> 
>> Hi!
>>
>> My name is Vojislav Marinkovic and I am a student of Electrical
>> Engineering at the Royal Institute of Technology in Stockholm. My
>> major is Communication Networks and right now I am looking for an
>> interesting subject for my masters thesis. While browsing the Internet
>> for some interesting topics, I ran into your project which is very
>> similar to (yet better than) one of my own ideas. So I thought "why
>> should I put time on inventing wet water instead of joining the
>> project?",
>>
>> On your homepage you stated that you have a lot of ideas but you don't
>> have the time to implement them all. My question is, do you have any
>> ideas that would fit to be done as a masters thesis in communication
>> networks? It could be anything from an issue related to the protocol
>> itself or it could be porting an already deployed technology on other
>> types of networks to the B.A.T.M.A.N. (I'm not suggesting anything,
>> but as an example let's say potential issues with live streaming over
>> a B.A.T.M.A.N.-network), comparing B.A.T.M.A.N. some other routing
>> protocol/s or any other topic related to my major subject. I really
>> don't have any idea on what problems you have encountered so please
>> help me find a good topic for my masters thesis.
>>
>> The thesis will be done during this summer.
>>
>> Thank you in advance
>> Vojislav Marinkovic
>> _______________________________________________
>> B.A.T.M.A.N mailing list
>> B.A.T.M.A.N@open-mesh.net
>> https://lists.open-mesh.net/mm/listinfo/b.a.t.m.a.n
>>
>>   
> 
> _______________________________________________
> B.A.T.M.A.N mailing list
> B.A.T.M.A.N@open-mesh.net
> https://lists.open-mesh.net/mm/listinfo/b.a.t.m.a.n
> 

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 5425 bytes --]

Re: [B.A.T.M.A.N.] Masters thesis

[Marek Lindner]

Hi,

> Was the protocol implemented yet on a simulation platform like omnet?
> For comparing purposes (for example with OLSR) it could be interesting
> to simulate the protocol.

there is no simulator support that I know of.


> Further the package load will be tunnelled through batman network by an
> udp tunnel. There was reasons to do this. But why we can not establish
> an tcp-tunel on top of the existing tunnels. So earn more overhead but
> the delivery of the related packages are granted.

It is not necessary to implement the tunnel with TCP as all protocols that use 
the tunnel already have a mechanism to detect packet lost. If you issue a HTTP 
query over a tunnel it will look like this:
HTTP -> TCP -> UDP Tunnel -> Internet

Your setup would look like this:
HTTP -> TCP -> TCP Tunnel -> Internet

Next to the overhead which comes with TCP you will face a double congestion 
window (see TCP congestion avoidance). In a lossy environment TCP over TCP 
connection will run at the lowest speed possible without a chance to recover. 


> In respect to IPv6: What is the problem with IPv6? The batman protocol
> self should work with ipv6? As payload it could be realized by an tunnel
> too.

Its not a problem - just somebody needs to do it.  :-)

Regards,
Marek

Re: [B.A.T.M.A.N.] Masters thesis

[elektra]

Hello Maik!


> Was the protocol implemented yet on a simulation platform like omnet?
> For comparing purposes (for example with OLSR) it could be interesting
> to simulate the protocol.
>   


There is no implementation of Batman for NS2 or Omnet, as far as I'm 
aware of. However there is a paper about the simulation of Batman-0.1 
(Mark I of the Batman algorithm without bidirectional link check) and 
Batman-0.2 (Mark II of the Batman algorithm with bidirectional link 
check): http://www.olsr.org/~aaron/olsr/batman_report.pdf

Note: The paper is nice, the results were encouraging but the study is 
dated. The lack of a bidirectional link check was a known limitation of 
Mark I when we just wanted to do a quick and dirty test to prove the 
feasibility of the Batman idea. So the first version we expected to work 
well in the real world was Mark II. Mark II was replaced quickly by Mark 
III because as Axel Neumann has pointed out there was a bug in the 
algorithm in both Mark I and Mark II which can cause routing loops.

Addressing this problem in Mark III also had the benefit to reduce 
protocol overhead. Mark III works nice, but we found that the link 
metric we used still had a flaw. All Batman algorithms can route 
asymmetric, which is great. However Mark I-III tend to prefer routing 
paths from which they *receive* protocol messages well as paths in the 
opposite direction to *transmit* payload. This can be unfortunate, 
because there could be an alternate routing path which works better in 
transmit direction than the path which works better in receive 
direction. In Mark II and III we tried to address this via the 
bidirectional link check, to achieve a symmetric ETX like routing 
behavior. This mitigated the problem but didn't solve it completely. 
Also it was not what we really were aiming for: Routing asymmetric in 
the transmit direction if this is the best routing path to go. Hence 
Mark IV was introduced.

We have tested and compared Olsrd 0.5.0 and Batman-Experimental (Mark IV 
) in the "Massive Mesh" wireless indoor grid at the Meraka institute of 
the CSIR in Tshwane (aka Pretoria) in South Africa. At the time we ran 
the tests Batman-0.3 was pretty much in its alpha state so we were 
concentrating on the Batman-Experimental branch because the 
implementation was more mature. (Batman-0.3.X and Batman-Experimental 
represent two different ideas for Mark IV of the Batman algorithm.)

http://researchspace.csir.co.za/dspace/bitstream/10204/3035/1/Johnson3_2008.pdf


Note that time has passed over this study as well. Olsr fans will point 
out that they have improved the code much since the study and fixed at 
least one crucial bug (ETX was not only calculated based on Hello packet 
loss in Olsrd, as I had suggested it to Thomas Lopatic when we were both 
designing the ETX/LQ implementation in Olsr in 2004. Thomas had decided 
to use all protocol messages to calculate TQ/NLQ in the implementation 
of olsr-0.4.8, so the LQ/NLQ values would change quicker than I expected 
- depending on the number of TC messages floating around in the network)

However some general conclusions still remain the same if you compare 
both protocol ideas:

* Batman-IV floods protocol messages selectively i.e. only on paths 
following the best route for each destination. Olsr has to flood all 
topology messages everywhere - the only optimization being the idea of 
multipoint relays. (MPR redundancy was set to 7 MPRs per node, since I 
tried my best to avoid routing loops).  However - enabling multi-point 
relays or not - Olsr tries to sync every topology update with all nodes. 
Since the grid has thousands of alternate propagation paths to 
redundantly flood messages the protocol overhead is drastic, because 
there is not much protocol message loss.

* Olsr needs more protocol information (topology data) to operate than 
Batman.

* We did the best to stop Olsr from looping payload packets - i.e. send 
topology updates redundant - however this comes at a price. In order to 
avoid loops the topology information has to be synced with all OLSR 
nodes. Despite the high level of redundancy less than 70% of the routes 
used were symmetric. This is a clear indication that the topology data 
bases were not in sync, because ETX would route symmetric at all times 
if the topology data is in sync. Despite the great deal of of effort to 
sync topology information Olsr still had transient routing loops under 
heavy payload. It would be interesting to see how a current Olsr behaves 
today, since the fix of the fore mentioned issue.

* Batman-IV didn't loop, no matter how hard we saturated the network 
with payload traffic. This is not a surprise because it was the main 
goal of the algorithm design. Transient routing loops were the main 
motivation for Thomas and me to drop development of Olsr.


> In respect to IPv6: What is the problem with IPv6? 


No problem regarding the protocol - we are just missing IPv6 support so 
far in the OSI-Layer 3 implementations of Batman (both Experimental and 
0.3.X). Batman-Advanced doesn't have this problem, as a Layer 2 protocol 
it can carry any protocol you like.


> The batman protocol
> self should work with ipv6? 

Absolutely.

> As payload it could be realized by an tunnel
> too.

Yes. As a side-note: Batman uses tunnels for Internet connectivity to 
address the problem of gateway switching when NAT is used on the 
gateway. With IPv6 NAT on gateways should become superfluous one sunny 
day :-)


Cheers,
elektra

Re: [B.A.T.M.A.N.] Masters thesis

[Vojislav Marinkovic]

Hello!

I have about 20 weeks to do the master thesis. This time includes: getting familiar with the protocol, gathering other information needed for the task, analysis, report writing, coding, presentation preparation and probably some more stuff that I can't remember right now.

Based on this list i would say that the tasks which could fit me are IPv6 support (the other tasks in this group seem to be more development towards the OS) and "Improve Batman with regards to protocol overhead and convergence speed" (with a risk that it would only result in a report). Maybe IPv6 would be more interesting to you guys since you would get something in return for helping me out.

Another idea that came to my mind is building a B.A.T.M.A.N. module for ns2, and I have seen it being discussed here the last couple of days.

The easiest task for me would be IPv6 support. It would also give me the opportunity to get some in-depth knowledge about IPv6 and some hands-on experience with it. But I would need to check if my professor would accept this topic. Otherwise, I'm not a fastidious (I just learned a new word in English :) ) person, so it wouldn't be a problem for me to do any of the tasks mentioned above.

The next step is choosing one task and then making a thesis proposal, including a rough time-plan.

Any comments or suggestions?

Vojislav Marinkovic

________________________________________

one afternoon of work (at maximum):
*  Modify Batman-0.3.X code so we have an option to compile it without
policy routing support
*  Modify the way that Batman-Advanced (Layer 2) deals with
broadcast/multicast payload packages (on multihop wireless routes there
is always packet loss, protocols like DHCP use broadcast or multicast
messages which are not send redundantly and not acknowledged, so these
protocols which are not designed to deal with a high level of packetloss
have difficulties to work on a Layer 2 mesh as the number of hops and
packet loss on the media increases)

several weeks of coding effort (including tests):
*  Modify Batman-0.3.X  in order to support IPv6
*  Get support for other operating systems working (so far it only works
with Linux) -> depends on your knowledge of "other" systems
* merge batman adv userspace & kernelland code to reduce the maintenance
overhead
* automatic interface bonding for better throughput (layer 2)

requires in depth knowlegde about batman:
*  Improve Batman with regards to protocol overhead and convergence speed

mt. everest:
*  Implement a minimalistic and power saving Batman client version for
embedded mobile devices (requires extensive knowledge of 802.11 power saving
mechanisms and how to bring them into the mesh)
* multipath routing (as it always appears over and over again:
http://en.wikipedia.org/wiki/Multipath_routing)
_______________________________________________

Re: [B.A.T.M.A.N.] Masters thesis

[elektra]

Hello Vojislav!


My personal and very biased opinion is that simulations suck - 
simulating a wireless mesh in all its complexity (the complexity of RF 
propagation and interference is the first issue that comes to my mind) 
needs a very, very sophisticated software and a really powerful 
computer. Not to mention simulating real CPU load in mesh nodes and real 
problems with wireless interfaces, unexpected problems of the MAC layer 
and so on.

I'd dare to say that the computational effort of simulating what is 
going on in a mesh for 10 seconds is higher than taking 50 real machines 
with real wireless interfaces, running them for days and getting real 
results. Simulation seems to be important for the scientific world, 
though. Having a implementation for the popular simulation programs 
could increase the interest in Batman from the scientific world, but 
honestly I don't care much. At a unit price of 25€ per mesh-capable 
wireless router running Open-WRT (D-Link DIR-300 for example) I don't 
think it is necessary to do simulations anymore. However such a 
el-cheapo grid would be only capable to test algorithms running on one 
wireless interface and up to 5 wired interfaces. There are real testbeds 
on this planet (like the "Meraka Massive Mesh") which are idling most of 
the time, I guess.

It would be awesome to have IPv6 support in Batman, to be up to the 
changes and challenges that are knocking at the door. Also protocol 
improvements regarding protocol overhead and convergence speed (both 
topics are linked to each other, of course) is something we should work 
on - and hammering your head on algorithms is fun.

Cheers,
elektra





> Hello!
>
> I have about 20 weeks to do the master thesis. This time includes: getting familiar with the protocol, gathering other information needed for the task, analysis, report writing, coding, presentation preparation and probably some more stuff that I can't remember right now.
>
> Based on this list i would say that the tasks which could fit me are IPv6 support (the other tasks in this group seem to be more development towards the OS) and "Improve Batman with regards to protocol overhead and convergence speed" (with a risk that it would only result in a report). Maybe IPv6 would be more interesting to you guys since you would get something in return for helping me out.
>
> Another idea that came to my mind is building a B.A.T.M.A.N. module for ns2, and I have seen it being discussed here the last couple of days.
>
> The easiest task for me would be IPv6 support. It would also give me the opportunity to get some in-depth knowledge about IPv6 and some hands-on experience with it. But I would need to check if my professor would accept this topic. Otherwise, I'm not a fastidious (I just learned a new word in English :) ) person, so it wouldn't be a problem for me to do any of the tasks mentioned above.
>
> The next step is choosing one task and then making a thesis proposal, including a rough time-plan.
>
> Any comments or suggestions?
>
> Vojislav Marinkovic
>
> ________________________________________
>
> one afternoon of work (at maximum):
> *  Modify Batman-0.3.X code so we have an option to compile it without
> policy routing support
> *  Modify the way that Batman-Advanced (Layer 2) deals with
> broadcast/multicast payload packages (on multihop wireless routes there
> is always packet loss, protocols like DHCP use broadcast or multicast
> messages which are not send redundantly and not acknowledged, so these
> protocols which are not designed to deal with a high level of packetloss
> have difficulties to work on a Layer 2 mesh as the number of hops and
> packet loss on the media increases)
>
> several weeks of coding effort (including tests):
> *  Modify Batman-0.3.X  in order to support IPv6
> *  Get support for other operating systems working (so far it only works
> with Linux) -> depends on your knowledge of "other" systems
> * merge batman adv userspace & kernelland code to reduce the maintenance
> overhead
> * automatic interface bonding for better throughput (layer 2)
>
> requires in depth knowlegde about batman:
> *  Improve Batman with regards to protocol overhead and convergence speed
>
> mt. everest:
> *  Implement a minimalistic and power saving Batman client version for
> embedded mobile devices (requires extensive knowledge of 802.11 power saving
> mechanisms and how to bring them into the mesh)
> * multipath routing (as it always appears over and over again:
> http://en.wikipedia.org/wiki/Multipath_routing)
> _______________________________________________
> _______________________________________________
> B.A.T.M.A.N mailing list
> B.A.T.M.A.N@open-mesh.net
> https://lists.open-mesh.net/mm/listinfo/b.a.t.m.a.n
>
>   

Re: [B.A.T.M.A.N.] Masters thesis

[Troy Benjegerdes]

I have somewhat the same opinion of simulations.. garbage in, garbage
out. HOWEVER, being that my paying job is maintaining systems that DO
large simulations, I think there would be a HUGE benefit to both the
research community and the BATMAN software development for a coherent
simulation model. 

The simulation is *deterministic*, and does not depend on whether
someone has the microwave running when you're sending packets or not.
This allows you to perform repeatable tests on a proposed routing
algorithm change.

The problem with most simulations is they take some toy algorithm, that
is never actually used in the real world, and then someone publishes a
paper saying how great it is.

Now, if you could make a simulation engine than can take as input data
probabilities of packet loss or MAC layer problems, which was gathered
from a REAL running mesh network, then you have something. Even better
if you can compile the same BATMAN routing code and move data around
with virtual machines. You *could* use something like qemu to even
emulate the embedded CPU's, but I think the computation cost would be
far too high. However, running many native linux instances (kvm, or
somthing libvirt-based .. http://libvirt.org/drvuml.html) would probably
allow a pretty large mesh (maybe over 1000 nodes) to run in pretty much
real-time on a 64-128 node cluster.

Now you have the real-world system providing data to the simulation,
which can then allow testing of new algorithm tweaks in a repeatable
manner, which is quite hard with a real network.

All that being said, if you do IPv6 instead, I would use it for my
scheme to use wireless mesh networks for smart power grid applications ;)

On Fri, May 01, 2009 at 05:11:06PM +0200, elektra wrote:
> Hello Vojislav!
>
>
> My personal and very biased opinion is that simulations suck -  
> simulating a wireless mesh in all its complexity (the complexity of RF  
> propagation and interference is the first issue that comes to my mind)  
> needs a very, very sophisticated software and a really powerful  
> computer. Not to mention simulating real CPU load in mesh nodes and real  
> problems with wireless interfaces, unexpected problems of the MAC layer  
> and so on.
>
> I'd dare to say that the computational effort of simulating what is  
> going on in a mesh for 10 seconds is higher than taking 50 real machines  
> with real wireless interfaces, running them for days and getting real  
> results. Simulation seems to be important for the scientific world,  
> though. Having a implementation for the popular simulation programs  
> could increase the interest in Batman from the scientific world, but  
> honestly I don't care much. At a unit price of 25? per mesh-capable  
> wireless router running Open-WRT (D-Link DIR-300 for example) I don't  
> think it is necessary to do simulations anymore. However such a  
> el-cheapo grid would be only capable to test algorithms running on one  
> wireless interface and up to 5 wired interfaces. There are real testbeds  
> on this planet (like the "Meraka Massive Mesh") which are idling most of  
> the time, I guess.
>
> It would be awesome to have IPv6 support in Batman, to be up to the  
> changes and challenges that are knocking at the door. Also protocol  
> improvements regarding protocol overhead and convergence speed (both  
> topics are linked to each other, of course) is something we should work  
> on - and hammering your head on algorithms is fun.
>
> Cheers,
> elektra
>
>
>
>
>
>> Hello!
>>
>> I have about 20 weeks to do the master thesis. This time includes: getting familiar with the protocol, gathering other information needed for the task, analysis, report writing, coding, presentation preparation and probably some more stuff that I can't remember right now.
>>
>> Based on this list i would say that the tasks which could fit me are IPv6 support (the other tasks in this group seem to be more development towards the OS) and "Improve Batman with regards to protocol overhead and convergence speed" (with a risk that it would only result in a report). Maybe IPv6 would be more interesting to you guys since you would get something in return for helping me out.
>>
>> Another idea that came to my mind is building a B.A.T.M.A.N. module for ns2, and I have seen it being discussed here the last couple of days.
>>
>> The easiest task for me would be IPv6 support. It would also give me the opportunity to get some in-depth knowledge about IPv6 and some hands-on experience with it. But I would need to check if my professor would accept this topic. Otherwise, I'm not a fastidious (I just learned a new word in English :) ) person, so it wouldn't be a problem for me to do any of the tasks mentioned above.
>>
>> The next step is choosing one task and then making a thesis proposal, including a rough time-plan.
>>
>> Any comments or suggestions?
>>
>> Vojislav Marinkovic
>>
>> ________________________________________
>>
>> one afternoon of work (at maximum):
>> *  Modify Batman-0.3.X code so we have an option to compile it without
>> policy routing support
>> *  Modify the way that Batman-Advanced (Layer 2) deals with
>> broadcast/multicast payload packages (on multihop wireless routes there
>> is always packet loss, protocols like DHCP use broadcast or multicast
>> messages which are not send redundantly and not acknowledged, so these
>> protocols which are not designed to deal with a high level of packetloss
>> have difficulties to work on a Layer 2 mesh as the number of hops and
>> packet loss on the media increases)
>>
>> several weeks of coding effort (including tests):
>> *  Modify Batman-0.3.X  in order to support IPv6
>> *  Get support for other operating systems working (so far it only works
>> with Linux) -> depends on your knowledge of "other" systems
>> * merge batman adv userspace & kernelland code to reduce the maintenance
>> overhead
>> * automatic interface bonding for better throughput (layer 2)
>>
>> requires in depth knowlegde about batman:
>> *  Improve Batman with regards to protocol overhead and convergence speed
>>
>> mt. everest:
>> *  Implement a minimalistic and power saving Batman client version for
>> embedded mobile devices (requires extensive knowledge of 802.11 power saving
>> mechanisms and how to bring them into the mesh)
>> * multipath routing (as it always appears over and over again:
>> http://en.wikipedia.org/wiki/Multipath_routing)
>> _______________________________________________
>> _______________________________________________
>> B.A.T.M.A.N mailing list
>> B.A.T.M.A.N@open-mesh.net
>> https://lists.open-mesh.net/mm/listinfo/b.a.t.m.a.n
>>
>>   
>
> _______________________________________________
> B.A.T.M.A.N mailing list
> B.A.T.M.A.N@open-mesh.net
> https://lists.open-mesh.net/mm/listinfo/b.a.t.m.a.n

-- 
--------------------------------------------------------------------------
Troy Benjegerdes                'da hozer'                hozer@hozed.org  

Unless hours were cups of sack, and minutes capons, and clocks the tongues
of bawds, and dials the signs of leaping houses, and the blessed sun himself
a fair, hot wench in flame-colored taffeta, I see no reason why thou shouldst
be so superfluous to demand the time of the day.  I wasted time and now doth
time waste me.                        -- William Shakespeare