Whether a network provides a simple connectionless or a complicated connection oriented unicasting service, generalizing it for multicasting is not trivial. Flow, congestion and error control depend on feedback to the sender, according to network and receiver triggered events. For simple network services, no such information is provided by the network itself, but instead higher layer protocols must exchange end-to-end reports. With more complex network service models, some of these problems, such as error control, may be dealt with internally in the network, while other problems such as flow control, are left to higher layer protocols that are better equipped to deal with them.
Error control ensures that packets transmitted by the sender are received correctly at the other end. Packets may be received corrupted (detected by error detection codes) or they may be lost (detected by missed packet sequence numbers). Flow control assures that the sender does not swamp the receiver with data that cannot be consumed in time. Congestion control deals again with the problem of insufficient resources, but this time on the network switches between sender and receiver. Although packets are dropped when they cannot be processed in an intermediate node, in many networks this loss can be detected only by the receiver, resulting in confusion between errors and congestion (lost vs. dropped packets). While flow control is clearly an end-to-end issue, error control and congestion control depend on network status and thus they can be either dealt with at the network layer, or addressed at the higher layers, on an end-to-end basis.
In the unicast case, lost or corrupted packets are retransmitted based on feedback received from the network or the receiver. When packets are multicast, simple feedback schemes face the feedback implosion problem[33]: all receivers respond with status information, swamping the sender with possibly conflicting reports. Ideally, senders would like to deal with the multicast group as a whole and not on an individual receiver basis. This is the host group model. However, it cannot simply treat all receivers identically, because this would lead to either ignoring the retransmission requests of some receivers, or to wasting resources by retransmitting to all of them.
Since there is no evident solution that satisfies all requirements, several approaches exist emphasizing different goals. The simplest approach of all is to ignore the problem at the network layer and provide a best effort connectionless service. Delegating the resolution of transmission problems to the higher layers may be an adequate solution in many cases, since they may have additional information about the application requirements, and thus implement more appropriate mechanisms than what is possible here. In Section iv-D we discuss how this applies specifically to continuous media communications.
A second solution sacrifices the host group model's simplicity by keeping per receiver state during multicasts. After transmitting a multicast packet, the sender waits until a stable state is reached before sending the next one. For flow control, this slows down the sender enough so as not to swamp the slowest receiver. For error control, retransmissions are made until all receivers receive the data. This may not be possible even after multiple retransmissions, so the sender may have to treat specially some receivers, i.e. by removing them from the group. Retransmissions may be multicast when many receivers lose the initial packet, or unicast when few do. Since feedback implosion is always a possibility, all such schemes should use negative rather than positive acknowledgements, i.e. send responses when problems occur rather than confirming that packets are received correctly and in time. In a negative acknowledgement scheme, some responsibilities are moved to the receivers, complicating their operation. Nevertheless, distributing such overhead to all receivers rather than performing everything at the sender can lead to higher throughput rates[49]. The scalability of such schemes is doubtful however, even for very reliable links and rare congestion or overflow problems, as the sender is still the control center, and especially since with a growing number of group members, receivers and network paths become more heterogeneous. With these schemes, the service provided to a group member is the lowest common denominator, which may be the slowest or most overloaded receiver, or the slowest or most congested network link. Sophisticated approaches exist that follow these general directions[50][51], but their complexity and inefficiency makes them appropriate only for applications which absolutely require universal reliability and uniform member treatment[52]. Note that such reliable solutions can be implemented as transport services[53] over a simple connectionless network service[54].
A third solution is to distribute the feedback control mechanism over the
whole multicast tree, and follow a hierarchical scheme. A receiver's
feedback need not propagate all the way to the sender.
Instead, intermediate nodes
may either respond directly or merge the feedback from many downstream
receivers to a summary message and then recursively propagate it upwards.
This approach is based on a hop-by-hop protocol, so it has to be provided
at or close to the network layer, but the actual decisions on how to act
on the feedback may be taken by the sender, with feedback information
simply merged until
it reaches the sender. In this case, the feedback implosion is avoided in
terms of messages, but the problem of dealing with possibly conflicting
requests remains. If the added complexity of making local decisions
on each network node is acceptable,
we can narrow down the impact of problems to specific
parts of the tree, relieving
the sender from dealing with individual receivers. Since the current trend
in networks is to minimize node complexity, it seems that the
hierarchical approach will be used either for simple protocols that
only summarize information forwarded to the sender,
or for more complex protocols that are activated
only infrequently during a session[17].
A fourth solution tries to minimize the need for feedback, by taking preventive action rather than corrective action. For error control, this is achieved by using forward error correction codes (FEC)[55][56] rather than simple error detection codes. For flow and congestion control, this is achieved by advance resource reservations[17] so that both receivers and intermediate network nodes are always able to support the sender's data rate. The motivation for these approaches is that they are better than doing nothing, but simple enough to be efficiently implemented. FEC is the simplest part, since it only requires some processing and transmission overhead and no additional mechanisms in the network. Resource reservation on the other hand needs additional control mechanisms to set up a session (and probably, also during the session's lifetime). However, these costs will be a small fraction of the total costs (in the case of FEC) and only infrequently incurred (in the case of reservations), compared to other complex feedback mechanisms. The combination of error correction and reservations may be an adequate solution to the expected problems created by the statistical multiplexing of high burstiness and high bandwidth signals, even though these mechanisms are not expected to be both completely reliable and efficient in resource usage.