Reliable Multicast Design issues and features

• When to start reading packets from the multicast address
  Once the join and the request have been sent it is unclear whether waiting for the HTTP Req Ack is more important than accepting the multicast packets. We have chosen to wait for the Ack from the server before accepting the multicast packets. This is primarily because we do not intend to buffer the HTTP response within the flow.
• Reliability
  The underlying transport protocol is only partially reliable. It does not guarantee that a message will get delivered to all the end clients. This would not be acceptable for the application in consideration. Therefore in our design we add an additional layer of reliability to handle messages that are not received. All messages have application level sequence numbers. The server periodically broadcasts the name of the object that is being multicast, the number of segments and the starting, ending and current sequence numbers. The proxy then detects missing sequence numbers and sends requests to the server requesting retransmission.
• Late Join
  When a proxy receives an HTTP ACK, we have two choices. The station can wait for the start of the file or start receiving packets immediately and request the rest of the packets. Joining at any point in the session would be more efficient but will have extra overhead. We choose to go with joining at any point in the session. The client will start looking for the control packet and will start receiving packets from that point. For small files the server would put the control packets only in the beginning of the file. This way the stations would get all the packets in sequence if there are no errors. However for large packets where it would be inefficient to wait, the server will insert the control packets periodically and this period is configurable. This allows the proxy to buffer the flow, and do an early leave from the group.
• HTTP ACK Pause Time
  When the server finishes multicasting the file, it waits for a certain amount of time to wait for all the proxy to send back URL ACK message back to the server. If at the end of this pause time all clients have acknowledged the complete receipt of the message the server stops multicasting the packets. Otherwise, the server starts retransmitting the message again. Currently this timeout is a fixed value of 1 s. This needs to be made a function of the largest RTT among all the proxies and the number of proxies listening to the multicast session.