From nobody Thu Dec 23 23:24:21 2021 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11FE3A0AE2; Thu, 23 Dec 2021 23:24:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gK7mu7TgiS8X; Thu, 23 Dec 2021 23:24:14 -0800 (PST) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A12503A0AE0; Thu, 23 Dec 2021 23:24:14 -0800 (PST) Received: by mail-pj1-x1033.google.com with SMTP id k6-20020a17090a7f0600b001ad9d73b20bso7721505pjl.3; Thu, 23 Dec 2021 23:24:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jB/U8KOh2Y3V4E+LojD9IBrtA8SQkEDPuhIeXCa4Rwk=; b=j7Ojq7OPNh6Ef+eadhdly6+6/qQLxFhcRgl8hHS6aR+stRjXLd741yqbRICu/7hVHR 7nhXAcQMFnd0KYYQudAHoVUkVXUWm2gooOTxjATKdl1zKqQKcAV9Ph7GrjGVuZs8RQkg jiMfbDzFo7oqpkM5d/p6uPrryM9IAWOafRqt0FNmG7SqERWuyVuUp8T2wQNVPSm9dNIG 7svaJxka7TZjdMRnvvTDzCK9x/f0Fs041JtrmggKqkYDz0mAVdoN7wTVM3+iyR4/x4CS 3UCQ+/RqsjWJ0LTgIIQXugowwze/URyC92MiRizl0R6a5Px/wQZiuimmB8BNjdR6mX5J Hzwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jB/U8KOh2Y3V4E+LojD9IBrtA8SQkEDPuhIeXCa4Rwk=; b=J6d7W019ASQkeWOXU2l4qLHAdo59slNoIvgFV+jClwRafTY+UT91Qz56XDzbchNUAT NLjfFzGxRYMnyGujAx3hDZzmJ98UIrPEcjwo/s9WyW1oPKF69dS08Q2MSGJnIKjrXkqZ aWYxfdtucnl0vHX3VDYVLvGh9rOrU+QWemDd6+ZwJ7dapyNSInJwmLIBvJczzQBK9WEU nZSLJANSLDRWQuUqs5Pq4XJ7h368oh/lEFgzFxvVbKNLoDWGfhTIqk3PVM591FNZUvgz bYLLCvEfSJHeHqOCyntRm7MCPRQN7lmCNIQ2cfGk00gwWdbRbFTaN6tvzkjfS6Pe2u8U +NNA== X-Gm-Message-State: AOAM530iajpdjYeB/DXwq03mhpNshhQfTJ6oJ/65vnWEMnDebhiP1XZw h3XukYxhYJL8ntwNYgb2xsiSaD9g3DMvNKl4EIS+9XOP X-Google-Smtp-Source: ABdhPJwthutpNjjoLLgQ+A0kJizMVWbB9aqh9tjWeXg4CQgow1LJVfoQjpadXClWj737HscL70IImRHDkemD5Xp3FEY= X-Received: by 2002:a17:90a:1002:: with SMTP id b2mr6681632pja.202.1640330653433; Thu, 23 Dec 2021 23:24:13 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Gyan Mishra Date: Fri, 24 Dec 2021 02:24:02 -0500 Message-ID: To: Dirk Trossen Cc: Alvaro Retana , BIER WG , Toerless Eckert , "bier-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e981b605d3df3d78" Archived-At: Subject: Re: [Bier] WGLC: draft-ietf-bier-multicast-http-response X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2021 07:24:20 -0000 --000000000000e981b605d3df3d78 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dirk Responses in-line Kind Regards Gyan On Thu, Dec 23, 2021 at 4:24 AM Dirk Trossen wrote: > Hi Gyan, > > > > Many thanks for supporting this draft and its continuation as well as goo= d > to see your interest in collaborate on the continued draft. > > Gyan> Welcome! > > See more inline. > > > > Best, > > > > Dirk > > > > *From:* BIER [mailto:bier-bounces@ietf.org] *On Behalf Of *Gyan Mishra > *Sent:* 23 December 2021 00:15 > *To:* Toerless Eckert > *Cc:* bier-chairs@ietf.org; BIER WG ; Alvaro Retana < > aretana.ietf@gmail.com> > *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 clien= t > 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 notio= n > of a stream but a joint interest (expressed in the request for a specific > chunk, for instance), expressed as individual unicast requests but replie= d > to as a single multicast response (there may be the same interest albeit > express some time later, resulting in a the different response albeit wit= h > likely same content). This is key since it makes the multicast nature mor= e > instantaneous, not following a longer-lived group-like semantic. Take an > example of clients pulling video chunks. The lack of synchronization in t= he > unicast requests for chunks leads inevitably (due to processing and packe= t > 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 =E2=80=9Cunlike IP Multicast=E2=80=9Dso what you are des= cribing and > optimizations is not a multicast solution but a completely new solution > alternative for subscribers and operators. Is there a document I can rea= d > 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 interes= t > 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 o= f > 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 certa= in > 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 =E2=80=98combined=E2=80=99 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 =E2=80=9Cunlike IP multicast=E2=80=9D 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, > 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 strea= m > 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 =E2=80=98group=E2=80=99 is defined through batching requests (for the= same semantic > content) at the server. The request for the content is here the =E2=80=98= signaling=E2=80=99 > 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, o= f > course, different since the underlying chunk retrieval aims at a differen= t > semantic, not limited to a live stream. If you want to move to such > =E2=80=98individual viewing experiences=E2=80=99, the proposed solution s= till 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 =E2=80=93 this draft propos= es a > mechanism that is based on the pattern in the forward direction but not t= he > 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 =E2=80=9Chttp level multicast=E2=80=9D 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 th= at > would be a lot of control plane signaling overhead where with IGMP you jo= in > the group which is for the video feed not the individual chunks of the > video file being streamed. Am I missing something? > > 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 discusse= d > 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. Th= e > test here was done as part of past efforts I led. The content was not liv= e > 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. > > > > > https://datatracker.ietf.org/doc/html/draft-ietf-bier-use-cases-12#sectio= n-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 =E2=80=93 see also bel= ow.* > > 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=E2=80=99s this part = where I > would expect input and positions from the application (protocol) communit= y > 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=E2=80=99s not captured in this draft= for the > reasons already mentioned. * > > Gyan> Understood > > The key point I am missing is how adaptive video is natively possible ove= r > 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 a= nd > not bidirectional so no feedback mechanism exists for adaptive rate > limiting. I believe QUIC with sideband TCP channel is a possibility whi= ch > 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 whic= h > uses chunks and segments natively both video delivery methods only suppor= t > 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 questio= ns > open on issues like timing of aggregation, interaction with upper layer > mechanism, how to handle congestion control on the return path (if at all= )=E2=80=A6* > Gyan> Understood > *[DOT] as an example: DASH adaptive streaming mimics TCP in the sense of > using latency information as an indication for network conditions, thereb= y > lowering the stream quality when such latency occurs. If you look into th= e > idea of aggregated chunk responses (as in the draft here), you may notice > quickly that =E2=80=98delaying=E2=80=99 chunk responses is beneficial her= e since doing so > increases your window to =E2=80=98catch=E2=80=99 more incoming client req= uests 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 giv= e > a number) since it gives you a good delay budget for returning the respon= se > 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=E2=80=A6so there are interactions that need to be under= stood. * > > Gyan> Understood > > Most all modern web browsers Chrome, Firefox and Safari etc do not suppor= t > 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 require= s > 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/2= 01803/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-br= oadcast-services?hsLang=3Den > > > > > https://dashif.org/docs/workshop-2019/12-Stockhammer%20Multicast%20Decemb= er%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. > > *[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). Mo= st > 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 > > 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.* > > Gyan> Most welcome!! > > Many Thanks! > > > > Gyan > > > > On Mon, Dec 20, 2021 at 3:13 PM Toerless Eckert 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 reque= st > 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 BIE= R > 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 f= or > > 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-r= eferences/ > > ). > > > > Thanks! > > > > Alvaro. > > > > On December 9, 2021 at 12:19:05 PM, Greg Shepherd (gjshep@gmail.com) > 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 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 > > BIER@ietf.org > > https://www.ietf.org/mailman/listinfo/bier > > > _______________________________________________ > > BIER mailing list > > BIER@ietf.org > > https://www.ietf.org/mailman/listinfo/bier > > > -- > --- > tte@cs.fau.de > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > > -- > > > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mishra@verizon.com * > > *M 301 502-1347* > > > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com * *M 301 502-1347* --000000000000e981b605d3df3d78 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dirk

Responses in-line=C2=A0

Kind Regards=C2=A0

Gya= n

On Thu, Dec 23, 2021 at 4:24 AM Dirk Trossen <dirk.trossen@huawei.com> wrote:

Hi Gyan,

= =C2=A0

Many thanks for supporting this draft and it= s continuation as well as good to see your interest in collaborate on the c= ontinued draft.

=C2=A0Gyan> Welcome!

See more inline.=

= =C2=A0

Best,

= =C2=A0

Dirk

= =C2=A0

From: BIER [mailto:bier-bounces@ietf.or= g] On Behalf Of Gyan Mishra Sent: 23 December 2021 00:1= 5
To: Toerless Eckert <tte@cs.fau.de>
Cc: bier-chairs@ietf.org; BIER WG <bier@ietf.org&g= t;; Alvaro Retana <aretana.ietf@gmail.com&= gt;
Subject: Re: [Bier] WGLC: d= raft-ietf-bier-multicast-http-response

=C2=A0

=C2=A0

Dear BIER WG,=C2=A0

=C2=A0

I support publication =C2=A0of this informational dr= aft which provides the framework and basis of how stateless BIER infrastruc= ture can eliminate state and bandwidth usage with an aggregate http respons= e when many client join a stream.=C2=A0 I would be happy to collaborate on the draft.

[DOT] Key here is that, u= nlike in IP multicast, there is no direct notion of a stream but a joint in= terest (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 s= ame content). This is key since it makes the multicast nature more instantaneous, not following a longer-l= ived group-like semantic. Take an example of clients pulling video chunks. = The lack of synchronization in the unicast requests for chunks leads inevit= ably (due to processing and packet latencies) to changing batches of requests that may be responded to with r= elevant content, although the content itself may be the same across several= responses. The batches likely change in membership since clients may encou= nter different relevant latencies etc. =C2=A0

=C2=A0Gyan> =C2=A0You say =E2=80=9Cunlike IP Mult= icast=E2=80=9Dso what you are describing and optimizations is not a multica= st solution but a completely new solution alternative for subscribers and o= perators.=C2=A0 Is there a document I can read that explains how the host s= ignaling works as it does not use IGMP or PIM it seems and different proces= s, procedures, FSM of how to express interest for a specific chunk and how = that all works.=C2=A0 That would really help the reader in understanding th= e full scope of the use case.=C2=A0 Also what part of IP Multicast is used = as far as host signaling if any? =C2=A0

[DOT] This aspect is impo= rtant in several technical aspects, such as timing used to create the multi= cast 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 possibl= y different clients are =E2=80=98combined=E2=80=99 into the individual resp= onses). To me, those questions need dealing with although not in this draft IMO. What the draft provides is a base capabili= ty, as you also outline it, to allow for this aggregation and the resulting= multicast delivery of aggregated responses.

=

=C2=A0 =C2= =A0 =C2=A0Gyan> Understood.=C2=A0 I am still a bit lost from your above = paragraph that you state =E2=80=9Cunlike IP multicast=E2=80=9D
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,

I have some comments on the draft based on my experi= ence working with multicast video delivery:

=C2=A0

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

=C2=A0

Can you comment on the increase in signaling when th= ere are a few subscribers?=C2=A0 I assume you are referring to IGMP join la= st hop router chatter.=C2=A0

[DOT] When comparing with IP multicast= , its explicit group membership constitutes waste compared to the proposed = mechanism since in the latter, the =E2=80=98group=E2=80=99 is defined through batching requests (for the same semantic content) at th= e server. The request for the content is here the =E2=80=98signaling=E2=80= =99 to compare against. Of course, for static groups, you can argue that th= e 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 re= trieval aims at a different semantic, not limited to a live stream. If you = want to move to such =E2=80=98individual viewing experiences=E2=80=99, the proposed solution still yields in multic= ast delivery due to the mere statistical synchronicity of chunk requests (p= articular for the short tail of a catalogue). Also, if you do live event bu= t provision them over an HTTP-based platform, you are simply pushed into the unicast request/reply pattern =E2=80=93 thi= s draft proposes a mechanism that is based on the pattern in the forward di= rection but not the return one.

=C2=A0Gyan> As I stated above= and I think should be included in the draft is a detailed explanation of t= he proposed multicast replacement architecture called =C2=A0=E2=80=9Chttp l= evel multicast=E2=80=9D and how it works detailed procedures and state mach= ine.=C2=A0 With HLS and DASH the video file is broken up into chunks segmen= ts 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 fi= le being streamed.=C2=A0 Am I missing something?

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

=C2=A0

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

=C2=A0

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

[DOT] Right, RFC8763 mentions this sce= nario but indeed lacks details. The test here was done as part of past effo= rts I led. The content was not live but stored content.

=C2=A0Gyan> Understood.=C2=A0= I think overall details of http level multicast is lacking in the dradt=

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

=C2=A0

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

[DOT] You seem to assume a live stream= ing type of scenario, sourced from an ingest point (over UDP) and relayed v= ia this mechanism? But the draft outlines something more akin to an HLS/DASH model, i.e., clients individually reque= st chunks and the server replies albeit aggregating several same content re= sponses into multicast ones =E2=80=93 see also below.<= /span>

=C2=A0Gyan> Understood.=C2=A0 Ok so I think I get it th= is is a completely new architecture multicast paradigm shift=C2=A0

[DOT] the aspects below are indeed all= valid but it=E2=80=99s 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 app= lication level solution. In my past work, we had some insights into the asp= ects you outline below but it=E2=80=99s not captured in this draft for the = reasons already mentioned.

=C2=A0Gyan> Understood=C2=A0<= u>

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

=C2=A0

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

=C2=A0

=C2=A0

My understanding and experience with HLS and DASH ad= aptive streaming which uses chunks and segments natively both video deliver= y methods only support Unicast video delivery.=C2=A0 Does not support nativ= e delivery via multicast. =C2=A0

[DOT] It is the HLS/DASH type of deliv= ery mechanism. The lack of support for multicast here motivated the draft i= nitially but still leaves questions open on issues like timing of aggregation, interaction with upper layer mechani= sm, how to handle congestion control on the return path (if at all)=E2=80= =A6

=C2= =A0 Gyan> Understood=C2=A0

=

[DOT] as an example: DASH adaptive str= eaming mimics TCP in the sense of using latency information as an indicatio= n 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 t= hat =E2=80=98delaying=E2=80=99 chunk responses is beneficial here since doi= ng so increases your window to =E2=80=98catch=E2=80=99 more incoming client requests for the same content, thereby increasing the size of the r= esponse 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 i= f you do that, DASH adaptive stream will kick in and reduce your streaming = quality=E2=80=A6so there are interactions that need to be understood.

=C2=A0Gyan> Understood=C2=A0<= u>

Most all modern web browsers Chrome, Firefox and Saf= ari etc do not support NPAPI plug in and thus cannot play multicast nativel= y.=C2=A0 That is a major industry wide problem.

=C2=A0

There are standard solutions that exist that involve= a UDP wrapper at the source multicast gateway that ingests unicast and dis= tributes =C2=A0multicast. =C2=A0

=C2=A0

Ramp is one vendor that provides such a solution.=

Ramp uses a source sender that ingests HLS or DASH u= nicast stream and packages in UDP envelope and at the host receiver endpoin= t Window or Mac it strips UDP encapsulation and plays out HLS or DASH video= natively on loopback 127.0.0.1.

=C2=A0

=C2=A0

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

=C2=A0

=C2=A0

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

=C2=A0

This is the only link below I could find on DASH mul= ticast.

=C2=A0

DVB is basically MPEG video delivery over an IP netw= ork.=C2=A0 There was a DVB IETF WG which concluded decades ago and since ha= d been a standards forum for digital video delivery.

=C2=A0

=C2=A0

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

=C2=A0

This document talks about how ingest occurs if adapt= ive video source stream done by a multicast server which encapsulated and d= elivers the multicast over the network.

=C2=A0

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

=C2=A0

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

[DOT] Note again, that the point here = is that the solution is based on a request/response semantic with the forme= r in unicast and the latter possibly in multicast (if more than one request to the=C2=A0 same content). Most of th= e solutions you outline above are joining an explicit group for a stream. N= ow you could, of course, model this via an HTTP/2 request and a stream of H= TTP DATA frames. So this would make the forward request your explicit group membership signaling. <= span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73= ,125)">

=C2=A0Gyan> Understood.=C2=A0= I am getting it now a completely new multicast architecture=C2=A0

I can provide a further review of the draft and inpu= t to help advance the document.

[DOT] Great, thanks! Your email was al= ready extremely helpful.=

=C2=A0Gyan> Most welcome!!=

Many Thanks!

=C2=A0

Gyan

=C2=A0

On Mon, Dec 20, 2021 at 3:13 PM Toerless Eckert <= tte@cs.fau.de> wr= ote:

Dear BIER WG-chairs

a) As authors, we are pinging other WG members to ask for more reviews with= in BIER-WG.

b) Picking up on Alvaros suggestion (thanks a lot), i would like to request=
=C2=A0 on behalf of the authors a TSVART (Transport Area Review Team).

(we will ask for Application Area review later.. working ourselves up the s= tack).

Here is the suggested text for the datatracker form through which
you WG chairs could reques

Deadline:

=C2=A0 02-15-2022

Document revision:

=C2=A0 draft-ietf-bier-multicast-http-response-06

Requester's comments and instructions

=C2=A0 The authors are requesting early review of the document from transpo= rt area.

=C2=A0 The following is a motivational summary of the purpose of this docum= ent:

=C2=A0 Adaptive bitrate streaming (such as today DASH) for live-streaming o= r short-tail can
=C2=A0 use Multicast to improve network efficiency by eliminating duplicate= transmission
=C2=A0 of the same data segments to multiple users requiring the same bitra= te. This
=C2=A0 was shown and used in products as early as 200x (e.g.: Digital Fount= ain).
=C2=A0 These solutions never proliferated because of the intrinsic signalin= g problems
=C2=A0 of IP Multicast causing severe performance/scale/operational issues.=

=C2=A0 These IP Multicast limitations can today be overcome with the novel = BIER
=C2=A0 multicast mechanism. This document describes an application solution= layer
=C2=A0 architecture in which BIER is used as the multicast mechanism for HT= TP
=C2=A0 adaptive bitrate streaming including the use of BIER-TE for includin= g
=C2=A0 path steering optimizations into the solution. This document is sole= ly
=C2=A0 informational and does not intend to establish any standards for the= IETF.

Thank you so much
=C2=A0 =C2=A0 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 docu= ments
> reach consensus, to demonstrate that the WG cares and has reviewed, > commented, etc.=C2=A0 Silence is not a good indicator of consensus. Th= anks for
> following up on this!
>
> If there is interest in the WG, and given that this document deals wit= h
> 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.=C2=A0 Please use the rfc81= 74
> template (not rfc2119).=C2=A0 I am surprised that there are no Normati= ve
> references (
> https://www.ietf.org/about/groups/iesg/statements/normative-informative-ref= erences/
> ).
>
> Thanks!
>
> Alvaro.
>
> On December 9, 2021 at 12:19:05 PM, Greg Shepherd (gjshep@gmail.com) wrote:
>
> Zero response for this WGLC, not even from the authors. Is this work s= till
> of interest to anyone in the WG?
>
> - Shep
>
> On Mon, Nov 22, 2021 at 8:45 AM Greg Shepherd <gjshep@gmail.com> wrote:
>
> > This email starts a 2 week WGLC timer for
> > draft-ietf-bier-multicast-http-response. Please read and review:<= br> > >
> > 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
> BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier

> _______________________________________________
> BIER mailing list
> BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier


--
---
tte@cs.fau.de

_______________________________________________
BIER mailing list
BIER@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/bier

--

Gyan Mishra

Network Solutions Architect=C2=A0

Email gyan.s.mishra@verizon.com

M 301 502-1347

=C2=A0

--
--000000000000e981b605d3df3d78--