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

Dino,

See inline.

Best,

Dirk

-----Original Message-----
From: Dino Farinacci <[e-mail]> 
Sent: 07 November 2022 14:47
To: Dirk Trossen <[e-mail]>
Cc: Toerless Eckert <[e-mail]>; Gengxuesong (Geng Xuesong) <[e-mail]>; Jeffrey Zhang <[e-mail]>; Xiejingrong (Jingrong) <[e-mail]>; BIER WG <[e-mail]>; msr6 <[e-mail]>; mboned <[e-mail]>; pim <[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

> 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.
[DOT] Point taken. Given the reference to IP multicast, I was bringing in the network-side state as a key element to make the forwarding work but should have made this clearer.

> 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.
[DOT] Agree. So this may give you lower latency indeed for the tree building operations. This then leads to the aspect of what kind of state is needed (in the network) to make forwarding operations work. Here the difference between source-based methods (like BIER and MSR6) and IP multicast lies in the group dependency of that state IMO. 

> 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. 
[DOT] What I meant is that forwarding on a sub-tree may still continue even after a Leave message was received, unless you configure a 'fast leave' mechanism. 

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.
[DOT] Well played 😉 It is, in fact, so no convincing required. But the FRRM semantic does advocate explicit receiver initiated joins as well as multicast tree joining. Its realization via IP multicast uses IGMP for the former and in-network spanning trees for the latter. For BIER, MSR6, or even the SDN-based work we did some years ago, the explicit joins are the forward requests where the multicast tree joining is done solely at the source, e.g., by binary 'folding' unicast path into multicast ones. So I'm not objecting to the receiver-driven architecture (on the contrary) but am only trying to understand how newer technologies (such as BIER and MSR6) may fit under a single semantic to capture them all.

Dino