Appreciate your feedback. You'll see the answers in time, Ben. Best regards, Rick C. Hodgin
-------- Original Message -------- From: Ben Mendis <[email protected]> Sent: Sun, Jun 24, 2012 08:51 PM To: [email protected] <[email protected]> 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 >[email protected] >http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss _______________________________________________ Freedombox-discuss mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
