Intent to Prototype: Multicast Receive API

[Holland, Jake]

Contact emails

jhol...@akamai.com, bq...@akamai.com

Explainer

https://github.com/GrumpyOldTroll/wicg-multicast-receiver-api/blob/master/explainer.md

Specification

 

TBD: API spec and design document (currently just entering Intent to Prototype).

IETF standards-track docs (all presently works in progress):

- draft-ietf-mboned-ambi
- draft-ietf-mboned-dorms

- draft-ietf-mboned-mnat
- draft-ietf-mboned-cbacc

(There will be integrated components prototyped in the browser feature based an appropriate subset of the above specs before origin trials begin.)

 

 

Summary

Subscribe to source-specific multicast IP channels and receive UDP payloads in web applications.

Blink component

Blink>Network

Motivation

Currently, Web application developers have no API for receiving multicast traffic from the network. All traffic for web applications thus requires a one-to-one connection with a remote device. Multicast IP provides a one-to-many data stream, and enables packet replication by the network, enabling efficient use of broadcast-capable physical media and reducing load on congested shared paths. Enabling Web applications to receive multicast would solve the receiver distribution problem that contributes to the current under-utilization of multicast on the internet.

 

This effort is coupled with a standardization effort in the MBONED working group at IETF and ongoing trials with multiple network operators to deploy a standardized approach for ISPs to ingest externally sourced multicast UDP traffic.

Initial public proposal

https://discourse.wicg.io/t/proposal-multicastreceiver-api/3939

TAG review

None

TAG review status

Pending

Risks

Interoperability and Compatibility

 

Feature adoption by browsers has an influence on whether the ISPs will deploy the capability to ingest and manage externally source multicast traffic.

 

Gecko: No signal

Edge: No signal

WebKit: No signal

Web developers: Some positive support on ietf mboned mailing list.  (Also importantly: some ISP support.)

Is this feature fully tested by web-platform-tests?

No

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5683808135282688

This intent message was generated by Chrome Platform Status.

 

[Reilly Grant]

Moving blink-dev@ to BCC and forwarding this to the net-dev@ mailing list.

This work proposes adding support for new network protocols to Chromium, which has security and privacy consequences. net-dev@ is the mailing list where this conversation should start. From private communications with the proposers of this new API their primary goal at this stage of development is to land an experimental implementation within Chromium in order to facilitate iteration and evaluation of the technology.

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/17EBCB31-7583-4BFB-AEEC-1FD17DFAC7B2%40akamai.com.