Reliable Multicast Group

1. Reliable Multicast Group Neelofer T. CMSC 621

2. What is Reliable Multicasting? • Reliability could mean messages are delivered: • To each process • In same order • In timely manner • No duplicates • Ensure reliability when • Processes enter/leave the group • Processes fail while communicating

3. Small Scale Group • For small scale group: • Reliable, connection oriented, point-to-point connections are feasible • Messages have sequence numbers • Messages received in order • Receivers acknowledge messages • Request retransmission of missing messages • Sender keeps message in buffer till acknowledgement received

5. Large Scale Group • Issues with simple ACK based, point to point approach: • Feedback implosion • Receivers spread over WANs • Congestion due to repair messages

6. Reliable Multicasting Challenges • Reliable multicasting can cause more network congestion: • Than unicast group, because large amounts of data are transmitted to recipients distribute over WAN • Than unreliable multicast group, because of additional control messages ensuring reliability • Protocol • TCP is point-to-point • Multicast is not connection oriented • UDP does not provide reliability • Applications have to offer reliability (over UDP)

7. NACK based approach • Receiver sends feedback only for missing message • Issues: • No guarantee of removal of feedback implosion • Sender is not aware of message having been delivered to entire group • Sender forced to keep transmitted messages in buffer “forever” to resolve retransmission requests

8. Non-Hierarchical Feedback control • Approach: • Message loss detected by wide area application • Receivers only report missing messages • Feedback is multicast to group • Any other message will then suppress its feedback for the same message • Retransmission request is thus sent after random delay • Strengths: • Controls feedback implosion, thus scaling well

9. Weaknesses: • Synchronizing feedback of multiple receivers requires scheduling or timers across the WAN • Multicast feedback affects processes which have received the message

10. SRM (Scalable Reliable Multicast) • Improves scalability of Non hierarchical feedback control • Receivers help each other • Receiver multicasts retransmission request after a specific time period • Closest neighbor with requested data will multicast the message • Distant neighbors timeout later than the closest ones • If data is not retransmitted by any other node when a node timesout, then a node multicasts the data • All nodes are required to cache data

11. Hierarchical Feedback Control • RMTP (reliable multicast transport protocol) • Receivers partitioned into sub groups • Group has only one sender • Sub groups are subsequently organized as a tree • Sender’s sub group forms the tree node • Designated receivers act as coordinators for sub-groups • Any reliable multicast protocol used for each sub group with the DR being a virtual sender • DR maintains local buffer • DR sends retransmission request for missing message to parent node’s DR • DRs retransmit data to sub-group • DR deletes message from buffer when all receivers in sub groups and all children acknowledge it

13. Advantages: • Scales well • Hierarchy of DRs reduces load on original sender • Issues: • Tree construction • Trees also need to be modified dynamically • Implementing an approach to use any existing underlying network tree is not easy

14. PGM (Pragmatic General Multicast) • Routers act as Designated receivers • Hence easy to scale • Simple • NACK based protocol • NACKs are unicast from receiver to nearsest router to routers along the way to the sender • Sliding window of cached data at sender discarded after a time duration • Ensures that all receivers can get reliable, ordered, duplicate data or can detect message loss • Suited for applications where messages can join and leave group at any time

15. MFTP (Multicast FTP) • Approach: • Provides reliable multicast of bulk data transfer without time constraint • Similar to RMTP • Also includes group setup protocol • Packet size is as large as possible with each packet having multiple data packets • Receivers collect all NACKs together and send to sender • Sender resends only the packets that were NACKed by all receivers, in second pass • Process continues till all receivers have all packets

16. Advantages: • Minimum control message flow • Data is sent at the rate of the network capacity • Scales well • Supports one hop networks like satellite networks too with high scalability • Weakness • Cannot be used for applications like high timing constraints

17. ALC with FEC • Receiver applications belong to various layers based on their data transfer rates • Sender creates and sends packets based on the receiver’s data rate • Receiver initiates communication and reconstructs objects from the packets • Receivers join channels to receive data • Parity packets generated which are used for repairs only • On an average provides 2:1 load reduction due to congestion control

18. Atomic Multicast • Reliability in presence of process failures: • Messages sent to all processes or none • All messages sent in same order to all processes • When a process crashes while processing a message, all the remaining processes: • Either process the message • OR Discard it • When the crashed process comes up: • No more processes are multicast till that process is completes registration with the group • Newly registered process is easily updated with the group state

19. Virtual Synchrony • A message is associated with the group view of the sender • Group view is the list of processes the sender had when multicasting the message • All processes in the group have the same view • View changes when a process enters or leaves the group • No multicast can pass across a view change • All messages in transit when a view change takes place are either completed before the change takes effect or disacrded

21. Message Ordering • Unordered multicasts • Messages can be delivered in any order

22. FIFO-ordered multicasts • Messages from same process delivered in same order

23. Causally-ordered multicasts • Message causality is maintained • Can be implemented using vector timestamps • Totally-ordered multicasts • Messages to all group members delivered in same order • Ordering of messages from a sender can be in any one of the above three ways

24. Conclusion • Scalable reliable multicast with congestion control is an active research area for the Reliable Multicast Research Group (RMRG) in the Internet Research Task Force (IRTF) • One of the reliability constraints is usually sacrificed • Protocols used based on application needs • Sender initiated protocols • Do not scale well • Have lower throughput • End to end latency worsens • Has to maintain state for receivers

25. References • Tanenbaum and Steen, “Distributed Systems Principles and Paradigms” • Internet Research Task Force, Reliable Multicast Research Group http://www.irtf.org/charter?gtype=old-rg&group=rmrg • Adamson et al, “NACK-Oriented Reliable Multicast Protocol (NORM)”, RFC 3940 • Adamson et al, “NACK-Oriented Reliable Multicast Protocol (NORM)”, Internet draft draft-ietf-rmt-pi-norm-00.txt • Speakman et al,“PGM Reliable Transport Protocol Specification”, RFC 3208 • Luby et al, “Asynchronous Layered Coding (ALC) Protocol Instantiation”, Internet draft draft-ietf-rmt-pi-alc-revised-05.txt • Appala, Austen, “AN EVALUATION OF RELIABLE MULTICAST PROTOCOLS”, Proc. IEEE Southeastcon, pp. 165-168, 1999

26. Adamson, Roca, “Security and Reliable Multicast Transport Protocols: Discussions and Guidelines”, Internet draft draft-ietf-rmt-sec-discussion-00.txt • Paul, S., Sabnani, K. K., Lin, J. C., and Bhattacharyya, S. “Reliable Multicast Transport Protocol (RMTP)” IEEE Journal on Selected Areas in Communications, April 1997 • Peled and Vardi, “Formal Techniques for Networked and Distributed Systems” • http://rmt.motlabs.com/ • C. Kenneth Miller, “Reliable Multicast Protocols and Applications”, The Internet Protocol Journal - Volume 1, No. 2 • Gemmel et al, “The PGM Reliable Multicast Protocol” • Wu, “Verification analysis of Reliable Multicast protocol”

27. ???