Intent to Prototype: Multicast Receive API

341 views
Skip to first unread message

Holland, Jake

unread,
Feb 4, 2021, 4:31:14 PMFeb 4
to blin...@chromium.org

Contact emails

jhol...@akamai.combq...@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

unread,
Mar 11, 2021, 8:04:44 PMMar 11
to Holland, Jake, Qiu, Binqiang, net-dev
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.
Reply all
Reply to author
Forward
0 new messages