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

[Dino Farinacci <[e-mail]>]

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

We need to be more specific when we just make a referene to "state". Because whats important about state is how much and where it needs to be stored and how fast it is put in place to be used. We started the discussion with the receiver state. And now its moving to multicast tree state. That is fine but just want to make it clear how I am evolving the discussion.

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

Yes, it certainly depends on the density of the recievers that causes more or less spareness on the distribution tree. If the merge happens close to the source, it may make an argument for head-end-replication where multicast tree state buys you little. If the branching is robust, then the merge points are either or both in the core or the reciever edges.

> 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

They do not since IGMPv2 where a Leave message was introduced. Of course control-plane packet loss and moderate robustness in retransmission of control-message would cause the last resort state timeout, but I feel this is an exception rather than a rule. And arguably this can be improved with a ligher weight transport than TCP, like using QUIC.

Your ICN experience should convince you how useful and valuable receiver initiated joins and multicast tree merging is.

Dino