Section 3.2.2: Clarify Use Case

[aboba]

Partial fix for #103

---

Preview | Diff

[youennf]

Questions about the use case:

Is RTP used both before and after fanout, or is RTP only used before fanout (but data channel after), or does it cover both?
During fanout, is it important to add almost no latency (hence forwarding packets) or is it fine to buffer enough packets to build a frame and forward the frame?
Maybe we can answer this by looking at what |pipe| and Dolby are doing.

[aboba]

Since this is for critical applications like auctions or betting, RTP is used before fanout (e.g. WHEP distribution), rather than a streaming protocol (e.g. HLS, LL-HLS) that transports CMAF. To remove latency, the fanout also uses RTP, rather than using CMAF over data channel to move them around. While unreliable/unordered data channel with application FEC could be used to transport the frames, the low-latency congestion control of RTP (e.g. gcc) will be preferred to data channel's NewReno.

[youennf]

In that case, I wonder whether we could make the use case more precise according your description.

N39 could tell it wants to do forwarding at the packet level (to not require assembling frames). Currently it is vague, maybe intentionally.

Another requirement might be that the forwarding UA needs to expose RTCP info like PLI or FIR that it receives from its end clients so that the web page can trigger some recovery mechanism like asking for a key frame to the media source, as quickly as possible. This really is the SFU in a browser use case.

Also, in parallel to forwarding, the user agent should be able to consume the incoming media for local playback. I am not sure how much a technical requirement that is. But this could somehow influence the API design so that consumption be easy to do with no/as little JS as possible.

[dontcallmedom-bot]

This issue was mentioned in WebRTC TPAC 2023 meeting – 12 September 2023 (Back to WebRTC use case issues)

[alvestrand]

The notes from TPAC were "Continue discussing with intent to merge".

[youennf]

Additional point: the use case is really about stringent latency and also ensuring that all peers render media at precisely the same time.
Does it mean that a forwarding peer should delay rendering so that end peers render at the same time as forwarding peers?

[jan-ivar]

I'd prefer use cases that do not prescribe a solution, so I'd prefer removing mention of RTP. I think we should trust the "less than 300ms" requirement to already cover this.

[alvestrand]

Since we seem to be having the debate about "but you should consider whether or not datachannels are an equally good solution" at every juncture where we propose extensions that assume the use of RTP, I wonder if it would make sense to add sub-use cases where one is "RTP is used for media transport", and one is "non-RTP protocols are used for media transport in some or all parts of the solution".

That would give us some clean identifiers to point to when saying "THIS extension is applicable to THAT use case".

But I think we should merge this PR and take that up later.

[aboba]

This use case is focused on non-datachannel approaches because:

• The requirement for low latency congestion control cannot be met by datachannel.
• Datachannel-related requirements are already covered in Section 3.1 File Sharing.

[dontcallmedom-bot]

This issue was discussed in WebRTC December 5 2023 meeting – 05 December 2023 (Low Latency Broadcast w/fanout PR #123)