Use of WebRTC for media content distribution

[tidoust]

At the recent Media Web Symposium organized by Fraunhofer FOKUS, there was a demo of using WebRTC delivery for live streaming to reach sub-second latency. Use cases are around live streaming and include:

• the usual "Goal!" issue where your neighbours or social networks react to a goal before you see it
• live bets and live interactions during sport events.

The use of WebRTC to distribute media content looks like an interesting area to explore. I wonder: does that bring additional requirements on WebRTC?

For info, the WebRTC Working Group (whose new charter is currently under AC review) will soon have a face-to-face meeting focused on the next version of WebRTC. Media & Entertainment IG participants might be interested to look into the Use cases / requirements for raw data access functions thread as well.

[chrisn]

On a related note, we have been investigating WebRTC in a media production environment, and encountered issues with synchronisation between different WebRTC media streams. Here's a blog post that describes the use case in more detail.

[igarashi50]

Supporting the Encrypted Media Extensions API for WebRTC media content distribution could be considered as one of requirements from Media & Entertainment IG. WebRTC 1.0 media stream is secured by SRTCP (Secure Real-time Transport Protocol) but it has no aspect of content protection.

[tidoust]

Supporting the Encrypted Media Extensions API for WebRTC media content distribution could be considered as one of requirements from Media & Entertainment IG. WebRTC 1.0 media stream is secured by SRTCP (Secure Real-time Transport Protocol) but it has no aspect of content protection.

Interestingly, end-to-end encryption scenarios were discussed by the WebRTC WG last week during their F2F. See summary of e2e encryption discussions. Content protection for media distribution would be use case 3 in that summary.

Note the "It is unclear whether there is sufficient interest in that area" in that email, which suggests that the work won't happen unless people weigh in (the Media & Entertainment IG could do that) and contribute (at a per company level, not much the IG can do there).

Solution-wise, the starting point suggested in the email would use the Identity provider framework (which will soon move to a separate spec, partly because it is not yet supported across browsers) and isolated media streams coupled with a yet-to-define double encryption mechanism.

[tidoust]

The topic was discussed in a recent call of the Media & Entertainment Interest Group:

• Minutes of the call
• Intro slides from John
• Technical slides from Peter

Peter mentioned possible alternatives that could use WebRTC technologies to distribute content. One of them would be using QUIC transport coupled with MSE. This would require pushing the QUIC API for WebRTC spec forward. The WebRTC Working Group is undecided for now on whether to adopt the spec within the Working Group and looking for concrete use cases.

The Interest Group could perhaps help by voicing its support for this work, by pointing out media use cases that would benefit from such an API. Would someone be willing to take the lead on drafting such a message to the WebRTC WG?

[tidoust]

I believe no one stepped up to draft a message targeted at the WebRTC WG about the QUIC API for WebRTC specification. The WebRTC WG is now officially pondering whether to adopt the specification as a WG deliverable. See the related call for adoption: https://lists.w3.org/Archives/Public/public-webrtc/2018Nov/0032.html

Notably:

We are seeking both statements of support and statements of opposition. The chairs will tally the responses and attempt to draw a conclusion.

Please state your opinion to the**list on or before Wednesday, November 28.

I encourage interested companies who also participate in the WebRTC WG to state their opinion on the public-webrtc@w3.org mailing-list. An expression of support on behalf of the Media & Entertainment IG still seems doable, but someone would need to prepare it right away given the deadline for the call...

[gmandyam]

Based on my experience with ATSC 3.0, I have the following concerns:

a) QUIC is not IP multicast-compatible (yet). Although there are early stage proposals such as [1], they have been shown to significantly degrade IP-multicast performance versus the standardized ATSC transport protocol ROUTE (see slide 5 of presentation in [2]).

b) QUIC does not have any support for FEC. This is problematic for the ATSC file repair solution.

Note that ATSC 3.0 is already compatible with W3C specifications such as MSE and EME, so adoption of QUIC would not be of benefit from that perspective.

I would say overall there could be promise for WebRTC-QUIC for certain video distribution scenarios for live media, but the benefits are not clear for OTA broadcast of live media.

[1] https://datatracker.ietf.org/doc/draft-pardue-quic-http-mcast/ [2] https://mailarchive.ietf.org/arch/msg/ggie/2iCARGOZ7-5TDsDEFiGo2zu2StI

[rjb1000]

QUIC is not IP multicast-compatible (yet). Although there are early stage proposals such as [1], they have been shown to significantly degrade IP-multicast performance versus the standardized ATSC transport protocol ROUTE (see slide 5 of presentation in [2]).

I assume you're referring to this claim on your slide 5:

ROUTE is more efficient than QUIC

• About 10% less overhead per packet

In a recent comparison of media transport protocols done by the DVB Project we measured that the average protocol overhead of ROUTE was ~20 bytes per packet and the average protocol overhead of multicast QUIC was ~22 bytes per packet, although because QUIC uses variable-length encoding for some fields, it can be lower than this.

I agree that these bald numbers suggest that the overhead of QUIC is ~10% higher than ROUTE. However, a difference of two bytes in a 1500-byte packet is only a 0.13% real world difference. To describe this as a significant degradation in IP multicast performance would be overegging the pudding.

[LPardue]

The tests @rjb1000 mentions were based on a wire format that requires always an 8 byte field for connection ID. A recent change to QUIC [1] now allows down to a 1-byte field. This would change the previous results to be:

• 20 bytes ROUTE
• 15 bytes QUIC

By the previous claim methodology, you could say that QUIC is now 25% better than ROUTE. It's the clear winner, right?

1 - https://github.com/quicwg/base-drafts/issues/1570

[gmandyam]

The tests @rjb1000 mentions were based on a wire format that requires always an 8 byte field for connection ID. A recent change to QUIC [1] now allows down to a 1-byte field. ...

By the previous claim methodology, you could say that QUIC is now 25% better than ROUTE. It's the clear winner, right?

Wrong.

a) ROUTE supports all services, not just media. This includes ESG, DRM entitlements, NRT data, application packages, and application related signaling. The ROUTE headers have clear identification of these different types of information. Connection ID does not include such identifiers and therefore is thoroughly inadequate for the purpose.

b) Any overhead calculation has to include FEC. The ATSC has concluded that FEC is absolutely necessary for OTA transmission to account for (wireless) channel losses. The DVB project did not allow for FEC to be included in the calculation in part because of the lack of support in QUIC. That does not eliminate the absolute need for FEC in a wireless broadcast system.

Note: Ironically, WebRTC already supports FEC for RTP transport in the form of FLEX FEC (https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-11). Seems that QUIC is a step backwards in this regards.

c) Any broadcast transport must have clear identification of the necessary information included in a RAP (Random Access Point), in order to allow for fast channel acquisition. This includes: broadcaster application for the channel, initialization segment, Connection ID does not include this information (as far as I can tell, and therefore channel acquisition will not be possible in an ATSC system.

Note also that ROUTE is not a fiction - it has already been standardized and deployed. Perhaps QUIC may have a place for unicast transport of live media, but it is definitely a stretch to claim that is it suitable in its current state for OTA broadcast.

[LPardue]

Note also that ROUTE is not a fiction - it has already been standardized and deployed. Perhaps QUIC may have a place for unicast transport of live media, but it is definitely a stretch to claim that is it suitable in its current state for OTA broadcast.

I fail to see how concerns of OTA broadcast systems relate to actual IP networks. ROUTE, and the way that ATSC profiles it, seems like a fine fit for OTA broadcast. However, things are much different on the real Internet. Do you have any case studies of ROUTE deployments on the Internet?

Any overhead calculation has to include FEC. The ATSC has concluded that FEC is absolutely necessary for OTA transmission to account for (wireless) channel losses. The DVB project did not allow for FEC to be included in the calculation in part because of the lack of support in QUIC. That does not eliminate the absolute need for FEC in a wireless broadcast system.

I was part of the DVB analysis and disagree with your statement. The conclusions of ATSC are not applicable to heterogenous IP networks. Operators of IP multicast networks have ample evidence, from actual deployments running over many years, that FEC is not a silver bullet. The DVB mABR architecture, in its wisdom, provides flexible deployment models that allow operators agility in the respect of FEC. To that goal, FEC was absolutely considered in the analysis stage, it was left to candidate proponents to determine a fair and equivalent way to compare their options. This area is difficult. QUIC provided no blocker to that activity.

You've quoted a statistic from a slide that has no source, evidence or methodology. On that basis I've provided a counter point based on work undertaken in the DVB project. If you think there is other evidence that shows QUIC has significant degradation of IP-multicast performance versus the standardized ATSC transport protocol ROUTE I'd love to see it. Ideally such evidence has been gathered on an actual IP network. Without such, my assumption is that the 10% overhead comes from the DVB like-for-like protocol analysis. This boils down to difference in the size and shape of transport-layer packets. The previous data is stale now that QUIC can optimise in that area.

Note: Ironically, WebRTC already supports FEC for RTP transport in the form of FLEX FEC (https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-11). Seems that QUIC is a step backwards in this regards.

There are some groups interested in replacing the UDP and SCTP aspects of WebRTC for QUIC. It becomes the transport layer for RTP that would allow you to continue using such a FEC scheme.

a) ROUTE supports all services, not just media. This includes ESG, DRM entitlements, NRT data, application packages, and application related signaling. The ROUTE headers have clear identification of these different types of information. Connection ID does not include such identifiers and therefore is thoroughly inadequate for the purpose.

c) Any broadcast transport must have clear identification of the necessary information included in a RAP (Random Access Point), in order to allow for fast channel acquisition. This includes: broadcaster application for the channel, initialization segment, Connection ID does not include this information (as far as I can tell, and therefore channel acquisition will not be possible in an ATSC system.

See above, no claim is made that connection ID fits this purpose. Some of the concerns you state are not relevant to a systems that provide both unicast and multicast modes of delivery (in some form of combination that is a deployment/implementation concern.). Multicast transport solutions considered in the DVB mABR group allow for the transmission of any type of object. For the case of QUIC, the information you describe would be articulated inside the QUIC packet payload. Other options rely on manifests or file description tables. Either approach would permit a multicast-only mode of delivery, assuming the client has appropriate bootstrapping options (common discovery multicast group etc.).

[gmandyam]

I fail to see how concerns of OTA broadcast systems relate to actual IP networks. ROUTE, and the way that ATSC profiles it, seems like a fine fit for OTA broadcast. However, things are much different on the real Internet. Do you have any case studies of ROUTE deployments on the Internet?

ATSC is an IP Multicast system. What do you consider the "real Internet"? Is ATSC a fake system?

I was part of the DVB analysis and disagree with your statement. The conclusions of ATSC are not applicable to heterogenous IP networks.

ATSC is heterogenous. Unicast transport is fully integrated into ATSC along with IP multicast. Your premise is not accurate.

There are some groups interested in replacing the UDP and SCTP aspects of WebRTC for QUIC. It becomes the transport layer for RTP that would allow you to continue using such a FEC scheme.

If your organization (or anyone else) is planning to adapt FLEX FEC for QUIC then that would be of interest to many interested parties, not just myself.

Some of the concerns you state are not relevant to a systems that provide both unicast and multicast modes of delivery (in some form of combination that is a deployment/implementation concern.).

Again - ATSC does porivde both unicast and multicast modes of delivery. Please familiarize yourself with the specification before making such statements.

[LPardue]

ATSC is an IP Multicast system. What do you consider the "real Internet"? Is ATSC a fake system?

I consider the real internet to be a network of networks that permit me to use TCP/IP or UDP/IP to access remote systems.

IP multicast depends on packet switching. Most importantly for IP multicast is the correct forwarding of packets to an interested subscriber, generally achieved using Layer 3 routers or Layer 2 switches (with snooping) in path between sender and receiver. For better or worse, the internet is heterogenous in so far as different access network technologies, operator domains and many other factors. Such IP networks may carry unicast and multicast traffic, which can interfere with each other with negative consequence. To this end there are several approaches to deployment, for example, some IP multicast deployments prevent interdomain multicast (so-called multicast islands), some will segment the unicast and multicast networks (i.e. seperate VLANs).

Please explain how OTA broadcast delivery of IP packets satisfies IP multicast expectations.

Can you point me towards an ATSC-compliant ROUTE transport endpoint on a publically routable IP address such that I can test out without needing to be in the OTA broadcast coverage area?

I was part of the DVB analysis and disagree with your statement. The conclusions of ATSC are not applicable to heterogenous IP networks.

ATSC is heterogenous. Unicast transport is fully integrated into ATSC along with IP multicast. Your premise is not accurate.

"Heterogenous networks" i.e. networks composed of multiple: vendors, operators, physical layer technologies etc. ATSC seems not to support heterogenous networks if I can't access it using one of the many IP standards-compliant clients at my disposal.

Again - ATSC does porivde both unicast and multicast modes of delivery. Please familiarize yourself with the specification before making such statements.

I know ATSC provides both. What I've seen and heard is that the "multicast mode" is independent of the unicast mode. This is distinct from DVB mABR which relies of the combination of modes e.g. unicast IP is used for service discovery and fast-channel change, multicast IP is used for bulk transfer of ABR resources such as segments of audio, video or subtitle tracks. DVB mABR relies on an access network route into the internet.

So to your earlier point that "Any broadcast transport must have clear identification of the necessary information included in a RAP (Random Access Point), in order to allow for fast channel acquisition. This includes: broadcaster application for the channel, initialization segment" the DVB design avoids these design constraints - such information is discoverable via unicast IP access. If that is also the case for ATSC, then your earlier comment is invalid. Which is the case?

[LPardue]

And since I failed to make the obvious point. The discussion was couched in the applicability of FEC. You said that FEC is absolutely necessary to the homogenous OTA broadcast network. The Internet operates over many varied IP networks (cable, satellite, DSL, cellular, WiFi) across widely different environmental, economic and political domains. FEC is not unitalerally required over all of the permutations of these, which is why my position, that ATSC conclusions in this regard are not applicable, still stands. This position is the same as that adopted by the DVB mABR taskforce and is reflected in their architectural design and transport protocol selection.

[chrisn]

Leaving the relative merits of different protocols aside, I'd like to refer us back to the question put by Francois earlier, specifically whether Interest Group members want to give input to the WebRTC WG regarding adoption of the QUIC API for WebRTC specification as a deliverable. I encourage IG members to give input to the WebRTC discussion thread here.

[gmandyam]

@chrisn

Understood. Note that my original comment was based on experiences with ATSC 3.0 transport, and I was commenting as to whether QUIC can be used in the context of ATSC's implementation multicast IP for OTA. I believe the same reasoning would apply to LTE eMBMS and its 5G MBMS. QUIC cannot be a candidate for ATSC IP Multicast transport in its current form, and the WebRTC WG could look into the issues I have already raised above:

a) Lack of FEC support, which the ATSC has determined is required for the wireless channel conditions that will be encountered by ATSC receivers. Note that this was raised at the last TPAC WG meetings, and I expect that the issue of FEC support in QUIC will be revisited in the near future.

b) Potential protocol overhead issues. Obviously based on the back-and-forth above there are differing views on this topic. I believe "overhead" must include FEC-related overhead such as file repair, protocol headers that allow for identification of the type of media being sent OTA, and necessary protocol support for critical broadcast use cases such as fast channel acquisition.

c) I mentioned EME in my original comment, but to expand on it - any ATSC-compliant transport mechanism must have full support for CENC. This includes maintaining freshness of the entitlement and supporting all subscription scenarios required by ATSC broadcasters. This is not just important for ATSC-compliant receivers but also for in-home content redistribution. Maybe QUIC has a means of supporting EME - I haven't seen it yet.

Note that ATSC requires that all services work regardless of whether ATSC receivers have enabled broadband access or not. In fact, several broadcasters in markets such as Asia have told us that they have subscribers that do not have any kind of broadband access. Therefore, QUIC being a suitable replacement for HTTP 1.1 and 2.0 over unicast networks is of limited value in many ATSC deployments.

[LPardue]

The IETF standard form of QUIC is not a replacement for HTTP/1.1 or HTTP/2. It is a secure, mulitplexed transport that is a substitute for TCP+TLS, or maybe be a suitable substitute for SCTP+DTLS. QUICv1 will not offer unreliable stream delivery, multipath or FEC as standard. I look forward to the continued evolution of a widely adopted transport protocol at internet-scale.

As to the WebRTC proposal, there is merit in supporting alternative transport protocols that allow the flexible carriage of application layer protocols. There is merit is exposing capability like this to the web platform. However, I think the proposals of QUIC API for WebRTC need further refinement to interface and implementation. The discussions at the IETF 103 TAPS session (minutes) were useful for context.

[tidoust]

Status update on the QUIC API for Peer-to-peer Connections: the WebRTC Working Group did not adopt the specification as a normative deliverable. The WebRTC Working Group may adopt the specification later on depending on progress on the spec... and, as usual, on feedback and interest from would-be users.

In the meantime, the specification is under development in the ORTC Community Group. It builds on top of WebTransport, whose progress is tracked in #25.