Reticulum Optimization & Scalability

[zyansheep]

The following is taken from a matrix conversation that I started 3 months ago and then promptly forgot about :P

Hello!

I've been reading the manual, and I'm curious, does reticulum do anything to optimize for the use of lower-latency / high-bandwidth paths? Or does it just minimize hop count when establishing links?
Also, from my first read-through I got the impression that it is intended for every transport node to keep track of every announce within a 256-hop "radius", could this potentially cause scalability issues with millions or billions of announces?

[faragher]

I can't speak to optimization, but regarding announces, "it depends." A network made up of of "full" mode interfaces would operate in that manner, making a current implementation of Reticulum rather storage-heavy at that scale.

Before I discuss Reticulum any further, I'd like to point out this is a solved problem in TCP. Routing tables don't contain the entirety of the Internet, and DNS can be authoritative over a specific domain or cache requests, but each server can point to various destinations which contain the information for smaller subnets.

So, Reticulum, as a mesh network without authoritative servers, functions in a slightly different way. Subnets can be designed to suit various use cases. (Sections 4.6.4 and 6.12 are helpful to have in front of you) Interface types and pairs can be used to change the network topography regardless of the physical links. One of the most appropriate here is the "gateway" type. It acts like a "full" interface but also answers path requests. Basically, by connecting to a gateway node, it will cache all announces it sees and will respond to any network queries by anything on the downlink.

"Access Point" does similar path responses, but has different announce handling. By having an AP downlink and a "full" uplink the uplink's announce won't propagate to the downlink (although they will be stored for path requests!) but the downlink can announce over the uplink, keeping the clients addressable.

I'm afraid I don't understand "boundary" modes well enough to explain their use case, and "roaming" appears to be specifically for mobile nodes, But this should be a good first order answer to how network topography controls can keep announces to reasonable levels even with a potentially large number of nodes.

Also, I may be wrong or oversimplifying. My understanding of the system is still incomplete.

[markqvist]

does reticulum do anything to optimize for the use of lower-latency / high-bandwidth paths?

Yes. One particular announce may arrive over multiple different interfaces with different hop counts and at different points in time. Since every announce is unique, the transport engine can select the optimal path based on both hop count and latency. The current implementation tries to minimize both hop count and latency over time, but will prioritize using a lower-latency (most likely higher bandwidth) path over a slow one with few hops.