On Thursday, March 27, 2014 4:51:54 PM UTC-4, Dietrich Ayala wrote: > One of the biggest problems in the markets that Firefox OS has shipped is > connectivity - it's usually some combination of rare, slow, unreliable and > expensive.
One of my roles at a previous startup was write software responsible for maintaining a stable connection between two moving peers over an unreliable connection and behind NATs. It is a story of serial failures, which is best summarized as compounding all the complicated realities of a network: http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing 1) The network is NOT reliable: There is both packet loss and disconnections to contend with. Packet loss can be mitigated, but disconnections can be in the order of minutes when moving from one network to another, or in the order of days when your peers are "off". 2) Latency is NOT Zero: Latency is often over 2 seconds, and can reach 2 minutes, assuming you have a working path to your peer. I found that the application layer is affected by this high latency, so the presentation layer required all messages declare lifetimes. This required all applications have long term plans if sending a message fails. High latency also demanded that acknowledgements be rare, and as a result, larger. Larger acks had to be moved up to the presentation layer, but had the benefit of summarizing successes and failures at a higher level. 3) Bandwidth is LIMITED: Exploring the network for peers consumed a lot of bandwidth. Furthermore, the transport layer had to be tolerant of missing acks, and not send too many itself. When a connection is working, it is better to send as much information as possible blindly and wait for a more detailed, but delayed, acknowledgment. 4) Network is NOT secure: Encryption was pushed down to the network layer. Packets had to be designed so their routing information and tracking numbers were inside the encrypted packet. Since packets can arrive from any peer, public keys were used to encrypt based on the destination, which the required all the key management infrastructure (registering keys, expiring keys, and trust hierarchies). 5) Topology DOES change: Moving peers, and UDP hole punching require a lot of network exploration: Given the latencies and unreliability that is expected, this exploration involved sending many packets with little expectation they will reach their intended destination. It also required maintaining long-lived lists of possible addresses, to minimize the number of exploratory packets. Since the protocol I worked on only dealt with point-to-point communications over an established network, the other three issues never needed to be dealt with; I imagine mesh networking will: 6) There are many/zero administrators: At the very least a mesh network will require trust hierarchies and "special" nodes that help establish connections. Mozilla already has this expertise. 7) Transport cost is NON zero: Given the complexities of establishing a simple peer-to-peer connection over established (but unreliable) networks, I imagine exploring and maintaining routes through the mesh network will be a resource intensive task, both in communication overhead, and in the amount of knowledge kept on each node. I do not know the state of the space, but I imagine the first step is write the mesh routing algorithms and test them on virtual networks that mimic topologies we expect to see in the wild. 8) The network is heterogeneous: I only had to deal with IP. Successful mesh networks may require nodes to be multilingual - able to communicate on many different data link layers - which FFOS is doing well given the features on a smartphone. > > Should we look to mesh networking to fill this gap? Yea! That'd be cool! _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
