"Connection.Stats reads zero on a local two-instance session"

You read the engine's connection telemetry on a local two-instance session (an editor host plus a -joinlocal peer) and every field is zero. Networking.HostStats shows outBps=0 inBps=0 fps=0 peakOutBps=0. Every per-connection Connection.Stats line shows ping=0 outBps=0 inBps=0 sendRateBps=0 quality=0.00.

The zeros appear on both peers, every sample, while a damage-sync layer on the same session is demonstrably moving tens of thousands of bytes a second. Ping and ConnectionQuality cannot both be genuinely zero while the session actively sends data, so this is a telemetry gap, not an idle link.

Networking.HostStats and Connection.Stats do not report on the local/loopback path. Sampling was repeated four times across two live sessions, mid-round and at a scene peak, and read zero every time on both peers. A bandwidth instrument that latches its peak off these fields (sampling them once a second) latches zero for the same reason: the engine instrument gives nothing on this path, so there is no value to latch.

Do not rely on Connection.Stats for bandwidth on a local or loopback multiplayer session. Count bytes yourself at the application layer:

1. Add a per-message byte counter at the point your own code encodes and sends a payload.
2. Keep a per-peer peak latch on that counter.
3. Compare the counted total against your budgeted ceiling. This measurement was cross-checked against a planned bandwidth ceiling this way.

Your own encode-and-send point sees every payload before it reaches the transport, so a counter there measures real traffic that the engine instrument does not surface on loopback. The application-layer count does not depend on whichever engine path fails to populate Connection.Stats.

Scope the caveat to loopback. Whether the same gap extends to a real non-loopback two-machine session is unconfirmed, so treat a Connection.Stats read on a real two-machine session as a separate question and confirm it there before trusting the numbers.