Re: [media-and-entertainment] Use of WebRTC for media content distribution (#1)

> 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.).





-- 
GitHub Notification of comment by LPardue
Please view or discuss this issue at https://github.com/w3c/media-and-entertainment/issues/1#issuecomment-441156050 using your GitHub account

Received on Friday, 23 November 2018 04:50:37 UTC