Reliable Multicast Protocol

The Reliable multicast protocol runs over UDP and uses the IP multicast [1] service for packet delivery. Since both IP multicast and UDP are unreliable protocols, the reliability is achieved by running an end to end reliable protocol at the application level. We use a framing protocol like the one suggested in [2] for exchanging state information through application layer headers. To achieve reliability, packets with errors or lost packets will be retransmitted, using a sliding window protocol based on feedback from the stations. We evaluated several existing Reliable Multicast protocols and chose MTP-2 proposed by researchers at Technical University Berlin [4] in RFC1301 [5]. A good description of the multicast socket interface can be seen in [6].

We decided to choose this multicast transport protocol because it gave us a good programming interface (similar to the socket interface), and because it was easy to build upon to develop our application and add additional features over it. Features of this protocol are explained below. We have added features like Reliability, URL acknowledgment and late join and leave to this protocol. These additional features are explained in detail in the section on design issues and decisions.

• Partial Reliability
  This protocol guarantees that at least one particular host chosen as "master" receives a message error free. This is not sufficient for our application and therefore we build on this partial reliability by using application level sequence numbers and a per receiver acknowledgment.
• Negative Acknowledgments
  In this protocol only NACKs are transmitted. In all reliable multicast protocols ACK implosion is a serious problem because if there are N users and each of these N station sends an ACK back to the server, there will be typically N ACK's per packet which will severely cripple the performance of the server. Many solutions have been proposed for this problem. One of those is for the stations to only send NACKs for packets not received. On error free links ( which is the case with current Internet) far fewer packets are returned to the server, which is the solution chosen in this implementation.
• Concept of Master
  A single station among all the receivers is chosen as the master . This master decides when the message transmission is complete. It also controls which stations to allow to join the multicast group. Each station, when it joins the group will try to become the master . If another station is already chosen as the master then the new station can request to be the master or just join the group. If the master receives the message error free, the packet is assumed to be delivered to all hosts, which only provides partial reliability in the protocol. If we migrate the master to the station on the slowest and error-prone link this will achieve near reliability.

• Reliable Multicast Design issues and features
• Client-side Multicast API
• Server-side Multicast API