Subject: Re: [Mops] [MBONED] DVB: New Multicast Video Spec

From: Gyan Mishra <[email-masked]>
Date: Tue, 5 May 2020 10:11:39 -0400

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 <[email-masked]> wrote:

> Thanks Jake! The ball is starting to roll..
>
> On Tue, Apr 21, 2020 at 12:18 PM Holland, Jake <jholland=
> [email-masked]> 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
>>
>> Something to be aware of, and hopefully helpful to some of us.
>>
>> Best regards,
>> Jake
>>
>>
>> _______________________________________________
>> MBONED mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mboned
>>
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned
>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]

---

From: "Holland, Jake" <[email-masked]>
Date: Tue, 5 May 2020 21:07:26 +0000

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 <[email-masked]>
Date: Tuesday, May 5, 2020 at 7:11 AM
To: "[email-masked]" <[email-masked]>
Cc: "Holland, Jake" <[email-masked]>, MBONED WG <[email-masked]>, "[email-masked]" <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Jake! The ball is starting to roll..

On Tue, Apr 21, 2020 at 12:18 PM Holland, Jake <jholland=[email-masked]<mailto:[email-masked]>> 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=>

Best regards,
Jake

_______________________________________________
MBONED mailing list
[email-masked]<mailto:[email-masked]>
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
[email-masked]<mailto:[email-masked]>
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: 301 502-1347
Email: [email-masked]<mailto:[email-masked]>

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 5 May 2020 20:12:00 -0400

Thanks Jake for all the informational links and feedback.

Kind regards

Gyan

On Tue, May 5, 2020 at 5:07 PM Holland, Jake <[email-masked]> 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:
>
> 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:
>
> 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
>
>
>
> 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 <[email-masked]>
> *Date: *Tuesday, May 5, 2020 at 7:11 AM
> *To: *"[email-masked]" <[email-masked]>
> *Cc: *"Holland, Jake" <[email-masked]>, MBONED WG <[email-masked]>,
> "[email-masked]" <[email-masked]>
> *Subject: *Re: [MBONED] DVB: New Multicast Video Spec
>
>
>
> Jake
>
>
>
> 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
> 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.
>
>
>
> <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=>
>
> <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=>
>
> <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
>

-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347