Re: [MBONED] [Msr6] [Bier] MSR6 BOF 3rd Issue Category: More details are requested about the large scale use cases, including issue 8-11

[Dino Farinacci <[e-mail]>]

Well IGMP can do the job without crossing layer boundaries to acheive the same thing. Why is this better?

Dino

> On Nov 4, 2022, at 1:14 AM, Dirk Trossen <[e-mail]> wrote:
> 
> 
>>> receiver of the multicast should be determined by the application layer (e.g., http request with the same content requirement) or a controller could gather the information about which receivers want the same content.
>> 
>> Yes and that happens today and hence signals the lower layer IGMP/MLD protocol to send a "join signal" on the network.
> 
> [DOT] I think Xuesong is referring to the 'implicit joins' that can be expressed through forward requests to, e.g., same content, leading to a source operation to construct suitable return path information in an ad-hoc manner. This allows for, e.g., delivering responses to HTTP requests (for video chunks) that arrived unsynchronized at the server in a multicast manner. Point on dynamicity here is that the next 'batch' of requests (maybe even to the same chunk) may have a vastly different set of receivers (i.e., requestors for a specific chunk) due to variations in sending those originating forward requests (even just because a receiver may execute a PAUSE command on its UI). This was the essence of the BIER multicast response draft and is captured in the name of its success draft: 'forward requests, return multicast'. Here, explicit joins to the network to establish forwarding state simply won't do for the delay budget you have (those chunks need to be delivered at some point).
> 
> Dirk