[Mesh] From libre-mesh

[Pau]

-----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
-----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-----