Stop Paying for the Relay on Sessions That Never Needed It

Direct-first, relay-only-when-required is an operational rule, not a protocol preference. Defaulting to relay creates a permanent tax on latency and cost.

Relay infrastructure is useful. It is also easy to start treating as the default path instead of the exception.

Once that happens, two quiet costs appear.

The permanent tax

First, every session pays the relay tax even when a direct path was available. Latency goes up for no reason. Infrastructure cost goes up for no reason. The system becomes permanently more expensive than the actual network conditions required.

Second, the direct path atrophies. Because most traffic is already being relayed, the hard cases that truly need the relay and the easy cases that don’t are no longer distinguished in operations or in design. You lose the signal that tells you when the network is actually the problem versus when your own defaults are the problem.

Why the inverted default is common

Many platforms make relay the default because it is operationally easier for the vendor. Everything goes through infrastructure they control. Signaling is simpler. Debugging is centralized. The behavior is consistent.

That convenience is real. It is also a permanent tax on every customer session that could have been direct. The customer pays in latency and in infrastructure cost for a decision that optimized the vendor’s operations rather than the session’s actual requirements.

The cleaner rule

Prefer the direct path.
Bring the relay in only when the network refuses the direct path.
Make that decision per session, not per architecture.

This keeps easy networks cheap and fast. It keeps hard networks possible. It also preserves an honest signal: when relay usage rises, it is because the network conditions actually required it, not because the architecture never tried anything else.

Design rule: Default to peer-to-peer (or direct) connectivity. Escalate to relay infrastructure only for the sessions that cannot complete a direct path. Keep the decision local to the session so that easy networks stay cheap and fast, and hard networks remain possible.

This is not a purity argument about protocols. It is an argument about not paying for infrastructure you do not need, and about keeping the system honest about network reality.

You can say no to the tax. The refusal looks like this: design for direct first, escalate only when necessary, and keep the control path available either way. The result is lower average latency, lower average cost, and a clearer picture of when the network is actually hostile.

Most teams only notice the tax after the bill or the latency complaints arrive. The ones who refuse it early simply never start paying it.