Proposal: Manual Latency Shift Tuning for Routing Preference

[peigongdsd]

We are using Yggdrasil in a small-scale network and greatly appreciate its redundancy and multi-hop relay capabilities. To enhance robustness, we've adopted a topology with redundant peerings instead of a lean, tree-like structure.

However, we’ve observed a notable downside in the current routing behavior. Yggdrasil prioritizes low-latency paths, which is often stupid—some nodes offer better bandwidth but slightly higher latency. Currently, there is no mechanism to manually adjust or influence this routing preference.

Ideally, under heavy traffic, the latency to an overloaded node should increase, which should raise the calculated cost of paths through that node and steer new connections away. In practice, however, we’ve found that cost values often do not reflect real-time network congestion, and newly established connections still prefer that bandwidth-saturated paths. This leads to significant network jamming.

Suggested Temporary Workaround

We propose introducing an optional tuning parameter per peering:

Peers: [
    "tls://very.low.bandwidth:1999?latencyshift=xxxx"
  ]

This latencyshift should artificially inflate the latency used in routing decisions (i.e., effective_latency = real_latency + latencyshift) for a specific peering. This would discourage routing through known low-bandwidth or congested links.

Global Node-Level Option

To generalize the idea further, we suggest a node-level setting:

GlobalLatencyShift = 100  # in milliseconds

This would apply the latency shift to all peerings with the node (excluding multicast-discovered links), allowing bandwidth-constrained nodes to signal their limited capacity network-wide, reducing relay load through them.

---

These two parameters—LatencyShift and GlobalLatencyShift—offer a simple, manual mechanism to guide Yggdrasil’s routing decisions in small or specialized networks. We believe this should be relatively straightforward to implement and would significantly improve routing flexibility in constrained or heterogeneous environments.

[peigongdsd]

Addresses #1222

By design, the routing scheme of yggdrasil could hardly be interfered by human, so it should be wonderful if we have this hinting feature to suppress a particular peering.

[majestrate]

This seems like a reasonable hack to add in, my only curiosity is would these manual hints bleed out into the wider network somehow?

[peigongdsd]

This seems like a reasonable hack to add in, my only curiosity is would these manual hints bleed out into the wider network somehow?

I don't think so. TBH for the larger global-scale network we need a more comprehensive investigation of the Cost of a link. There are some possible considerations, e.g.

• Updating the link cost in real-time (or at least low latency), so when a link suffers from heavy congestion, newly established connections avoid it immediately. (I remembered in Yggdrasil 0.5.10 a smoothing process for the link cost was introduced to avoid spikes of latency measurement, which did the contrary, but there is a reason to do so unless we roam a session between multiple pathes)
• On transmission, the routing scheme should not stick to a single established Path, but actively seek out paths with lower costs, and route the data shards through different paths (the best path at the spot).

But these are just vague ideas, and would cost great time to implement and improve. Also the core routing scheme is not implemented here.

However, for a local internal Yggdrasil-based network, the initiation above is very easy to implement in this repository, and already good enough for maintainers to hint and tune the network manually, which leads to a much more usable private and local deployment.

[peigongdsd]

This seems like a reasonable hack to add in, my only curiosity is would these manual hints bleed out into the wider network somehow?

And, if one is to join the wider network, this consideration should still work, especially when a node is hinted with GlobalLatencyShift so every peering with this node is having a equalled shifted latency set, it would be greatly suppressed as being used as relays. For example, if one has to join two public nodes, one in North America and the other in Southeast Asia, he could setup a GlobalLatencyShift to avoid being used as a relay, and still enjoying convenient connection to both public nodes.

[ab2525]

I would also find this very useful in my applications, where I would like each component on an autonomous platform to be peered with each other over a consistent but higher latency local link within the platform itself while also maintaining multicast peering links to other nearby platform components. We have noticed scenarios where nearby wireless multicast nodes (50mbps) become preferred relays for traffic between wired components (100mbps). The ability to artifically spike the routing preference of an interfacepeer to become a peer of least resort only would be helpful.