Where network-layerYes and from a routing perspective, this also applies if members are senders as well.
multicast really *does* become compelling is when you've got a very
large number of receivers that want real-time simultaneous delivery of
something (like live video), and where the network-layer replication
and delivery is critical.
Given that we can't conclusively say we don't need to consider multiple senders at the network layer, and in light of what Jon just said below
the SM and Express papers clearly state their targets. Radia and Dave Cheriton have also explained that they may have broader applicability too, but I want to REFINE the cases, not expand the scope of this discussion.
here's a suggestion:
Express and SM both agree that the mcast API should change. This will
be part of the WG's goal.
In addition, a bi-directional tree can be degenerated to a single source
tree. Rather than agonizing whether we should have bi-directional
tree or not when we don't have enough evidence to decide yet, we can provide
a knob for users to cfg at the root (source or core) of the
mcast distribution tree, the choice is whether the root is the source (single
source) or not.
This feature could be deployed incrementally depending on market needs.
Is this agreeable?
If so, delivering a protocol (delta) that can accomodate this, in stages,&n
bsp;
will be another part of the WG's goal.
cheers,
cyl
p.s Hugh, do you have a url for the Express paper?