[Freedombox-discuss] Freedombox Mesh Network Simulator

Ben Mendis dragonwisard at gmail.com
Mon Jun 25 00:51:49 UTC 2012


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

Hi Rick,


On Sun, 24 Jun 2012, Rick C. Hodgin wrote:

> My mother past away in January.  My brother and I spent some time this 
> weekend putting her house in order for a sale.  It's thrown all prior planned 
> weekend activities off.

I'm sorry to hear that. You have my condolences.

> Here are some nuggets to chew on regarding its design.  I have solidified on 
> a relative grid-based design, the coordinates of which can come from either 
> some system of relative FBX positions, or, for a more agile, public, adhoc 
> grid, true GPS coordinates.

I don't want to seem like I'm being negative, but I think your design is
naive and impractical. For example, accurately determing the physical
position of a node is difficult. Even with GPS, it can be a challenge as
the GPS might report an inaccurate position or might fail to determine
the position at all. And assuming you have an accurate way to determine
the position, how do you know you can trust the positions reported by
other nodes? And even then, if you have an accurate position and you
know that other nodes are reporting accurate positions to you, physical
location/proximity is not a reliable real-world indicator of whether or
not there is connectivity between two nodes. Two nodes might be very
near to each other, but not have any connectivity with each other, while
having very good connectivity to other nodes which are further away. So
in general, I think the idea of relying on physical location to route
traffic is not a realistic approach.

> All nodes on the grid coordinate thusly:
>
> 1)  No unnecessary communication.

I think you falsely assume that the "chatty" communication that existing
routing protocols rely on is "unnecessary". Figuring out how to reduce
that traffic would be a big optimization, and it's certainly an open
problem in the field, but eliminating it is a mistake.

> 2)  Chirps initial position to determine neighbors.

Ok, but what about if it moves or goes off-line? How do the neighbors
determine if the initial chirp is still valid if it doesn't update
periodically?

> 4)  Determines route to open up a channel / path to send streams of data.

How does it do that? Are you suggesting it just does a calculation to
determine which neighbor is the next closest in terms of physical
distance to destination? As a said before, I believe that to be a
mistake. The next physically closest node might not have any suitable
routes to deliver that packet, meanwhile a node that is physically
further away might have an appropriate route.

> Note:  Remember that since we're using grid-base communication, each node 
> always knows from where it is to where it's going.  So it's always looking 
> for nodes which can get the information sent over "that way," and "in that 
> direction".  In the event of an obstacle (a downed portion of the mesh, a 
> hole in active nodes there), it will seek alternate routes which go around 
> the hole, but initially it tries the most direct route as each node as each 
> node will know the location of nodes around itself.

The "try a direct route first, then backtrack" approach might be
marginally faster when a direct route exists, but it could be much, much
slower if it does not. I think you'll find that even in a relatively
trivial example the cost of indirect routes will be prohibitively
expensive.

> 5)  If a node is mobile, it updates itself as it moves.

Again, you're relying on having accurate positioning information, and
an explicit correlation between position and connectivity.

> 6)  Communication of whatever comes in.

I'm not sure what you mean here.

> 7)  Broadcast to one or many.

You want to support multicast? How do you see that working here?

> 8)  Some other things too numerous to mention. :-)

Ok, well here's another question. How are you planning to map IPv4/IPv6
addresses to geographic node addresses? That's going to be key to a
number of issues here, including how multicast routing will work. Or are
you planning to just replace IPv4/6 addresses entirely? What are you
going to do about directional antennas? And on that note, you seem to
implicitly assume that Layer-1 is Wi-Fi, what if it's not? What if it's
wired ethernet, or fiber-optics, or Ronja, or amateur radio, or a
cellular modem?

I realize that using geographic position seems like an obvious way to
efficiently route packets, but for a variety of reasons, including those
listed above, I don't believe it's a practical strategy. I think the
answer will be to allow nodes to do neighbor discovery and build a
virtual map of the network's topology, as the virtual topology often
bears little or no relation to the physical topology. Understanding the
virtual topology will result in the most efficient routes.

Again, this criticism is meant to be constructive. I'm not trying to
discourage you from experimenting with mesh networking protocols. I am
certainly no expert, so it's conceivable that you might prove me wrong.

Best regards,
Ben the Pyrate

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJP57YlAAoJEMco5sYyM+0wkF8H/i2KvGRol8U/jCEQohwSB+lx
r7jntUChkranuXivbZ0B/flc8bAbFyVrDS6AAABJxoLAuBw0AWxS1CiEi7A/EXC8
EEF6Qzz7MCjjiX9dX6YYs9LtdAADg1eGde1bTT9NKRVi3jIfkDzise/fg4FgCo+L
FnUU6KP3HRAjv/3S3NkjKk75pc4uQyxhztUdrKRLkttgzfMdQ5XxJMOM8U1eYEBX
l5TdNlc8qa/dBeDfVQXnOIid21B03nKu9oXqgcKDQJb0fazc2d3NBCnxrx9Rh0aM
CiSBE7zlusSKl4gBxw6JlHqNg1yToeIf0rThSakcP6KPtGSbNj1xeXAOrFjXqEc=
=PqyI
-----END PGP SIGNATURE-----



More information about the Freedombox-discuss mailing list