If the same media stream is split between reliable and unreliable (I vs P), there are likely situations that will cause the reliable data to run slower than the unreliable. This can introduce additional jitter and/or result in the receiver dropping frames due to the slower transmission of reliable vs unreliable (same media flow). Coalescing these or introducing some level of additional pacing/CC to the unreliable data could help.
Multipath has the same challenge in that pacing will be lost between paths/connections.
Messages buffered, cached, ... and then replayed later would not preserve application pacing unless pacing rates were encoded in the stream. Maybe start point or start of stream should have pacing inter-packet-delay value. This value would only be used for egress transmissions to subscribers. Relay to relays could still transmit at their own rates, fast as possible.
As stated in https://datatracker.ietf.org/doc/html/rfc9002#name-pacing, https://datatracker.ietf.org/doc/html/rfc9221#name-congestion-control, and in other implementations... application packet pacing is important for subscribers/receivers.
If the same media stream is split between reliable and unreliable (I vs P), there are likely situations that will cause the reliable data to run slower than the unreliable. This can introduce additional jitter and/or result in the receiver dropping frames due to the slower transmission of reliable vs unreliable (same media flow). Coalescing these or introducing some level of additional pacing/CC to the unreliable data could help.
Multipath has the same challenge in that pacing will be lost between paths/connections.
Messages buffered, cached, ... and then replayed later would not preserve application pacing unless pacing rates were encoded in the stream. Maybe start point or start of stream should have pacing inter-packet-delay value. This value would only be used for egress transmissions to subscribers. Relay to relays could still transmit at their own rates, fast as possible.