Video now opts into an unreliable media channel and audio states Reliable
explicitly, rather than both inheriting a hardcoded default.
`rudp_media_transport_options_follow_low_latency_profile` has asserted
Unreliable since it was written and has never passed. It was not aspirational:
CultNet hardcoded the media channel Reliable in both the profile builder and the
send path, so Muninn had no way to express the intent. Muninn signalled it the
only way available, by passing no reliable expiry — meaning "unreliable, so
expiry is moot" — and got reliable delivery instead.
Measured on Raven through `cultnet-impair`, 848-byte packets at 12 Mbps, which
is Muninn's real shape:
profile mode delivered
clean unreliable 100.00%
clean reliable 69.10%
loss 1% unreliable 98.95%
loss 1% reliable 72.00%
loss 3% unreliable 96.73%
loss 3% reliable 73.30%
The reliable channel loses 31% of a clean 12 Mbps offer, and its delivery barely
moves as loss rises, so loss was never the binding constraint — it cannot carry
this rate at all. The unreliable channel holds every packet on a clean link and
then degrades by roughly the loss injected, which is what a media lane should
do. Reverse traffic differs by three orders of magnitude: 43 bytes of
acknowledgement against ~135,000.
An earlier draft of this message argued the defect was retransmission amplifying
load under loss. The measurement does not support that mechanism. The conclusion
survives it; the reasoning did not.
Audio passes Reliable explicitly and does not change. That pairing is still
wrong — 3 Mbps of uncompressed PCM does not belong on a reliable channel — but
that is the Opus change, and inheriting the right value silently is what
produced this bug.
Requires CultLib's `claude/media-channel-delivery`. The dependency pin still
points at c13b6ba and must be moved before this builds from a clean checkout.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
24d51015f8