What techniques can be used to speed up reliable multicasting? For example, say a sender is delivering an object reliably to 10 known and fixed receivers over WAN. What can be done to decrease average completion times?
a Multicast Distribution Tree (MDT) as a distributor of MultiCast (MC) can help: A node in the network acts as a Designated Router (DR). This DR represents the root in the MDT. All end nodes as MC recipients are the leaves of the MDT. The paths from the root to the individual leaves in MDT
are the shortest routes (number of hops).
All packets (as multicast data) are first delivered to the DR for sending. All intermediate nodes in the MDT therefore send the MC data to the leaves via all branches (paths). The multicast protocols are based on this principle, such as: PIM-SM (Protocol Independent Multicast - Sparse Mode), RFC 4601.
Since you specify "reliable" multicast, as opposed to just plain jane multicast, I have to assume you are asking about retransmissions in case of a receiver receiving corrupted packets? That is a problem with reliable multicast. A better way than individual receivers requesting retransmissions, which will then interrupt the flow of multicast packets, is to use forward error correction techniques in the multicast payload. This does increase the size of each packet, but one can choose a level of FEC that is "good enough," and then avoid retransmissions altogether. For streaming media, where interrupting the flow is not really an option, FEC is used.
Efficient multicast routing trees apply to any multicast, and protocols like PIM-SM work to achieve such efficient trees (RFC 7761, see in particular introductory Sections 3.1-3.3). You begin with a rendezvous point which a receiver can access, and which relays all of the multicast packets from a source. But then the protocol looks for more efficient routes, going from each destination to the multicast source(s), to form more efficient trees. But I don't believe this is what you were asking?
Thank you Anatol and Albert for your valuable comments. This is actually a research question that I am asking and I didn't have any specific multicasting standard or protocol in mind. I was thinking more about the abstract problem, like given a graph with link capacity specified on edges, how should we select trees to connect receivers to the sender to minimize average completion times.
Mohammad, if you go through the IETF RFCs on the subject of multicast, you should find that the subject is very much discussed on fundamental principles. So for example, unicast routing protocols, whether link state or distance vector, optimize the path based on link speeds (costs). And multicast trees are built secondarily, on top of these unicast routing protocols. That's how use of optimal paths is taken into account. I would read through RFC 5110, to get the broad perspective of multicast routing.
There are multiple options discussed, frequently, and the best one may depend on circumstances. For instance, if there are very many members of multicast groups in a particular network, it might make more sense to begin with an overabundance of branches in the multicast trees, and then pare these down when it is determined that some of the braches are not necessary. Conversely, if multicast members are few and far between, it might make more sense to begin with a very parsimonious set of branches, and then add on to these when the individual members remain in the group.
There are associated protocols, such as RTP/RTCP, which are used to provide feedback to a source of unicasts or multiast, to adjust dynamically the transmission rate, based on unicast or multicast path specifications (success rates, or lack of). There are a number of proprietary streaming protocols with similar goals as RTP/RTCP, providing similar dynamic control of the transmissions. These permit use of best effort packet switched networks, even for communications previously only possible with connection-oriented networks (where link requirements are negotiated and then guaranteed, before a transmission can begin).
I don't think much of this is specific to any one protocol implementation. The underlying concepts are generic and even clever.