[Freedombox-discuss] Freedombox Mesh Network Simulator
Appreciate your feedback. You'll see the answers in time, Ben.
Rick C. Hodgin
-------- Original Message --------
From: Ben Mendis <dragonwisard at gmail.com>
Sent: Sun, Jun 24, 2012 08:51 PM
To: freedombox-discuss at lists.alioth.debian.org <freedombox-discuss at lists.alioth.debian.org>
Subject: Re: [Freedombox-discuss] Freedombox Mesh Network Simulator
>-----BEGIN PGP SIGNED MESSAGE-----
>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
>> 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
>> 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
>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.
>Ben the Pyrate
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.11 (GNU/Linux)
>-----END PGP SIGNATURE-----
>Freedombox-discuss mailing list
>Freedombox-discuss at lists.alioth.debian.org