The difference between multicasting and separately unicasting data to several destinations is best captured by the host group model: a host group is a set of network entities sharing a common identifying multicast address, all receiving (traditionally, via best effort service) any data packets addressed to this multicast address, by senders that may not be members of the group and have no knowledge of the group's membership[32]. This definition implies that the behavior of the group over time is unrestricted in multiple dimensions; it may have local (LAN) or global (WAN) membership, be transient or pervasive in time, have constant or varying membership. From the sender's point of view, this model reduces the multicast service interface to a unicast one; this implies that the network software is accordingly burdened with the task of managing the multicasts in a manner transparent to the users. From the network designer's point of view, this extra work is expected to result in a more efficient usage of resources; this is the primary motive for network providers to support multicasting in the first place.
These requirements for multicast service impose specific requirements for the network implementation. First, there must be the means for routing packets from a sender to all group members whenever the destination address of a packet is a multicast one, which implies that the network must locate all members of the relevant group and make routing arrangements. Second, since group membership is dynamic, the network must also continuously track current membership during a session's lifetime, which may be a short or very long period of time. Tracking is required both to start forwarding data to new group members and for stopping the wasteful transmission of packets to destinations that have left the group. Both tasks must be carried out without assistance from the sending entity as defined by the host group model.
Another set of issues is concerned with extending the feedback mechanisms employed by unicast oriented protocols to deal with flow, congestion and error control. Many protocols adapt their behavior according to the prevailing network conditions at any given point in time, by measuring loss and error rates as experienced by receivers, especially in networks based on best effort services. Such protocols are typically based on end-to-end exchange of reports that describe reception statistics; these are then used by the sending side to estimate the network conditions and then modify its behavior accordingly. When extending these protocols for multicasting, there is the possibility of feedback implosion when many receivers send such reports towards the sender[33], thus swamping the network and the receiver with control information. Apart from the obvious scalability problems of such schemes, there is also the issue of how to adapt the sender's behavior when conflicting reports arrive from the various receivers.