[franek]

Does Reticulum routing always prefer the path with the fewest hops, even if a path with more hops might have higher throughput or lower latency?

That's how I understand the manual (https://reticulum.network/manual/understanding.html):

> Once an announce has reached a node in the network, any other node in direct contact with that node will be able to reach the destination the announce originated from, simply by sending a packet addressed to that destination. Any node with knowledge of the announce will be able to direct the packet towards the destination by looking up the next node with the shortest amount of hops to the destination.

[LinuxinaBIt]

I like the way you’re thinking but it doesn’t necessarily work like that in practice. Why? Because of how announce queues work, each interface has its own queue, and announces are limited very specifically to 2% of a channel’s bandwidth.

This means that announces are much more likely to be transferred over the faster medium first, resulting in paths that are on average the most reasonable balance between speed and distance.

If that doesn’t make sense at first, I get it. I find trying to visualize how it works really helps. Reticulum is conceptually so different from anything else out there that it takes a while to understand.

See http://reticulum.network/manual/understanding.html#the-annou... for more details.

[franek]

That does make a lot of sense, at least in terms of latency: I imagine that when a one-hop announce comes back from outer space, the faster multi-hop path across town will have already been established.

For bandwidth, however, I don't see it yet. If all relevant nodes are idle at the time an announce comes in (so the 2% limit doesn't come into effect), a low-bandwith route might be established before one with a much higher bandwidth, no? (Prioritising latency over bandwidth can be the right thing to do, of course, depending on what the network is used for. But it might not.)

[LinuxinaBIt]

Sure, in some cases, when the network has fewer announces to deal with, the 2% limit has less effect, the best way Reticulum can deal with this is with a network made out of more specialized node types connecting the lower speed links (http://reticulum.network/manual/interfaces.html#interfaces-m...)

However when the network (and each node) is receiving enough announces to saturate that 2% chunk of most smaller links, those interfaces prioritize announces with less hops, and there is a queue, meaning it takes that interface longer to transport announces coming from further away. This makes it much more likely that nodes will form routes over a faster but longer path.

[franek]

> Sure, in some cases, when the network has fewer announces to deal with, the 2% limit has less effect, the best way Reticulum can deal with this is with a network made out of more specialized node types connecting the lower speed links (http://reticulum.network/manual/interfaces.html#interfaces-m...)

I see. So it seems that optimizing a complex network can be a little more hands-on, not completely automatic (which would be a bit too much to ask, thinking about it). I guess my hypothetical path via outer space would have a "boundary" mode node somewhere on the way, although I am still fuzzy on how exactly this would affect things.

And your point about the announce queue with saturated 2% bandwidth is clear.

Thanks so far! This makes me want to read the rest of the manual and possibly start tinkering with Reticulum myself at some point.

[LinuxinaBIt]

Yeah, exactly what each type of node does gets a bit into the weeds where even I don't really know. You can ask in the Github Forum (https://github.com/markqvist/Reticulum/discussions) or Matrix Room (https://matrix.to/#/#reticulum:matrix.org) if you need more detailed information :)