As well as performance and failure modes, N-way reliable protocols can have different service models. We could support reliable 1-n, reliable n-1 and reliable n-m.
Applications such as software distribution are cited as classic 1-n requirements. Telemetry is given as a n-1 reliable protocol. Shared whiteboards are cited as examples of n-m.
Now the interesting thing is to look at the reliability functions needed in these. 1-n and n-1 are effectively simplex bulk transfer applications. In other words, the service is one where reliability can be dealt with by "rounding up' the missing bits at the end of the transfer. Since this need not be especially timely, there is no need for this to be other than end to end, and application based. 3.6
On the other hand n-m processes such as whiteboards need timely recovery from outages. The implication is that the "service' is best done somewhat like the effect of having n*n-1/2 TCP connections. If used in the WAN, the recovery may best be distributed, since requests for recovery will implode down the very links that are congested or error prone and caused the need for recovery.
Now there are different schemes for creating distributed recovery. If the application semantics are that operations (ALF packetsworths...) are sequenced in a way that the application can index them, then any member of a multicast session can efficiently help any other member to recover (examples of this include mark Handley's Network Text tool...). On the other hand, packet-based recovery can be done from data within the queues between network/transport and application, if they are kept at all members in much the same way as a sender in a unicast connection keeps a copy of all un-acknowledged data. The problem with this is that because its multicast, we don't have a positive acknowledgment system. Because of that, there is no way to inform all end points when they can safely discard the data in the 'retransmit' queue. Only the application really knows this!
Well, this is not to say that there isn't an obvious toolkit for reliable multicast support - it would certainly be good to have RTP style media timestamps (determined by the application, but filled in by the system). It would be good to have easy access to a timestamped based receive queue so applications could use this to do all the above. It might be neat to have virtual token ring, expanding ring search, token tree and other toolkits to support retransmit 'helper' selection....
So, drawing a table of where we might put functions to provide reliability (retransmit), sequencing and performance (adaptive playout say versus end to end, versus hop by hop delay constraint), we can see the following picture:
We will look at this further in chapter 5.