Re: [lime-dev] [Mesh] From libre-mesh - lime-dev

27 Jul 2013

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Well, this kind of discussions is what I was trying to avoid... but it
is my fault for starting it.

On 28/07/13 01:30, Mitar wrote:
...
  Hi!

  The idea is to make a meta-firmware which can be
used as basis
 to create specific community firmwares. The project is named
 libre-mesh [5].  
 To throw a ball back at you: why another meta-firmware? We already
 have OpenWrt. Why libre-mesh cannot be just one package for
 OpenWrt, which configures and depends on anything you believe
 should be there? Then other communities can just fork that package
 and adapt it. Or just add additional packages. 
It is exactly what we are doing. Please see our repositories you will
find lime-packages which is an OpenWRT feed.

...
  Because I don't see firwmare anything more than
just a list of
 packages + configuration + few small scripts. I don't see this as
 such big additional split of work as you are describing. Or is
 there more to firmware development? 
Well, I would not say "few small scripts", it is a bit more than that.
I don't know about which firmware are you speaking about but in my
experience if you want to end up in a stable, powerful and flexible
system you need more than "few small scripts".

...
   Batman-adv is
very nice, but you cannot have a single collision
 domain cloud for all the nodes because it does not scale.  
 Have this been proven/shown anywhere? Aren't there Batman-adv mesh
 nodes with 1000 nodes in existence (or in fact in Batman-adv you do
 not care so much about the nodes, but about number of individual
 MAC addresses in the mesh, including clients and anything bridged
 to the mesh)? 
Ask yo AlterMesh guys who are starting having problems with
scalability. Can you imagine which is the total amount of ARP packages
in a 1000 nodes bat-adv cloud? (just to put an example)

...
   So, the
network have to be splitted in several clouds. To
 federate them a layer3 routing protocol is needed, so here is
 where we use BMX6 [7].  
 Why would you need to use BMX6 to federate them? Isn't just Quaga
 with Batman-adv on both sides enough on a gateway node between
 clouds? Or are you saying that BMX6 should run on top of Batman
 clouds on all nodes and not just on gateways? 
Quagga is a suit which includes several routing protocols. Quagga
could be used to federate bat-adv and bmx6. But if you are speaking
about use static routing, I would just say it is a big mistake (what
happens when you have to paths to the same cloud?).

...
   Why? because
BMX6 (100% rewritten fork of Batmand with native 
 IPv6 support) is very powerful and produces a very low overhead
 (see [6]).  
 But how does this overhead compare with speed of convergence
 (adaption to the changes in the mesh). Because overhead is in
 general inversely related to speed of convergence. More packets you
 send around, higher the overhead is, faster you can inform
 everybody that there was a change in topology. So this graph
 without a related graph of speed of how fast the routing protocol
 adapted nodes is not really useful. So I am interested in a
 scenario where somebody is actively talking to a node which is
 moving around. If my connection to the node stays working while in
 all cases, but one routing protocol has lower overhead to achieve 
 this, then this is a better routing protocol.

I agree with your approach about compare overhead and routing changes.
However I can say this test was made during the WCW-Berlin. The
scenario was around 15-20 nodes (ask UFO to to know it better) in a
mobile scenario (it means someone moving nodes). All protocols were
running at same time in different VLAN (see battlemesh firmware in
github) so all of them were in the same situation. Just to give you
another detail, the tested protocol which showed more difference
between moving and not moving environment was Babel.

By the way, the conclusion of this tests was: BATMAN based protocols
are better in the overhead-mobile test.

...
  Mitar

Cheers, Mitar. Hope to see you in October.
- -- 
./p4u
...PGP SIGNATURE...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQEcBAEBAgAGBQJR9F2YAAoJEAX7rWpc+YnN2/UH/2Jo0bujrjXBwGwN2vP5oi+q
5O5w5jQZ6uQEaeruwEXrmtNeucY1p9yNkXLhxDnSFWYQup4Qt4KvAdJPOQ+/pjBf
7khnwvHgD9Pupce/F8dLbmgrdUTlmThZdrug1EQHPnHwekTHwPO6/DraDYgf6Pzf
NPu0QGQDFi0zk1sBbWxXeizvcmxXhgbID9yptp6p+XIn4wvJkAVw1d3N2jHcUDRe
fg/KBQeUsCqViwMnclylOwS6Q73UpJ6yW4wVAiphwS7KpZHYn+X/yYK0NbD8kQfL
3EtUufaUxoAUgfan1qQJcP8ItEV24ylrnkJTueV06/DP65NS3O2RykfOPwM6Tyo=
=skVf
-----END PGP SIGNATURE----- 