Re: [Bier] WGLC: draft-ietf-bier-multicast-http-response

[Gyan Mishra <[e-mail]>]

Dear BIER WG,

I support publication  of this informational draft which provides the
framework and basis of how stateless BIER infrastructure can eliminate
state and bandwidth usage with an aggregate http response when many client
join a stream.  I would be happy to collaborate on the draft.

I have some comments on the draft based on my experience working with
multicast video delivery:

Is the waste in transmission bandwidth due to PIM Assert and double stream
when multiple first hop routers are connected to the source?

Can you comment on the increase in signaling when there are a few
subscribers?  I assume you are referring to IGMP join last hop router
chatter.

The goal of BIER is to eliminate state in the core for MVPN P-tree and
C-Tree tree building technologies and not the last hop router as that is on
the customer side signaling.

I read through this RFC related to IRTF ICN deployments scenario discussed
related to 80 nodes test, however not much detail is provided related to
the adaptive multicast streaming testing.

https://datatracker.ietf.org/doc/html/rfc8763

I read through this draft section 3.10 and it also does not provide details
into how multicast adaptive video delivery works without having a gateway
or server that does an ingest of the adaptive video to source the multicast
distribution stream over UDP transport.

https://datatracker.ietf.org/doc/html/draft-ietf-bier-use-cases-12#section-3.10

The key point I am missing is how adaptive video is natively possible over
UDP transport.

Comments below are related to multicast and adaptive streaming.  The
problem with multicast is it uses UDP transport and is a one way stream and
not bidirectional so no feedback mechanism exists for adaptive rate
limiting.  I believe QUIC with sideband TCP channel  is a possibility which
I have investigated as an alternate transport to UDP.  PGM pragmatic
multicast is another possibility.

https://datatracker.ietf.org/doc/html/rfc3208


My understanding and experience with HLS and DASH adaptive streaming which
uses chunks and segments natively both video delivery methods only support
Unicast video delivery.  Does not support native delivery via multicast.

Most all modern web browsers Chrome, Firefox and Safari etc do not support
NPAPI plug in and thus cannot play multicast natively.  That is a major
industry wide problem.

There are standard solutions that exist that involve a UDP wrapper at the
source multicast gateway that ingests unicast and distributes  multicast.

Ramp is one vendor that provides such a solution.
Ramp uses a source sender that ingests HLS or DASH unicast stream and
packages in UDP envelope and at the host receiver endpoint Window or Mac it
strips UDP encapsulation and plays out HLS or DASH video natively on
loopback 127.0.0.1.

https://www.rampecdn.com/

Wowza is another vendor that does support multicast streaming but requires
ingest as well of adaptive steam and then sources multicast distribution
stream.

https://www.wowza.com/community/t/multicast-options-with-wowza-streaming-engine/44969


There has been development work done with WebRTC messaging that has the
ability to provide a similar solution to natively play out multicast in a
web browser.

https://www.w3.org/2020/09/webrtc-charter.html

https://datatracker.ietf.org/wg/rtcweb/documents/

This is the only link below I could find on DASH multicast.

https://res-www.zte.com.cn/mediares/magazine/publication/com_en/article/201803/PARK.pdf

Some history on DVB:

DVB is basically MPEG video delivery over an IP network.  There was a DVB
IETF WG which concluded decades ago and since had been a standards forum
for digital video delivery.

https://datatracker.ietf.org/wg/ipdvb/documents/


https://dvb.org/

This document was published in 2018 and talks about adaptive streaming over
IP multicast.

This document talks about how ingest occurs if adaptive video source stream
done by a multicast server which encapsulated and delivers the multicast
over the network.

https://dvb.org/wp-content/uploads/2019/12/a176_adaptive_media_streaming_over_ip_multicast_2018-02-16_draft_bluebook.pdf

3GPP 5G to support MBS Multicast and Broadcast Services with release 17
adaptive video delivery MPEG DASH

https://www.smpte.org/webcast/an-introduction-to-3gpp-5g-multicast-and-broadcast-services?hsLang=en

https://dashif.org/docs/workshop-2019/12-Stockhammer%20Multicast%20December%202019.pdf

https://www.etsi.org/deliver/etsi_ts/103700_103799/103720/01.01.01_60/ts_103720v010101p.pdf

This solution to use BIER could apply to any network that utilizes adaptive
video on FBB, MBB as well as an other network so  could have ubiquitous use
cases.

I can provide a further review of the draft and input to help advance the
document.

Many Thanks!

Gyan

On Mon, Dec 20, 2021 at 3:13 PM Toerless Eckert <[e-mail]> wrote:

> Dear BIER WG-chairs
>
> a) As authors, we are pinging other WG members to ask for more reviews
> within BIER-WG.
>
> b) Picking up on Alvaros suggestion (thanks a lot), i would like to request
>   on behalf of the authors a TSVART (Transport Area Review Team).
>
> (we will ask for Application Area review later.. working ourselves up the
> stack).
>
> Here is the suggested text for the datatracker form through which
> you WG chairs could reques
>
> Deadline:
>
>   02-15-2022
>
> Document revision:
>
>   draft-ietf-bier-multicast-http-response-06
>
> Requester's comments and instructions
>
>   The authors are requesting early review of the document from transport
> area.
>
>   The following is a motivational summary of the purpose of this document:
>
>   Adaptive bitrate streaming (such as today DASH) for live-streaming or
> short-tail can
>   use Multicast to improve network efficiency by eliminating duplicate
> transmission
>   of the same data segments to multiple users requiring the same bitrate.
> This
>   was shown and used in products as early as 200x (e.g.: Digital
> Fountain).
>   These solutions never proliferated because of the intrinsic signaling
> problems
>   of IP Multicast causing severe performance/scale/operational issues.
>
>   These IP Multicast limitations can today be overcome with the novel BIER
>   multicast mechanism. This document describes an application solution
> layer
>   architecture in which BIER is used as the multicast mechanism for HTTP
>   adaptive bitrate streaming including the use of BIER-TE for including
>   path steering optimizations into the solution. This document is solely
>   informational and does not intend to establish any standards for the
> IETF.
>
> Thank you so much
>     Toerless (for the authors)
>
> On Fri, Dec 17, 2021 at 05:09:36AM -0800, Alvaro Retana wrote:
> > Greg:
> >
> > Hi!
> >
> > It is important in light of rfc8789, which requires that all IETF
> documents
> > reach consensus, to demonstrate that the WG cares and has reviewed,
> > commented, etc.  Silence is not a good indicator of consensus. Thanks for
> > following up on this!
> >
> > If there is interest in the WG, and given that this document deals with
> > HTTP level multicast, please request an early review from both the ART
> and
> > Transport areas review teams before sending it off for publication.
> >
> >
> > A couple of quick comments for the authors.  Please use the rfc8174
> > template (not rfc2119).  I am surprised that there are no Normative
> > references (
> >
> https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
> > ).
> >
> > Thanks!
> >
> > Alvaro.
> >
> > On December 9, 2021 at 12:19:05 PM, Greg Shepherd ([e-mail])
> wrote:
> >
> > Zero response for this WGLC, not even from the authors. Is this work
> still
> > of interest to anyone in the WG?
> >
> > - Shep
> >
> > On Mon, Nov 22, 2021 at 8:45 AM Greg Shepherd <[e-mail]> wrote:
> >
> > > This email starts a 2 week WGLC timer for
> > > draft-ietf-bier-multicast-http-response. Please read and review:
> > >
> > >
> https://datatracker.ietf.org/doc/draft-ietf-bier-multicast-http-response/
> > >
> > > We also need a doc Shepherd before we can progress this work. Can
> someone
> > > please step up to help.
> > >
> > > Thanks,
> > > - Shep
> > > (Chairs)
> > >
> > _______________________________________________
> > BIER mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/bier
>
> > _______________________________________________
> > BIER mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/bier
>
>
> --
> ---
> [e-mail]
>
> _______________________________________________
> BIER mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bier
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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



*M 301 502-1347*