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

[Dirk Trossen <[e-mail]>]

Get the receiver API issue but the eventual setup and maintenance of the state defines the applicability in scenarios with high dynamicity.

Sure, if it's all rather local in receiver set changes, latency is reduced to local joined branching points but that's a strong assumption on locality.

Even then, I was under the impression that leave operations have timeouts to avoid frequent join/leave flapping so you might not even get the per request grouping behaviour you may want.

Dirk




From:Dino Farinacci <[e-mail]>
To:Dirk Trossen <[e-mail]>
Cc:Toerless Eckert <[e-mail]>;Gengxuesong (Geng Xuesong) <[e-mail]>;Jeffrey Zhang <[e-mail]>;Xiejingrong (Jingrong) <xiejingrong=[e-mail]>;BIER WG <[e-mail]>;msr6 <[e-mail]>;mboned <[e-mail]>;pim <[e-mail]>
Date:2022-11-05 17:13:26
Subject:Re: [Msr6] [Bier] MSR6 BOF 3rd Issue Category: More details are requested about the large scale use cases, including issue 8-11

I was taking about the local API in the receiver host.

Control-plane propagation time to the source which starts data delivery is another matter. But note that join merges on branches close to the receiver reduce latency more then when each receiver  contacts the source when they join.

Dino

> On Nov 4, 2022, at 11:57 PM, Dirk Trossen <[e-mail]> wrote:
>
> At which timescales can you form a multicast group and establish the network state, including to leave said group possibly at the next forward request. I don't think you can get there with IGMP, sorry.
>
> Best,
>
> Dirk
>
> -----Original Message-----
> From: Dino Farinacci <[e-mail]>
> Sent: 04 November 2022 19:09
> To: Dirk Trossen <[e-mail]>
> Cc: Toerless Eckert <[e-mail]>; Gengxuesong (Geng Xuesong) <[e-mail]>; Jeffrey Zhang <[e-mail]>; Xiejingrong (Jingrong) <xiejingrong=[e-mail]>; BIER WG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [Msr6] [Bier] MSR6 BOF 3rd Issue Category: More details are requested about the large scale use cases, including issue 8-11
>
> 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
>