Intermediates

[kixelated]

This is kind of awkward to phrase, but it's something that gets overlooked quite often.

There are use-cases that are fully glass-to-glass. A broadcaster can use WebRTC to send media to one or more peers without involving an intermediary. However, I would say that most media is transmitted via a pipeline involving multiple processing and fanout steps.

It's important that the protocol is designed with intermediates in mind. This means minimal processing and preserving any latency strategy throughout the pipeline. The glue between contribution and distribution needs to be factored in.

SRT is an example of a protocol that gets this wrong. It uses a fixed-size latency buffer (I hope it's been changed by now), meaning each SRT hop adds a fixed amount of latency. This makes it a poor syndication protocol because these buffers are additive within a video pipeline. And it also makes SRT less ideal in general, as just using this protocol within a pipeline (even just for contribution) incurs this fixed latency.

This is very close to the syndication use-case but it might be better phrased as a requirement.

[acbegen]

I think introducing a fixed delay is not the right way of describing the issue. The additional delay due to an intermediary could be fixed but also quite small compared to the e2e delay and in that case, maybe it is not that critical anymore. Intermediaries are a fact of life and new ones will keep coming up, so we just need to know when they start being a "problem" so maybe defining some limits/ranges might help here.

[SpencerDawkins]

@acbegen, I roughly agree with you on this. I'm planning to add an issue specifically for the meaning of latency, to work on.

[SpencerDawkins]

I'm leaving this discussion for reference during work on requirements, now that MOQ has been chartered.

[kixelated]

I tried to tackle this in the motivation section of the latest warp draft.

[SpencerDawkins]

@fiestajetsam and @SpencerDawkins discussed this issue.

The motivation for intermediates ("relays") should probably be in the architecture draft.

We should limit ourselves to requirements for relays in this draft.

We are held up by lack of discussion/consensus on architecture (and terminology, but that's nothing new).