[Freedombox-discuss] Freedombox Mesh Network Simulator

[Rick C. Hodgin]

Appreciate your feedback. You'll see the answers in time, Ben.

Best regards,
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>
 CC: 
 Subject: Re: [Freedombox-discuss] Freedombox Mesh Network Simulator

>-----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-----
>
>_______________________________________________
>Freedombox-discuss mailing list
>Freedombox-discuss at lists.alioth.debian.org
>http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss