Re: [MBONED] [blink-dev] Intent to Prototype: Multicast Receive API

[Gyan Mishra <[e-mail]>]

Hi Jake

Am glad we have connected on this topic.

Thank you for all your feedback and I will try to connect to some of the
other threads and monitor the progress of this critical project as this
same issue am sure plagues other operators worldwide.  Also any help I can
provide on this critical project as well as you can use our use case which
I think applies to any company.

So our major use case for this is for distribution of multicast SSM  feed
for enterprise webcasts to all Verizon Entities over our corporate intranet
which  spans the globe to 150k employees.

We have been using Ramp for video delivery ever since we started using
Chrome browser on windows and MAC for office productivity which does not
support NPAPI plugin so cannot play multicast natively.

https://www.rampecdn.com/

With Ramp the multicast source sender ingests the HLS or Dash unicast feed
encapsulates in UDP RTP header and sources the multicast distribution over
the network worldwide.  The Ramp receiver apps are loaded on all 150k
employees desktops which removes the outer header unpackages and plays out
locally over localhost signed certificate over 127.0.0.1 and the HLS or
Dash steam plays natively now on the browser.

The major problem we have had with this solution is the Ramp receiver on
each desktop has to be pushed out every time there is a software upgrade
and recently we have had security issue with new chrome flags allowing
playing locally as each host now acts as local web server - to prevent
malware attacks and thus the knob cannot be enabled.  So we are still
working with Ramp on a workaround as well as alternatives such as the best
of course would be Chrome playing multicast natively.

So this is a major problem and we are eagerly waiting to see when Chrome
will support playing multicast natively.

Responses in-line Gyan2>

Kind Regards

Gyan

On Wed, Feb 23, 2022 at 12:59 PM Holland, Jake <[e-mail]> wrote:

> Hi Gyan,
>
>
>
> > Have you looked at WebRTC.
>
>
>
> As I understand it (not very deeply), WebRTC does not support multicast
> since it requires the use of SRTP.
>
> > Gyan>  Did google say why they are not interested?
>
> In the net-dev thread you linked, I believe they indicated it needs good
> consensus on the security implications before they’d consider accepting it.
>
> Gyan2> I see so sounds like we are close but have a gap with security
>
> We tried to kick off that discussion at 112, but nobody has responded with
> further discussion yet except for the comments during the secdispatch
> presentation.  But the discussion was dispatched to the msec list:
>
> https://mailarchive.ietf.org/arch/msg/msec/FYx5GsAtAyI3pypPIlJ_s3vtiwc/
>
>  Gyan> Thank you I will review the ML
>
> The other thing they said in the net-dev thread you linked was they don’t
> want it to be part of their maintenance burden even if it’s cleaned up.  I
> expect this would change if the multicast traffic were likely to be
> delivered, which is why (as described in the msec message) we’re shifting
> focus to start getting some deployment of non-browser multicast to
> establish some places where delivery does actually work.
>
> Gyan2>  So you think there is hope that Google will get on board once
> security issues clean up is resolved if we are able to prove multicast
> delivery with non browser deployments then Google may get back on board.
>
> They also indicated in the thread that they do not have a goal of making
> multicast delivery more attractive to ISPs by adding support in the
> browser.  I hope to change their minds eventually, but that’s still where
> it stands today.
>
>  Gyan2>  Interesting as I wonder if they have unicast video working I
> guess and ISPs have plenty of bandwidth although with beyond 4k and VR as
> that blossoms with 5G network services Slicing as operators continue to
> build out OTN optical network from  400G to 800G and beyond its a moving
> target and multicast is the end all be all bandwidth management savior do
> hopefully they come around.
>
> > Gyan>  Alternative that might get adopted by Google so they can
> integrate natively into the browser?
>
>
>
> Yes.  The rough approach I’m starting is also outlined in the msec thread
> linked above, but I don’t have a draft written yet.  Not certain whether
> it’ll be out for 113, but maybe.  Probably will still be working on it
> though and won’t have a presentation about it yet.
>
> Gyan2> Excellent work by you and the MBONE and PIM and all WGs involved in
> this critical project.
>
> HTH, and I’m glad you’re interested.  I’d love to know more about what
> kind of use cases you’re looking into.
>
>  Gyan2>   Maybe we can get together and go over the use case details.
> Also our use case am sure exists for all corporations trying to use
> multicast for video delivery using Chrome.
>
> -Jake
>
>
>
> *From: *Gyan Mishra <[e-mail]>
> *Date: *Wed,2022-02-23 at 8:49 AM
> *To: *"Holland, Jake" <[e-mail]>
> *Cc: *MBONED WG <[e-mail]>, Toerless Eckert <[e-mail]>
> *Subject: *Re: [blink-dev] Intent to Prototype: Multicast Receive API
>
>
>
> Jake
>
>
>
> Have you looked at WebRTC.
>
>
>
> I believe there is a chrome plugin but not sure if the plug-in allows
> multicast to play natively.  I wonder if that plug-in could be tweaked to
> get multicast to work as well as an alternative.
>
>
>
> Thanks
>
>
>
> Gyan
>
>
>
> On Wed, Feb 23, 2022 at 11:46 AM Gyan Mishra <[e-mail]>
> wrote:
>
> Excellent!
>
>
>
> Questions in-line
>
>
>
> Thanks
>
>
>
> Gyan
>
>
>
> On Wed, Feb 23, 2022 at 11:04 AM Holland, Jake <[e-mail]>
> wrote:
>
> Hi Gyan,
>
>
>
> it’s not currently expected to make it into the upstream, as Google said
> they’re not interested.  However, an implementation is available for
> experimenting with.
>
>  Gyan>  Did google say why they are not interested?
>
> I’ve been maintaining a fork that implements the proposed api (but does
> not have the authentication functionality implemented):
>
> https://github.com/GrumpyOldTroll/chromium_fork
> <https://urldefense.com/v3/__https:/github.com/GrumpyOldTroll/chromium_fork__;!!GjvTz_vk!FBIPYCQrN0By_vJcKO_V9-zzmIyeuhaXJE1vlu09N1VmnYDsPvSJ-lVRAzhk2S4$>
>
>  Gyan>  That’s great.   I will try testing it out
>
> I’ve been keeping it approximately up to date with chromium releases.
> There’s .deb binaries linked from the repo that you can experiment with,
> and there’s an example page that uses the api at
> https://grumpyoldtroll.github.io/wicg-multicast-receiver-api/demo-multicast-receive-api.html
> <https://urldefense.com/v3/__https:/grumpyoldtroll.github.io/wicg-multicast-receiver-api/demo-multicast-receive-api.html__;!!GjvTz_vk!FBIPYCQrN0By_vJcKO_V9-zzmIyeuhaXJE1vlu09N1VmnYDsPvSJ-lVR0cZe9DQ$>
> .
>
>  Gyan> Excellent
>
> I’m looking into alternatives that might have a better chance at moving
> forward and getting adoption based on the feedback we got so far, and as
> soon as one of those is operational I’ll probably stop maintaining that
> fork and put up a note to the new thing, but for now that’s what I’ve got.
>
> Gyan>  Alternative that might get adopted by Google so they can integrate
> natively into the browser?
>
>
>
>
>
> The primary discussion venue for this is the W3C multicast community
> group.  You can get a rough idea of what we’ve been thinking from the
> meeting logs and videos:
>
> https://github.com/w3c/multicast-cg/tree/main/meetings
> <https://urldefense.com/v3/__https:/github.com/w3c/multicast-cg/tree/main/meetings__;!!GjvTz_vk!FBIPYCQrN0By_vJcKO_V9-zzmIyeuhaXJE1vlu09N1VmnYDsPvSJ-lVRUVb7XEU$>
>
>  Gyan> Thanks
>
> HTH,
>
> Jake
>
>
>
> *From: *Gyan Mishra <[e-mail]>
> *Date: *Tue,2022-02-22 at 8:15 PM
> *To: *"Holland, Jake" <[e-mail]>, MBONED WG <[e-mail]>,
> Toerless Eckert <[e-mail]>
> *Subject: *Re: [blink-dev] Intent to Prototype: Multicast Receive API
>
>
>
>
>
> Dear Jake, Toerless and MBONED
>
>
>
> Does anyone know the status of this project to allow Chrome browser to
> play multicast natively.
>
>
>
> The issue was that NPAPI plug-in is not supported and so multicast cannot
> play natively.
>
>
>
> So some dev work was needed to get this fixed and working for MBONE
> community at large.
>
>
>
> https://groups.google.com/a/chromium.org/g/net-dev/c/TjbMyPKuRHs?pli=1
> <https://urldefense.com/v3/__https:/groups.google.com/a/chromium.org/g/net-dev/c/TjbMyPKuRHs?pli=1__;!!GjvTz_vk!DhNFIJSjLlBTt2ff1aIHLB55Hz9D_vR8WG3b2uPJ37dr9hNIU4dghgNFRnRSVq8$>
>
>
>
>
>
> Copy/paste from link above.
>
>
>
> 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 | [e-mail] | Google Chrome
> <https://urldefense.com/v3/__https:/www.google.com/chrome__;!!GjvTz_vk!DhNFIJSjLlBTt2ff1aIHLB55Hz9D_vR8WG3b2uPJ37dr9hNIU4dghgNFJ2r6e6c$>
>
>
>
>
>
> On Thu, Feb 4, 2021 at 1:31 PM 'Holland, Jake' via blink-dev <
> [e-mail]> wrote:
>
> Contact emails
>
> [e-mail], [e-mail]
>
> Explainer
>
>
>
> https://github.com/GrumpyOldTroll/wicg-multicast-receiver-api/blob/master/explainer.md
> <https://urldefense.com/v3/__https:/github.com/GrumpyOldTroll/wicg-multicast-receiver-api/blob/master/explainer.md__;!!GjvTz_vk!DhNFIJSjLlBTt2ff1aIHLB55Hz9D_vR8WG3b2uPJ37dr9hNIU4dghgNFmW_6mkM$>
>
> 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
> <https://urldefense.com/v3/__http:/draft-ietf-mboned-ambi/__;!!GjvTz_vk!DhNFIJSjLlBTt2ff1aIHLB55Hz9D_vR8WG3b2uPJ37dr9hNIU4dghgNFhiTQ8xc$>
> - draft-ietf-mboned-dorms
> <https://urldefense.com/v3/__http:/draft-ietf-mboned-dorms/__;!!GjvTz_vk!DhNFIJSjLlBTt2ff1aIHLB55Hz9D_vR8WG3b2uPJ37dr9hNIU4dghgNFpBPIpck$>
>
> - draft-ietf-mboned-mnat
> <https://urldefense.com/v3/__http:/draft-ietf-mboned-mnat/__;!!GjvTz_vk!DhNFIJSjLlBTt2ff1aIHLB55Hz9D_vR8WG3b2uPJ37dr9hNIU4dghgNFEzNi_XI$>
> - draft-ietf-mboned-cbacc
> <https://urldefense.com/v3/__http:/draft-ietf-mboned-cbacc/__;!!GjvTz_vk!DhNFIJSjLlBTt2ff1aIHLB55Hz9D_vR8WG3b2uPJ37dr9hNIU4dghgNF9SrvDFo$>
>
> (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.
>
> --
>
> *Error! Filename not specified.*
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!GjvTz_vk!DhNFIJSjLlBTt2ff1aIHLB55Hz9D_vR8WG3b2uPJ37dr9hNIU4dghgNFEOI0wLY$>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
>
> --
>
> [image: Image removed by sender.]
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!GjvTz_vk!FBIPYCQrN0By_vJcKO_V9-zzmIyeuhaXJE1vlu09N1VmnYDsPvSJ-lVRgbkYpRA$>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
>
> --
>
> [image: Image removed by sender.]
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!GjvTz_vk!FBIPYCQrN0By_vJcKO_V9-zzmIyeuhaXJE1vlu09N1VmnYDsPvSJ-lVRgbkYpRA$>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*