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

From: Greg Shepherd <[email-masked]>
Date: Thu, 9 Dec 2021 09:18:41 -0800

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

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Wed, 15 Dec 2021 09:17:21 +0000

Hi Greg,

I’ve read the document and I think it is useful. I could be the Shepherd for the document if it is necessary.
But of course, getting in touch with the authors should come first.

Best
Xuesong

From: BIER [mailto:[email-masked]] On Behalf Of Greg Shepherd
Sent: Friday, December 10, 2021 1:19 AM
To: BIER WG <[email-masked]>
Subject: Re: [Bier] WGLC: draft-ietf-bier-multicast-http-response

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 <[email-masked]<mailto:[email-masked]>> wrote:
This email starts a 2 week WGLC timer for draft-ietf-bier-multicast-http-response. Please read and review:

We also need a doc Shepherd before we can progress this work. Can someone please step up to help.

Thanks,
- Shep
(Chairs)

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 17 Dec 2021 00:16:11 +0100

Greg: 

a) Thank you for the WGLC.

b) As an author, i am very interested to see this document be finished as a WG item,
   and will certainly contribute to make this happen

c) Let me promote the doc to the WG:

   I would really encourage all non-WG members to review the document and
   consider it to be the current best document to promote the benefit of BIER
   to applications (as opposed to what we otherwise do today: Benefits to the
   network operator, no difference seen by application developers).

   The key benefit BIER used in this document is that the video-sender can 
   control for every packet which receiver it is sent to. This allows for
   a DASH sender to use multicast: The DASH sender sends the different
   bitrates for each segment, and can indicate the receivers for each bandwidth
   packets.

   If this great alue of BIER in this pretty (IMHO) fundamental use-case is
   not crish enough in the draft, please tell us, and we're happy to improve
   the text accordingly!

d) I have some personal limitations to spend cycles until the end of the year. 
   Hence my late replies in nov/dec. And of course the bier-te draft is
   on top of my queue.

Cheers
    toerless

> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier

-- 
---
[email-masked]

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 17 Dec 2021 05:09:36 -0800

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

- Shep

---

From: Dirk Trossen <[email-masked]>
Date: Fri, 17 Dec 2021 15:20:41 +0000

Greg, Alvaro, all,

My apologies for the silence from my side on this and thanks for the WGLC on this draft.

Personally, I would like to see this work progress in the WG and I am happy to contribute to any needed update. Thanks to Alvaro for the excellent points to look into for such update and also thanks to Toerless, who has provided a very good spin for this draft, well capturing the original reasons for proposing the solution.

In addition to the interest of the wider WG, I would also like to see the viewpoints of my co-authors in terms of finalizing this draft since the work was originally initiated during my tenure with their company and I would want to see that this solution is still relevant to my co-authors.

Best,

Dirk

From: BIER [mailto:[email-masked]] On Behalf Of Alvaro Retana
Sent: 17 December 2021 14:10
To: [email-masked]
Cc: BIER WG <[email-masked]>
Subject: Re: [Bier] WGLC: draft-ietf-bier-multicast-http-response

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 ([email-masked]<mailto:[email-masked]>) wrote:
Zero response for this WGLC, not even from the authors. Is this work still of interest to anyone in the WG?

- Shep

Thanks,
- Shep
(Chairs)
_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 20 Dec 2021 21:13:04 +0100

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)

-- 
---
[email-masked]

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 22 Dec 2021 18:14:33 -0500

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

-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Dirk Trossen <[email-masked]>
Date: Thu, 23 Dec 2021 09:24:13 +0000

Hi Gyan,

Many thanks for supporting this draft and its continuation as well as good to see your interest in collaborate on the continued draft.

See more inline.

Best,

Dirk

From: BIER [mailto:[email-masked]] On Behalf Of Gyan Mishra
Sent: 23 December 2021 00:15
To: Toerless Eckert <[email-masked]>
Cc: [email-masked]; BIER WG <[email-masked]>; Alvaro Retana <[email-masked]>
Subject: Re: [Bier] WGLC: draft-ietf-bier-multicast-http-response

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.
[DOT] Key here is that, unlike in IP multicast, there is no direct notion of a stream but a joint interest (expressed in the request for a specific chunk, for instance), expressed as individual unicast requests but replied to as a single multicast response (there may be the same interest albeit express some time later, resulting in a the different response albeit with likely same content). This is key since it makes the multicast nature more instantaneous, not following a longer-lived group-like semantic. Take an example of clients pulling video chunks. The lack of synchronization in the unicast requests for chunks leads inevitably (due to processing and packet latencies) to changing batches of requests that may be responded to with relevant content, although the content itself may be the same across several responses. The batches likely change in membership since clients may encounter different relevant latencies etc.

[DOT] This aspect is important in several technical aspects, such as timing used to create the multicast response (therefore combining a certain number of incoming requests), how to handle the congestion on multicast relations that possible differ in nature from one response to another (since possibly different clients are ‘combined’ into the individual responses). To me, those questions need dealing with although not in this draft IMO. What the draft provides is a base capability, as you also outline it, to allow for this aggregation and the resulting multicast delivery of aggregated responses.

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.
[DOT] When comparing with IP multicast, its explicit group membership constitutes waste compared to the proposed mechanism since in the latter, the ‘group’ is defined through batching requests (for the same semantic content) at the server. The request for the content is here the ‘signaling’ to compare against. Of course, for static groups, you can argue that the joining happens once and the sender can simply stream, while the proposed mechanism signals for every chunk, so to speak. But the objectives are, of course, different since the underlying chunk retrieval aims at a different semantic, not limited to a live stream. If you want to move to such ‘individual viewing experiences’, the proposed solution still yields in multicast delivery due to the mere statistical synchronicity of chunk requests (particular for the short tail of a catalogue). Also, if you do live event but provision them over an HTTP-based platform, you are simply pushed into the unicast request/reply pattern – this draft proposes a mechanism that is based on the pattern in the forward direction but not the return one.

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
[DOT] Right, RFC8763 mentions this scenario but indeed lacks details. The test here was done as part of past efforts I led. The content was not live but stored content.

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
[DOT] You seem to assume a live streaming type of scenario, sourced from an ingest point (over UDP) and relayed via this mechanism? But the draft outlines something more akin to an HLS/DASH model, i.e., clients individually request chunks and the server replies albeit aggregating several same content responses into multicast ones – see also below.

[DOT] the aspects below are indeed all valid but it’s this part where I would expect input and positions from the application (protocol) community since the draft is merely meant to provide a base delivery mechanism, not an application level solution. In my past work, we had some insights into the aspects you outline below but it’s not captured in this draft for the reasons already mentioned.

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.

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.
[DOT] It is the HLS/DASH type of delivery mechanism. The lack of support for multicast here motivated the draft initially but still leaves questions open on issues like timing of aggregation, interaction with upper layer mechanism, how to handle congestion control on the return path (if at all)…
[DOT] as an example: DASH adaptive streaming mimics TCP in the sense of using latency information as an indication for network conditions, thereby lowering the stream quality when such latency occurs. If you look into the idea of aggregated chunk responses (as in the draft here), you may notice quickly that ‘delaying’ chunk responses is beneficial here since doing so increases your window to ‘catch’ more incoming client requests for the same content, thereby increasing the size of the response group. How long to delay? Well, could be something like 75% of the chunk length (just to give a number) since it gives you a good delay budget for returning the response and playing it out (with chunk length of 4 or more seconds). Problem is that if you do that, DASH adaptive stream will kick in and reduce your streaming quality…so there are interactions that need to be understood.

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.

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

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.

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://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.

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

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.
[DOT] Note again, that the point here is that the solution is based on a request/response semantic with the former in unicast and the latter possibly in multicast (if more than one request to the  same content). Most of the solutions you outline above are joining an explicit group for a stream. Now you could, of course, model this via an HTTP/2 request and a stream of HTTP DATA frames. So this would make the forward request your explicit group membership signaling.

I can provide a further review of the draft and input to help advance the document.
[DOT] Great, thanks! Your email was already extremely helpful.

Many Thanks!

Gyan

On Mon, Dec 20, 2021 at 3:13 PM Toerless Eckert <[email-masked]<mailto:[email-masked]>> wrote:
Dear BIER WG-chairs

Deadline:

  02-15-2022

Document revision:

Thank you so much

--
---
[email-masked]<mailto:[email-masked]>

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 24 Dec 2021 02:24:02 -0500

Hi Dirk

Responses in-line

Kind Regards

Gyan

On Thu, Dec 23, 2021 at 4:24 AM Dirk Trossen <[email-masked]>
wrote:

> Hi Gyan,
>
>
>
> Many thanks for supporting this draft and its continuation as well as good
> to see your interest in collaborate on the continued draft.
>
>  Gyan> Welcome!
>
> See more inline.
>
>
>
> Best,
>
>
>
> Dirk
>
>
>
> *From:* BIER [mailto:[email-masked]] *On Behalf Of *Gyan Mishra
> *Sent:* 23 December 2021 00:15
> *To:* Toerless Eckert <[email-masked]>
> *Cc:* [email-masked]; BIER WG <[email-masked]>; Alvaro Retana <
> [email-masked]>
> *Subject:* Re: [Bier] WGLC: draft-ietf-bier-multicast-http-response
>
>
>
>
>
> Dear BIER WG,
>
>
>
> *[DOT] Key here is that, unlike in IP multicast, there is no direct notion
> of a stream but a joint interest (expressed in the request for a specific
> chunk, for instance), expressed as individual unicast requests but replied
> to as a single multicast response (there may be the same interest albeit
> express some time later, resulting in a the different response albeit with
> likely same content). This is key since it makes the multicast nature more
> instantaneous, not following a longer-lived group-like semantic. Take an
> example of clients pulling video chunks. The lack of synchronization in the
> unicast requests for chunks leads inevitably (due to processing and packet
> latencies) to changing batches of requests that may be responded to with
> relevant content, although the content itself may be the same across
> several responses. The batches likely change in membership since clients
> may encounter different relevant latencies etc.  *
>
> * Gyan>  You say “unlike IP Multicast”so what you are describing and
> optimizations is not a multicast solution but a completely new solution
> alternative for subscribers and operators.  Is there a document I can read
> that explains how the host signaling works as it does not use IGMP or PIM
> it seems and different process, procedures, FSM of how to express interest
> for a specific chunk and how that all works.  That would really help the
> reader in understanding the full scope of the use case.  Also what part of
> IP Multicast is used as far as host signaling if any?  *
>
> *[DOT] This aspect is important in several technical aspects, such as
> timing used to create the multicast response (therefore combining a certain
> number of incoming requests), how to handle the congestion on multicast
> relations that possible differ in nature from one response to another
> (since possibly different clients are ‘combined’ into the individual
> responses). To me, those questions need dealing with although not in this
> draft IMO. What the draft provides is a base capability, as you also
> outline it, to allow for this aggregation and the resulting multicast
> delivery of aggregated responses.*
>

     Gyan> Understood.  I am still a bit lost from your above paragraph
that you state “unlike IP multicast”
This sounds like a completely new architecture that does not use the
multicast group concept for subscribers, but new framework to cutdown on
IGMP and PIM chatter,

> *[DOT] When comparing with IP multicast, its explicit group membership
> constitutes waste compared to the proposed mechanism since in the latter,
> the ‘group’ is defined through batching requests (for the same semantic
> content) at the server. The request for the content is here the ‘signaling’
> to compare against. Of course, for static groups, you can argue that the
> joining happens once and the sender can simply stream, while the proposed
> mechanism signals for every chunk, so to speak. But the objectives are, of
> course, different since the underlying chunk retrieval aims at a different
> semantic, not limited to a live stream. If you want to move to such
> ‘individual viewing experiences’, the proposed solution still yields in
> multicast delivery due to the mere statistical synchronicity of chunk
> requests (particular for the short tail of a catalogue). Also, if you do
> live event but provision them over an HTTP-based platform, you are simply
> pushed into the unicast request/reply pattern – this draft proposes a
> mechanism that is based on the pattern in the forward direction but not the
> return one. *
>
>  Gyan> As I stated above and I think should be included in the draft is a
> detailed explanation of the proposed multicast replacement architecture
> called  “http level multicast” and how it works detailed procedures and
> state machine.  With HLS and DASH the video file is broken up into chunks
> segments so if you have to signal interest in the steam for evey chunk that
> would be a lot of control plane signaling overhead where with IGMP you join
> the group which is for the video feed not the individual chunks of the
> video file being streamed.  Am I missing something?
>
> *[DOT] Right, RFC8763 mentions this scenario but indeed lacks details. The
> test here was done as part of past efforts I led. The content was not live
> but stored content. *
>
>  Gyan> Understood.  I think overall details of http level multicast is
> lacking in the dradt
>
> 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.
>
>
>
>
> *[DOT] You seem to assume a live streaming type of scenario, sourced from
> an ingest point (over UDP) and relayed via this mechanism? But the draft
> outlines something more akin to an HLS/DASH model, i.e., clients
> individually request chunks and the server replies albeit aggregating
> several same content responses into multicast ones – see also below.*
>
>  Gyan> Understood.  Ok so I think I get it this is a completely new
> architecture multicast paradigm shift
>
> *[DOT] the aspects below are indeed all valid but it’s this part where I
> would expect input and positions from the application (protocol) community
> since the draft is merely meant to provide a base delivery mechanism, not
> an application level solution. In my past work, we had some insights into
> the aspects you outline below but it’s not captured in this draft for the
> reasons already mentioned. *
>
>  Gyan> Understood
>
> *[DOT] It is the HLS/DASH type of delivery mechanism. The lack of support
> for multicast here motivated the draft initially but still leaves questions
> open on issues like timing of aggregation, interaction with upper layer
> mechanism, how to handle congestion control on the return path (if at all)…*
>
  Gyan> Understood

> *[DOT] as an example: DASH adaptive streaming mimics TCP in the sense of
> using latency information as an indication for network conditions, thereby
> lowering the stream quality when such latency occurs. If you look into the
> idea of aggregated chunk responses (as in the draft here), you may notice
> quickly that ‘delaying’ chunk responses is beneficial here since doing so
> increases your window to ‘catch’ more incoming client requests for the same
> content, thereby increasing the size of the response group. How long to
> delay? Well, could be something like 75% of the chunk length (just to give
> a number) since it gives you a good delay budget for returning the response
> and playing it out (with chunk length of 4 or more seconds). Problem is
> that if you do that, DASH adaptive stream will kick in and reduce your
> streaming quality…so there are interactions that need to be understood. *
>
>  Gyan> Understood
>
> 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.
>
>
>
>
> 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.
>
> *[DOT] Note again, that the point here is that the solution is based on a
> request/response semantic with the former in unicast and the latter
> possibly in multicast (if more than one request to the  same content). Most
> of the solutions you outline above are joining an explicit group for a
> stream. Now you could, of course, model this via an HTTP/2 request and a
> stream of HTTP DATA frames. So this would make the forward request your
> explicit group membership signaling. *
>
>  Gyan> Understood.  I am getting it now a completely new multicast
> architecture
>
> *[DOT] Great, thanks! Your email was already extremely helpful.*
>
>  Gyan> Most welcome!!
>
> Many Thanks!
>
>
>
> Gyan
>
>
>
> *Network Solutions Architect *
>
-- 

*Gyan Mishra*

*M 301 502-1347*