-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 28/07/13 02:50, Mitar wrote:
Hi!
Well, this kind of discussions is what I was trying to avoid...
but it is my fault for starting it.
No no. It is important to discuss this things. You cannot just
believe that people would just take some firmware without trying to
understand it and reasons for why something is like it is and not
some way around? So don't see this as a flame but more as a way to
teach/show.
Of course people should ask and understand before choosing some
specific existing solution. But I did not want to start this kind of
discussion here (in this post). I just w
anted
to let you know about
libre-mesh project.
Also I feel like you are trying to find some "week points" in our
approach to be able to say "it does not work for us" and I have to
defend it to convince you. I don't feel comfortable doing this, I just
wanted to let you know about libre-mesh because I have seen in your
WiKi many points in common with us. But of course the decision is yours.
It is exactly what we are doing. Please see our repositories you
will find lime-packages which is an OpenWRT feed.
Great!
This maybe means that talking about "firmware" is not the right
word. But more about a set of packages? Because then it is easier
to imagine that another
community network takes few of those
packages and add few theirs and maybe even then put them all
together in one feed for later community network to build upon.
I like "firmware" more than "set of packages" because at the end
libre-mesh will be a firmware (software for embedded devices). But OK,
it is just a way to refer to the same thing.
So I think the most important thing is not to see firmware as one,
but to learn which problems/issues you already solved with which
packages and see how to build upon that and contribute back, no?
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".
Can you maybe just show us few examples of such scripts? Just so
that it is easier to imagine what kind of things one have to think
about when developing a firmware?
It is not yet done in Libre-Mesh because it is in development. But you
can surf over the qmp.cat git repository to see the amount of code we
have (just the luci-based web iface is more than a "few scripts").
If you want to do a generic solution (like libre-mesh) you need a lot
of code to adapt to any scenario. But of course, if you want to have a
solution just for your network, the amount of code could be quite small.
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 only ARP packets are the issue. Other broadcast packets you can
simply drop with a ebtables firewall rule. You can still use
ZeroConf, because it is multicast and not broadcast.
Using ebtables is dirty and a patch to solve something that layer3
solves. And have you thought about IPv6? It does not have broadcast
but multicast link-local domains which can end-up in a big storm too
(RA announcements and requests).
And for ARP packets Batman could probably provide some fake proxy,
where the node would answer them directly instea
d of
broadcasting
them around. Or maybe tunnel them directly to the node who can
answer them. (Because Batman knows exactly where any MAC address in
the network is. You do not really have to broadcast around to get
this.) In a similar way that Batman currently handles DHCP by
intercepting the packets and responding itself.
Hey Mitar, would you try to layer2 bridge all the Internet? Or even
just your city? Collision domain is for small sets of computers, the
networking stack we are using based on MAC/IP is not ready to have 1k
computes in the same domain. Broadcast storms, ARP problems (including
poisoning!), huge overhead just to mention some of the problems you
would have. IMHO trying to patch it by modifying batman-adv is a
mistake. Layer3 routing is exactly done to solve these situations.
So I am not sure that it is smart to add another layer (another
routing protocol) of complexity to the networking stack, where we
could just learn and build upon existing tools. As you said, if I
paraphrase, not yet another routing protocol. Cannot we have just
one and all contribute to that one? So if Batman works in most
cases, let's fix those cases where it does not.
Guido already answered you and I agree with what he said. We had
several meetings with the Batman-adv guys and everybody accepted it
was a problem which has to be fixed using a second routing protocol.
It is complex to explain, if you want we can organize an audioconf.
Quagga is a suit which includes seve
ral
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?).
So are you saying that BMX should be run over whole mesh on layer 3
with Batman below on layer 2? Or are you saying that it should be
used only on gateways. I am not sure what exactly you are saying
here. Do you have some more concrete example/presentation of this
idea? So how does one packet travels around the network in your
topology of BMX + Batman?
I agree with your approach about compare overhead and routing
changes. However I can say this test was made during the
WCW-Berlin.
For others, WCW is a yearly mesh-related even in Berlin, Wireless
Community Weekend:
http://wiki.freifunk.net/Wireless_Community_Weekend_2013
More locally targeted for the whole Freifunk community to get
together from all around the country, once a year. (So most of the
stuff you will find will probably be in German. :-) )
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.
Is there any description of the scenario? So if they were just
moving the nodes around without communicating with the node at the
same time, then this data is useless.
Mitar
, you
have been in the BattleMesh before. You know this is not a
perfect research environment. But Axel, Henning, Jow, Simon, Elektra
etc... were there supervising the experiments so I want to believe the
results obtained are relevant since the elite of the mesh networking
was there.
Just to give you another detail, the tested protocol which
showed more difference between moving and not moving environment
was Babel.
This might be just that Babel adapts in a smart way to the moving
and starts sending more updates. :-)
I don't think so. Babel acts as a static protocol when the network is
not moving, but when it moves it produces a very very high overhead
(compar
ed to
other distance-vector protocols). I don't see this very
smart since for static deployments you could do the same using BGP or
OSPF.
By the way, the conclusion of this tests was: BATMAN based
protocols are better in the overhead-mobile test.
Yes. Their ways of updating the information about the network
topology is really interesting and charming. But sadly the overhead
is not the only thing which matters. Speed of convergence to new
topology, no routing loops, and no disruptions in service are other
which are important as well. Personally, I would not really care so
much if routing protocol has bigger overhead if this means it works
for people.
Of course
it is
not the only important thing. However in the last
BattleMesh, BMX6 was the better in coverage time and in best-path
selection. You have the results raw data in the battlemesh web page.
And in general nodes do not really move around so much. Clients do
(Batman has roaming support for them), but nodes, not really. At
least until we have nodes installed on cars and bikes. Nodes do
come up and down and at that time it is not so important how fast
new topology converges, that is true.
It will depend on the environment. The scope of libre-mesh is cover
any kind of deployment.
Cheers, Mitar. Hope to see you in October.
Sadly, I will not have time to attend the summit this time. :-(
Let me ask you something now. Is there any other "hacker" in this
project which knows about mesh networking? How many people do you have
working on firmware? I hope this conversation is useful for someone
else because at the end we are always the same people discussing the
same things (I did not know you were involved here!).
Cheers
Mitar
- --
./p4u
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
iQEcBAEBAgAGBQJR9Oe+AAoJEAX7rWpc+YnNpz4H/1wI7kSeihTqZM3QZqn32xwZ
wQjGoyTTvemJPhKAd28fJIe6IeqtlncMCrTAaswjAyg7w+utmfMcapUVKEkoTJY9
h+zTmaWO/p8a6zt7YR2pH+mfCbwy5OtXxzAZwT26dlcC2U0/noocg8cXxEAeZvuw
nt2ABQ7Vs2aqzoTIXw9mSE1PgSAcx3t6r4VvyR8GUMmnVXbSvXimMvub9ie4JbUy
tuqK1zZq6CxHffLatMLJT6tXU+JOtxF6j819NDBjlhuX/Xw0NeJPZjFUa9UVW6C4
/cAKxN/kukvgiNa70MNjNOB2oLJuTH+u2YStMDLVJUS0x9i7uuKCFe6aejwQ/as=
=fYo1
-----END PGP SIGNATURE-----
mesh mailing list
mesh@lists.sudoroom.org
http://lists.sudoroom.org/listinfo/mesh