3 ms·

I’ve looked at a few of the LoRa-based mesh network systems over the last couple months. They all seem to have a philosophical document of some sort, like this

by drob518 10mo ago

I’ve looked at a few of the LoRa-based mesh network systems over the last couple months. They all seem to have a philosophical document of some sort, like this one, sometimes buried as part of the user docs, but none of them have clear protocol specification docs. When I look at their node maps, the node counts are absurdly small (like 20 nodes in a city of 1 million people). I suspect each of them has major scaling issues. Sure, mesh networks are great because they are more resilient, but if you trust nobody and you have no sense of a route to a destination, you’re left with flooding as your primary next-hop selection method, which means you’re going to be about as scalable as an old Microsoft LAN Manager network was in 1995 (which is to say not very). Short of reading the code, does any sort of protocol documentation (or better yet, analysis) exist for Reticulum? Edit: looks like the Reticulum Manual might have some more technical details. https://github.com/markqvist/Reticulum/blob/master/docs/Reticulum%20Manual.pdf https://github.com/markqvist/Reticulum/blob/master/docs/Reti...

AyyEye 10mo ago
Reticulum is absolutely not flood routed and is not "LoRa-based" lmao. Typical hn comment. Planetary-scale networks is mentioned as a design goal on the first page of the docs https://reticulum.network/ https://reticulum.network/ which are hidden at the very top of the git repo.
- wredcoll 10mo ago
  Design goals are great. How do they actually achieve it?
  - AyyEye 10mo ago
    Not with flood routing.
    - drob518 10mo ago
      Yes, you said. You’ve been very helpful in telling us how it doesn’t work.
    - bigbadfeline 9mo ago
      flood routing works fine locally, from there on use IP to connect the local networks, no need to reinvent the wheel.
      - drob518 9mo ago
        Sure, but The Zen of Reticulum repeatedly says that all that centralized infrastructure is bad, bad, bad. So, it seems a bit like cheating if you still need all that to scale.
  - drob518 10mo ago
    Exactly. Okay, that’s a great claim. How? Also, “planetary scale” is meaningless. With the right node count (low), topology, and radios, just about any mesh network can achieve “planetary scale.” But that doesn’t mean it’ll support 10 thousand users, never mind millions. There are underlying technical reasons that the Internet works the way it does.
- drob518 10mo ago
  Okay, maybe Reticulum isn’t strictly LoRa-based, but others are (e.g. Meshtastic), and while Reticulum works over lots of physical layers, the README specifically states “An open-source LoRa-based interface called RNode has been designed specifically for use with Reticulum.”
the__alchemist 10mo ago
> but none of them have clear protocol specification docs This is a big turn off for me. I have seen it for a number of protocols beyond mesh ones. ESP-Hosted does this too. So does ELRS. Maybe I'm too used to reading data sheets etc, but if your protocol requires a specific implementation, I am put off by the friction: I must integrate your software, in the language you used, and will likely hit compatibility problems as a result.
- drob518 10mo ago
  Exactly. And are you going to break it one day just because and force every node to run the new version of firmware to stay active. I like implementers who show some transparency and some self-reflection about the limits of the protocol. And to be clear, in looking through the other docs in the Reticulum repo, it looks like there are more protocol details there, so maybe Reticulum has that transparency.
alnwlsn 10mo ago
Meshtastic is the most popular in my area. I can see about 150 nodes from my house in a US county of ~300K (though actually being able to talk to most of those remains questionable). I am certain the popularity of Meshtastic is down to how easy they have made it to onboard. Buy the module, flash using the web flasher, install the app on your phone, done. There's a Youtube tutorial on every street corner for this, even though I (and seemingly many people) don't find Meshtastic to be all that reliable. For reference, this is what Meshtastic has to say about their flood-based mesh protocol: https://meshtastic.org/docs/overview/mesh-algo/ https://meshtastic.org/docs/overview/mesh-algo/
- drob518 10mo ago
  To be clear, I’m not harshing on Meshtastic’s node counts. In some sense these systems are like packet ham radio. They appeal to a specific user base. I just question how their protocols are going to scale, and even 150 nodes is extremely small compared to the number of people around you who are using the Internet, WiFi, etc. So, for instance, at the URL you referenced, it says at the bottom: > As meshes grow larger and traffic becomes more contentious, the firmware will increase these intervals. This is in addition to duty cycle, channel, and air-time utilization throttling. > Starting with version 2.4.0, the firmware will scale back Telemetry, Position, and other ancillary port traffic for meshes larger than 40 nodes (nodes seen in the past 2 hours) using the following algorithm: > ScaledInterval = Interval * (1.0 + ((NumberOfOnlineNodes - 40) * 0.075)) > For example an active mesh of 62 nodes would scale back telemetry.device_update_interval to 79.5 minutes instead of the 30 minute default. It looks like they are already building back-off strategies as the net scales, and that starts to happen at very low node counts (just 40). So, what happens when node counts hit 500 or 1000? Again, not trying to throw stones; just trying to understand how far these protocols can go and how they degrade/fail as they scale. Ideally, they don’t fall over and even possibly get more robust (with more nodes, there are typically more topological connections between nodes, which provides more possible paths and resiliency).
reticolon 9mo ago
Reticulum has no bandwidth management. If your node or the whole local area is flooded with traffic from the rest of the network there is nothing you can do. "Reticulum does not include source addresses on any packets" and with that you cannot throttle passing-through traffic based on source. Any hope of scaling is gone.
- tbrockman 9mo ago
  I believe the recommendation would be to use https://reticulum.network/manual/using.html#using-blackhole-management https://reticulum.network/manual/using.html#using-blackhole-... in such scenarios.
  - reticolon 9mo ago
    Unfortunately that cannot work. You don't know in advance the traffic destination or source.
sleepybrett 9mo ago
Seattle is showing >400 nodes for meshcore: https://meshcore.co.uk/map.html https://meshcore.co.uk/map.html

by drob518 10mo ago

AyyEye 10mo ago

Reticulum is absolutely not flood routed and is not "LoRa-based" lmao. Typical hn comment. Planetary-scale networks is mentioned as a design goal on the first page of the docs https://reticulum.network/ https://reticulum.network/ which are hidden at the very top of the git repo.

wredcoll 10mo ago
Design goals are great. How do they actually achieve it?
- AyyEye 10mo ago
  Not with flood routing.
  - drob518 10mo ago
    Yes, you said. You’ve been very helpful in telling us how it doesn’t work.
  - bigbadfeline 9mo ago
    flood routing works fine locally, from there on use IP to connect the local networks, no need to reinvent the wheel.
    - drob518 9mo ago
      Sure, but The Zen of Reticulum repeatedly says that all that centralized infrastructure is bad, bad, bad. So, it seems a bit like cheating if you still need all that to scale.
- drob518 10mo ago
  Exactly. Okay, that’s a great claim. How? Also, “planetary scale” is meaningless. With the right node count (low), topology, and radios, just about any mesh network can achieve “planetary scale.” But that doesn’t mean it’ll support 10 thousand users, never mind millions. There are underlying technical reasons that the Internet works the way it does.
drob518 10mo ago
Okay, maybe Reticulum isn’t strictly LoRa-based, but others are (e.g. Meshtastic), and while Reticulum works over lots of physical layers, the README specifically states “An open-source LoRa-based interface called RNode has been designed specifically for use with Reticulum.”

the__alchemist 10mo ago

> but none of them have clear protocol specification docs This is a big turn off for me. I have seen it for a number of protocols beyond mesh ones. ESP-Hosted does this too. So does ELRS. Maybe I'm too used to reading data sheets etc, but if your protocol requires a specific implementation, I am put off by the friction: I must integrate your software, in the language you used, and will likely hit compatibility problems as a result.

drob518 10mo ago
Exactly. And are you going to break it one day just because and force every node to run the new version of firmware to stay active. I like implementers who show some transparency and some self-reflection about the limits of the protocol. And to be clear, in looking through the other docs in the Reticulum repo, it looks like there are more protocol details there, so maybe Reticulum has that transparency.

alnwlsn 10mo ago

Meshtastic is the most popular in my area. I can see about 150 nodes from my house in a US county of ~300K (though actually being able to talk to most of those remains questionable). I am certain the popularity of Meshtastic is down to how easy they have made it to onboard. Buy the module, flash using the web flasher, install the app on your phone, done. There's a Youtube tutorial on every street corner for this, even though I (and seemingly many people) don't find Meshtastic to be all that reliable. For reference, this is what Meshtastic has to say about their flood-based mesh protocol: https://meshtastic.org/docs/overview/mesh-algo/ https://meshtastic.org/docs/overview/mesh-algo/

drob518 10mo ago
To be clear, I’m not harshing on Meshtastic’s node counts. In some sense these systems are like packet ham radio. They appeal to a specific user base. I just question how their protocols are going to scale, and even 150 nodes is extremely small compared to the number of people around you who are using the Internet, WiFi, etc. So, for instance, at the URL you referenced, it says at the bottom: > As meshes grow larger and traffic becomes more contentious, the firmware will increase these intervals. This is in addition to duty cycle, channel, and air-time utilization throttling. > Starting with version 2.4.0, the firmware will scale back Telemetry, Position, and other ancillary port traffic for meshes larger than 40 nodes (nodes seen in the past 2 hours) using the following algorithm: > ScaledInterval = Interval * (1.0 + ((NumberOfOnlineNodes - 40) * 0.075)) > For example an active mesh of 62 nodes would scale back telemetry.device_update_interval to 79.5 minutes instead of the 30 minute default. It looks like they are already building back-off strategies as the net scales, and that starts to happen at very low node counts (just 40). So, what happens when node counts hit 500 or 1000? Again, not trying to throw stones; just trying to understand how far these protocols can go and how they degrade/fail as they scale. Ideally, they don’t fall over and even possibly get more robust (with more nodes, there are typically more topological connections between nodes, which provides more possible paths and resiliency).

reticolon 9mo ago

Reticulum has no bandwidth management. If your node or the whole local area is flooded with traffic from the rest of the network there is nothing you can do. "Reticulum does not include source addresses on any packets" and with that you cannot throttle passing-through traffic based on source. Any hope of scaling is gone.

tbrockman 9mo ago
I believe the recommendation would be to use https://reticulum.network/manual/using.html#using-blackhole-management https://reticulum.network/manual/using.html#using-blackhole-... in such scenarios.
- reticolon 9mo ago
  Unfortunately that cannot work. You don't know in advance the traffic destination or source.

sleepybrett 9mo ago

Seattle is showing >400 nodes for meshcore: https://meshcore.co.uk/map.html https://meshcore.co.uk/map.html