Re: [MBONED] DVB: New Multicast Video Spec

[Gyan Mishra <[e-mail]>]

Thanks Jake for all the informational links and feedback.

Kind regards

Gyan

On Tue, May 5, 2020 at 5:07 PM Holland, Jake <[e-mail]> wrote:

> Hi Gyan,
>
>
>
> Thanks for sending the note about that.  I hadn’t been watching the QUIC
> list, and I think there’s a few things to mention in response that might be
> more in-scope for mops and mboned than for QUIC:
>
>
>
> 1.
>
> QUIC for RTP got some consideration a few years back (without the
> multicast angle).  You might want to read an old thread or 2 discussing the
> idea, like this one:
>
> https://groups.google.com/forum/#!topic/discuss-webrtc/aRvnniKe-88
>
>
>
> AFAICT, the concept ended up reformulated as webtransport + webcodecs,
> which is an active set of coupled projects that looks like it might go
> somewhere.[1]
>
>
>
> 2.
>
> Coming back to multicast (particularly the reliable multicast point you
> mentioned), there’s some interesting work from the BBC on reliable
> transport using a multicast QUIC variant.  You might be interested to take
> a look at these:
>
> https://tools.ietf.org/html/draft-pardue-quic-http-mcast-06
>
> https://github.com/bbc/nghq
>
>
>
> To me it seems a fine option for application-level generalized object
> transport, and I made some changes along the way to AMBI
> (draft-ietf-mboned-ambi) to make sure that I think it can cover the
> transport-layer authenticity concerns that are briefly mentioned in the
> quic-http-mcast doc, as well as the other protocols that get carried over
> multicast UDP.
>
>
>
> To generalize that a bit, a solution I’ve seen written several different
> ways is using reliable transport with FEC plus unicast repair as a fallback.
>
>
>
> Certainly in Akamai’s LMS product we that, and I think the Cablelabs
> NORM-based approach[2] does also, and I’m pretty sure the DVB-mABR approach
> does as well, in addition to providing for protocol flexibility (DVB
> mentions support for FLUTEv1 and ATSC-ROUTE, which I gather is based on
> FLUTEv2, but also I get the idea that they’d be delighted to support the
> BBC’s QUIC-based protocol too, especially since it’s got some of the same
> authors).
>
>
>
> This plethora of UDP-based options (also including the existing MPEG-TS
> and RTP uses, plus the several other proprietary protocols) is a big part
> of why I wanted to handle unidirectional transport-level authentication in
> a generic way at the UDP layer or lower.
>
>
>
> All these protocols seem to have some active use and some potential for
> the future, and mostly I just want internet multicast to become actually
> viable to use widely for transport to end users, regardless of which
> application layer ends up being best in everybody’s deployments.
>
>
>
> HTH.
>
>
>
> Best regards,
>
> Jake
>
>
>
> [1]  A few possibly-useful links to follow if you’re interested in
> webtransport+webcodecs:
>
> https://discourse.wicg.io/t/webtransport-proposal/3508
>
> https://datatracker.ietf.org/wg/webtrans/about/
>
> https://discourse.wicg.io/t/webcodecs-proposal/3662
>
> https://github.com/w3c/media-and-entertainment/issues/25 )
>
>
>
> [2] Cablelabs NORM spec:
>
>
> https://community.cablelabs.com/wiki/plugins/servlet/cablelabs/alfresco/download?id=3edb1609-17ff-4844-87ed-124314a73e7c
>
>
>
> PS: If I read all the specs right, none of the FLUTE- or NORM- based
> implementations do anything like what the IETF FLUTE or NORM docs specify
> for feedback and rate control, but they did use the packet framing from
> those docs.
>
>
>
> (This was top-posted in response to the message below. I have no further
> comments added to the below text, but left the prior message included for
> context.)
>
>
>
>
>
> *From: *Gyan Mishra <[e-mail]>
> *Date: *Tuesday, May 5, 2020 at 7:11 AM
> *To: *"[e-mail]" <[e-mail]>
> *Cc: *"Holland, Jake" <[e-mail]>, MBONED WG <[e-mail]>,
> "[e-mail]" <[e-mail]>
> *Subject: *Re: [MBONED] DVB: New Multicast Video Spec
>
>
>
> Jake
>
>
>
> This is great news with MPEG-DASH and reliable multicast and adaptive bit
> rate.
>
>
>
> I actually sent an email below excerpt to QUIC WG related to possibly
> using QUIC variant to provide reliable multicast email below.  So the issue
> is multicast is uni directional so there is no feedback ACK so you would
> have to create a variant of QUIC the with data channel over QUIC and side
> band control channel for the ACK feedback for reliable multicast.  This is
> however outside of the QUIC WG charter so if anything it would be a
> individual submission but would not get WG adoption.
>
>
>
> ***email to QUIC WG***
>
>
>
> QUIC WG
>
>
>
> Has anyone ever tried using QUIC with multicastRTP UDP streamed using QUIC
>  transport.
>
>
>
> Multicast has always been problematic with use on the internet MBONE and
> even on intranets due the unreliable UDP RTP transport for MPEG4 MPEG-TS
> and even newer protocols MPED-DASH abs and HLS multicast has struggled
> with using UDP transport.
>
>
>
> Multicast has thus required stringent end to end QOS in profile
> guaranteed scheduling bandwidth hop by hop PHB to ensue no drops to avoid
> dropping of I frame resulting in client frozen window and buffering.
>
>
>
> Since QUIC is a secure reliable transport and supports unidirectional
> flows it would be a perfect fit for multicast.
>
>
>
> This would be a game changer for multicast as over the internet which you
> don’t have any QOS guarantee.
>
>
>
>
>
> Kind regards
>
>
>
> Gyan
>
>
>
> On Wed, Apr 22, 2020 at 11:59 AM Greg Shepherd <[e-mail]> wrote:
>
> Thanks Jake! The ball is starting to roll..
>
>
>
> On Tue, Apr 21, 2020 at 12:18 PM Holland, Jake <jholland=
> [e-mail]> wrote:
>
> Hi mops and mboned participants,
>
> I wanted to let you all know about a new spec that has recently come to my
> attention from the DVB SDO, detailing a new standard approach to delivering
> video over multicast, via reliable delivery of video segments that
> interoperate with DASH players:
>
>
> https://dvb.org/wp-content/uploads/2020/03/A176_Adaptive-Media-Streaming-over-IP-Multicast_Mar-2020.pdf
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__dvb.org_wp-2Dcontent_uploads_2020_03_A176-5FAdaptive-2DMedia-2DStreaming-2Dover-2DIP-2DMulticast-5FMar-2D2020.pdf&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=aQkj-amwdVtXDPVg_Nl7a8H1LSmRxRZ0NRD0Fpv0f90&s=zRELsFfyitr9rdDbZxVaak3KfAUSilNMfyFmhohUdkU&e=>
>
> Something to be aware of, and hopefully helpful to some of us.
>
> Best regards,
> Jake
>
>
> _______________________________________________
> MBONED mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mboned
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mboned&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=aQkj-amwdVtXDPVg_Nl7a8H1LSmRxRZ0NRD0Fpv0f90&s=4qHcA-WLGzkKAkUbj6u3GsiygdV4ZhB-8gn1mPfgMXE&e=>
>
> _______________________________________________
> MBONED mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mboned
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mboned&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=aQkj-amwdVtXDPVg_Nl7a8H1LSmRxRZ0NRD0Fpv0f90&s=4qHcA-WLGzkKAkUbj6u3GsiygdV4ZhB-8gn1mPfgMXE&e=>
>
> --
>
> Gyan  Mishra
>
> Network Engineering & Technology
>
> Verizon
>
> Silver Spring, MD 20904
>
> Phone: [phone]
>
> Email: [e-mail]
>
>
>
>
>


-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: [phone]

Email: [e-mail]