[Battlemesh] Mesh Routing Protocol Comparison

Moritz Warning moritzwarning at web.de
Sat May 2 21:45:59 CEST 2020

Hey Caleb,

nice to see you around. It is clear from the tests that yggdrasil and cjdns are not focusing on mobile mesh networks first. That's ok and gives opportunities to shine in other areas.

The scaling data does not have much values right now. E.g. batman-adv does not show that high overhead of 100KB/s per node for 200 node networks in the real world. Likely because all links have no latency. Updated results will follow, but it may take while, since a the scalability tests take over two days to run.

On 5/2/20 5:16 PM, Caleb James DeLisle wrote:
> Hey Mortiz,
> This data is fantastic. Thank you for putting this together. I'm surprised that the cjdns DHT stuff didn't come in last at everything. That algorithm is deprecated but left on because it does work when no route server is available. I'd really like to migrate to Yggdrasil algorithm for these cases.
> Obviously I'd love to have the kind of scaling properties of something like Babel, but cjdns and Yggdrasil have the additional constraint of having been designed to operate in an environment with hostile nodes.
> When I read the mobility testing, I'm not completely clear as to whether I'm looking at drop rate of pings between nodes who have themselves changed peer relationships, or between stable nodes in a globally dynamic network. In the second case I would intuitively expect to see a good showing from Yggdrasil since it will just switch to tree routing when it gets confused. However if the destination moves then that has to go through the DHT, and we might find this is in fact hobbling the protocol.
The ping arrival rate in the mobility graphs are the result of sending 300 pings from a random node to another random node. Some nodes have formed new connections 10 seconds ago.

Foe the percent value of the graph, only actually possible paths are counted. Thus, 100% means that all pings that can arrive in theory (checked via dijkstra) do have indeed arrived.

> If this is in fact the case, then my intuition is that the DHT nodes should gossip link state updates to their keyspace neighbors and communicating nodes should be able to subscribe to receive link state updates of those with whom they have active sessions.
Let's wait for updated results here as well and see if they paint a different picture.

> Thanks,
> Caleb
> On 01/05/2020 13:11, Moritz Warning wrote:
>> Hi folks,
>> I wrote a virtual test setup that supports multiple mesh routing protocols and produces nice graphs.
>> The whole setup is based on Linux network namespaces:
>> https://github.com/mwarning/meshnet-lab
>> So far, there are some preliminary results with a focus on convergence, mobility and scalability.
>> https://github.com/mwarning/meshnet-lab/blob/master/results/README.md
>> Keep in mind that these results are not "final" yet, as hardware limitations and pathological behavior play a dominat factor in some of the results.
>> I hope to be able to present the refined results at the next Battlemesh and have a lively discussion!
>> Best,
>> mwarning
>> Btw.: if you happen to have beefy server with good CPU/IO speed - let me know.
>> _______________________________________________
>> Battlemesh mailing list
>> Battlemesh at ml.ninux.org
>> https://ml.ninux.org/mailman/listinfo/battlemesh

More information about the Battlemesh mailing list