Routing Like a Slime Mold

Part of a series on building Vinver, solo, from the manifold to the microcontroller. I keep calling the Fabric's routing bio-inspired and never explaining it. Here it is: how a request finds its way across the mesh without a routing table.

A traditional network routes by configuration. Routing tables, load-balancer rules, failover scripts, health checks, blue-green cutovers: a long list of decisions about which path a request should take, made by humans or by a control plane, plus an even longer list of machinery to cope with the fact that those decisions go stale the instant the topology changes. A node dies, a link saturates, a region drops, and every static assumption about where to send things has to be detected and corrected by something watching from outside.

The Fabric does not configure its routes. It grows them, the way a slime mold grows tubes, and lets the ones that stop being useful rot.

The organism that builds networks without a brain

Physarum polycephalum is a single-celled slime mold with no brain and no central anything. It solves mazes. It builds transport networks between food sources that are close to optimal in length, efficiency, and fault tolerance, by a mechanism almost insultingly simple: it thickens the tubes that carry a lot of flow and lets the tubes that carry little flow wither. Tero and colleagues famously laid oat flakes out in the shape of the cities around Tokyo and let the mold connect them; what it grew was comparable to the actual Tokyo rail network, which a great deal of human engineering had produced. There was no engineer in the petri dish, and no plan. There was a local rule applied everywhere: reinforce what flows, abandon what does not.

That local rule is a routing algorithm, and it is the one the Fabric uses.

Reinforce what flows, abandon what does not

In the Fabric, every route is a tube with a single number attached: its conductivity. The conductivity follows the slime mold's own equation, a balance between reinforcement by flow and steady decay:

$$\frac{dD}{dt} = f(|Q|) - \alpha D$$

A tube's conductivity $D$ rises with the flow $|Q|$ it successfully carries and falls at a steady rate $\alpha$ on every tick whether it is used or not. Traffic that succeeds along a tube raises its conductivity; an idle tube loses a small fraction of its conductivity regardless. A request that completes strengthens the path it took. A path that stops carrying traffic fades on its own. A neighbor that drops off the network has its tubes cut.

The consequence is that the network learns its own routing table from the traffic that actually flows through it, and continuously forgets the parts that stopped working, with no node in charge of the decision. Routes get better with use and disappear with disuse, exactly as in the organism.

One decaying number replaces the resilience stack

This is where the slime mold earns its place, because of what it makes unnecessary. The address-free Fabric from the earlier posts has a problem any such system has: when many peers can serve the same intent, something has to choose which one, and a configured load balancer is a static answer to a question whose answer changes by the second. The conductivities are not static. Traffic flows to the strongest tube, which is the load balancer, and a failing node's tubes lose conductivity until traffic simply flows around them, which is the circuit breaker, and neither required a configuration file or a health-check daemon or a human. A node that goes bad is not detected and removed. It is starved, the way the mold starves a tube to a food source that ran out.

The paper that argued for this fabric listed circuit breakers, retry policies, failover configs, and health checks as the machinery a brittle, location-based network needs to survive change. Most of that machinery collapses, here, into one decaying number per route.

When there is no tube yet: fall back to geometry

A reinforced tube only exists once traffic has worn the path. For a cold route, one the network has never carried, there is nothing to follow, and this is where the second borrowed idea comes in.

When the router has no tube for an intent, it falls back to routing by pure geometry: every node has a coordinate in a hyperbolic space, and the router forwards greedily toward the coordinate of the target. Hyperbolic space has a property that makes this work where it would fail in flat space: it embeds hierarchies and tree-like structures with almost no distortion, so a node can make a good forwarding decision toward a distant target using only its neighbors' coordinates and no global map. Greedy geometric routing in hyperbolic space is a known result; the Fabric uses it as the always-available substrate beneath the learned tubes.

So routing has two layers, and both are taken from nature rather than configured. The slime-mold tubes carry the traffic the network has learned to carry, fast and reinforced. The hyperbolic geometry carries everything else, the cold paths and the first request down any route, with no learning required. A request rides a worn tube where one exists and falls through to the geometry where one does not, and over time the geometry's good paths wear into tubes.

The honest part

None of this is magic, and a few things are worth saying plainly. A brand-new network has no tubes at all and routes entirely on the hyperbolic fallback until traffic begins to wear paths in; convergence is a function of traffic, not of an instant. The decay rate and the threshold below which a tube is considered dead are parameters, tuned, not handed down by nature. Nodes gossip their strongest tubes to their neighbors, which is what keeps a purely local reinforcement rule from trapping the network in a locally good path while a better one goes undiscovered: the gossip spreads knowledge of strong routes a node never traveled itself, so the structure converges toward globally good paths and not just locally reinforced ones. And this is a routing layer, not a delivery guarantee: when a request must not be lost, the guarantee comes from the reliability tier on top, not from the slime mold underneath.

And the credit, as always: the reinforcement-and-decay model is the biology of Physarum as formalized by Tero and colleagues, and greedy routing on hyperbolic coordinates rests on a line of geometric-routing results. What is mine is the wiring, using the slime mold's rule and the hyperbolic geometry together as the routing layer of an address-free fabric, so that the network finds its own way.

Why the Fabric is tissue, not cloud

The brand language for this system calls the Fabric a tissue rather than a cloud, and routing is the most literal place that holds. A cloud is configured: you tell it where things are and it does what you said until you tell it otherwise. A tissue is grown: it reinforces what is used, lets the unused atrophy, heals around damage, and arrives at a good structure without anyone designing it. A network that routes by thickening its busy paths and starving its dead ones is doing, in software, what a slime mold does in a petri dish and what a body does with the vessels that carry its blood.

That is the whole ambition of this layer. Not a smarter control plane, but no control plane: a network that finds its way the way living things do, by flow and decay, with geometry underneath for everywhere it has not been yet.

If you build networks, distributed systems, or anything that has to route without a center, or you're hiring someone who wired a slime mold and a hyperbolic space into a working mesh, I want to hear from you. [email protected]