1. Multicast Communication

2. Unicast vs. Multicast

3. Multicast Whereas the majority of network services and network applications use unicast for IPC, multicasting is useful for applications such as: online conferences, interactive distance learning, and can be used for applications such as online auction. It can also be used in replication of services for fault tolerance.

4. Mutlicast group In an application or network service which makes use of multicasting, a set of processes form a group, called a multicast group. Each process in a group can send and receive message. A message sent by any process in the group can be received by each participating process in the group. A process may also choose to leave a multicast group. In an application such as online conferencing, a group of processes interoperate using multicasting to exchange audio, video, and/or text data.

5. 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

6. Reliable Multicast vs. Unreliable Multicast When a multicast message is sent by a process, the runtime support of the multicast mechanism is responsible for delivering the message to each process currently in the multicast group. Due to factors such as failures of network links and/or network hosts, routing delays, and differences in software and hardware, the time between when a unicast message is sent and when it is received may vary among the recipient processes.

7. Reliable Multicast vs. Unreliable Multicast Moreover, a message may not be received by one or more of the processes at all, due to errors and/or failures in the network, the machines, or the runtime support. Whereas some applications, such as video conferencing, can tolerate an occasional miss or misordering of messages, there are applications – such as database applications – for which such anomalies are unacceptable. Therefore, when employing a multicasting mechanism for an application, it is important that you choose one with the characteristics appropriate for your application. Otherwise, measures will need to be provided in the coding of the application in order to handle the anomalies which may occur in message delivery.

8. 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)

9. Classification of multicasting mechanisms in terms of message delivery -1 Unreliable multicast: At its most basic, a multicast system will make a good-faith attempt to deliver messages to each participating process, but the arrival of the correct message at each process is not guaranteed. In the best case, the correct message is received by all processes. In some cases, the message may be received by some but not all, The messages may be received by some processes in a corrupted form. Such a system is said to provide unreliable multicast.

10. Classification of multicasting mechanisms in terms of message delivery - 2 Reliable multicast: A multicast system which guarantees that each message is eventually delivered to each process in the group in uncorrupted form is said to provide reliable multicast.

11. Classification of multicasting mechanisms in terms of message delivery - 3 The definition of reliable multicast requires that each participating process receives exactly one copy of each message sent. However, the definition places no restriction on the order that the messages are delivered to each process: each process may receive the messages in any permutation of those messages. For applications where the order of message delivery is significant, it is helpful to further classify reliable multicast systems based on the order of the delivery of messages.

12. Reliable Multicast Integrity: A correct (i.e., non-faulty) process p in a group(m) delivers a multicast message m at most once. –Safety property: any message delivered is identical to the one that was sent Validity: If a correct process multicasts (sends) message m, then it will eventually deliver m. –Guarantees liveness to the sender. –Liveness property: any message is eventually delivered to destination Agreement: If a correct process delivers message m, then all the other correct processes in group(m) will eventually deliver m. –Property of “all or nothing.” –Validity and agreement together ensure overall liveness: if some correct process multicasts a message m, then all correct processes deliver m too.

13. Reliable Multicast Algorithm R-multicast B-multicast reliable unicast “USES”

14. Reliable Multicast Algorithm (R-multicast) Integrity Agreement if some correct process B-multicasts a message m, then, all correct processes deliver m too. If no correct process B-multicasts m, then no correct processes deliver m. Integrity, Validity

15. Classification of reliable multicast Unordered An unordered reliable multicast system provides no guarantee on the delivery order of the messages. Example: Processes P 1, P 2, and P 3 have formed a multicast group. Further suppose that three messages, m 1, m 2, m 3 have been sent to the group. Then an unordered reliable multicast system may deliver the messages to each of the three processes in any of the 3! = 6 permutations (m 1 -m 2 -m 3, m 1 -m 3 -m 2, m 2 -m 1 -m 3, m 2 -m 3 -m 1, m 3 -m 1 -m 2, m 3 -m 2 -m 1). Note that it is possible for each participant to receive the messages in an order different from the orders of messages delivered to other participants.

16. Ordered Multicast FIFO ordering: If a correct process issues multicast(g,m) and then multicast(g,m’), then every correct process that delivers m’ will have already delivered m. Causal ordering: If multicast(g,m)  multicast(g,m’) then any correct process that delivers m’ will have already delivered m. Total ordering: If a correct process delivers message m before m’, then any other correct process that delivers m’ will have already delivered m.

17. Total, FIFO and Causal Ordering Totally ordered messages T 1 and T 2. FIFO-related messages F 1 and F 2. Causally-related messages C 1 and C 3 Causal ordering implies FIFO ordering Total ordering does not imply causal ordering. Causal ordering does not imply total ordering. Hybrid mode: causal-total ordering, FIFO-total ordering. Totally-ordered FIFO-ordered Causal- ordered

18. Example: Display From Bulletin Board Program Bulletin board: os.interesting Item FromSubject 23A.HanlonMach 24G.JosephMicrokernels 25A.HanlonRe: Microkernels 26T.L’HeureuxRPC performance 27M.WalkerRe: Mach end What is the most appropriate ordering for this application? (a) FIFO (b) causal (c) total Post to Bulletin Board User 1 Post to Bulletin Board User 2

19. FIFO-ORDERED MULTICAST

20.  Process messages from each process in the order they were sent:  Each process keeps a sequence number for each other process.  Messages are sent with local sequence number  When a message is received, as expected (next sequence), accept higher than expected, buffer in a queue lower than expected, reject Providing Ordering Guarantees (FIFO) If Message# is

21. Hold-back Queue for Arrived Multicast Messages: received yet undelivered messages Message processing Delivery queue Hold-back queue deliver Incoming messages When delivery guarantees are met FO-deliver

22. Implementing FIFO Ordering (FIFO-ordered multicast) S p g : count of messages p has sent to g. R q g : the recorded sequence number of the latest message that p has delivered from q to the group g. For p to FO-multicast m to g –p increments S p g by 1 –p “piggy-backs” the value S p g onto the message. –p B-multicasts m to g. At process p, upon receipt of m from q with sequence number S: –p checks whether S= R q g +1. If so, p FO-delivers m and increments R q g –If S > R q g +1, p places the message in the hold-back queue until the intervening messages have been delivered and S= R q g +1. –If S < R q g +1, then drop the message (we have already seen the message)

23. Example: FIFO Multicast P1 P2 P3 0 0 0 Physical Time 1 0 0 2 0 0 1 0 0 2 0 0 2 1 0 0 0 0 2 1 0 0 0 01 0 0 2 1 0 1 1 1 2 2 1 1 Reject: 1 < 1 + 1 Accept 1 = 0 + 1 Accept: 2 = 1 + 1 2 0 0 Buffer 2 > 0 + 1 Accept: 1 = 0 + 1 2 0 0 Accept Buffer 2 = 1 + 1 Reject: 1 < 1 + 1 Accept 1 = 0 + 1 Sequence Vector for P1 (do NOT confuse with vector timestamps) 0 0 0 S1gS1g R2gR2g R3gR3g R1gR1g S2gS2g R3gR3g Sequence Vector for P2

24. Classification of reliable multicast - 2 10/27/2015 24 FIFO multicast A system which guarantees that the delivery of the messages adhere to the following condition is said to provide FIFO (first-in-first-out) or send-order multicast: If process P sent messages m i and m j, in that order, then each process in the multicast group will be delivered the messages m i and m j, in that order. Suppose P 1 sends messages m 1, m 2, and m 3 in order, then each process in the group is guaranteed to have those messages delivered in that same order: m 1, m 2, then m 3.

25. Classification of reliable multicast - 2 10/27/2015 25 Note that FIFO multicast places no restriction on the delivery order among messages sent by different processes. To illustrate the point, let us use a simplified example of a multicast group of two processes: P 1 and P 2. Suppose P 1 sends messages m 11 then m 12, while P 2 sends messages m 21 then m 22. Then a FIFO multicast system can deliver the messages to each of the two processes in any of the following orders: m 11 -m 12 -m 21 -m 22, m 11 -m 21 -m 12 -m 22, m 11 -m 21 -m 22 -m 12, m 21 -m 11 -m 12 -m 22 m 21 -m 11 -m 22 -m 12 m 21 -m 22 -m 11 -m 12.

26. CAUSAL-ORDERED MULTICAST

27. Causal Multicast Let us focus on multicast group g Each process iєg maintains a vector V g i of length |g| where –V g i [j] counts the number of group g messages from j to i Messages multicast by process i are tagged with the vector timestamp V g i Recall rule for receiving vector timestamps Max(V receiver [j], V message [j]), if j is not self V receiver [j] + 1otherwise i.e. when process i receives a from j, then –V g i [k] = max(V g i [k], V g j [k]) if k ≠ i –V g i [k] = V g i [k] + 1 if k = i Remember V(a) < V(b) iff a happens before b V receiver [j] =

28. Causal Ordering using vector timestamps The number of group-g messages from process j that have been seen at process i so far Guarantees Causal ordering

29. Example: Causal Ordering Multicast P1 P2 P3 Physical Time (1,1,0) Reject: Accept 0,0,0 1,0,0 1,1,0 1,0,0 Buffer missing P1(1) (1,1,0) >(1,0,0) 1,1,0 Accept 1,0,0 Accept Buffered message 1,1,0 (1,0,0) (1,1,0) Accept

30. Causal Order Multicast – example1 10/27/2015 30 Suppose three processes P 1, P 2, and P 3 are in a multicast group. P 1 sends a message m 1, to which P 2 replies with a multicast message m 2. Since m 2 is triggered by m 1, the two messages share a causal relationship of m 1 -> m 2. Suppose the receiving of m 2 in turn triggers a multicast message m 3 sent by P 3, that is, m 2 -> m 3. The three messages share the causal relationship of m 1 -> m 2 -> m 3. A causal-order multicast message system ensures that these three messages will be delivered to each of the three processes in the order of m 1 - m 2- m 3.

31. Causal Order Multicast – example2 10/27/2015 31 As a variation of the above example, suppose P 1 multicasts message m 1, to which P 2 replies with a multicast message m 2, and independently P 3 replies to m 1 with a multicast message m 3. The three messages now share these causal relationships: m 1 - > m 2 and m 1 -> m 3. A causal-order multicast system can delivery these message in either of the following orders: m 1 - m 2 - m 3 m 1 - m 3 - m 2 since the causal relations are preserved in either of the two sequences. In such a system, it is not possible for the messages to be delivered to any of the processes in any other permutation of the three messages, such as m 2 - m 1 - m 3 or m 3 - m 1 - m 2, the first of these violates the causal relationship m 1 -> m 2, while the second permutation violates the causal relationship m 1 -> m 3.

32. TOTAL-ORDERED MULTICAST

33. 1 st Method - Using Sequencer Delivery algorithm similar to FIFO Except that processes maintain group specific sequence number (as opposed to process specific sequence number) Sender attaches unique id ‘i’ to each message m and sends to the sequencer(g) as well as to group g Sequencer maintains group specific sequence number S g (consecutive and increasing) and B- multicasts order messages to g

34. Total Ordering Using a Sequencer (Method 1) P1 sequencer P3 P2 SgSg, S g +1 rgrg rgrg unique msg id - Single point of failure - Bottleneck Group g: P1, P2, P3 Sequencer (g) :

35. 2 nd Method - ISIS Algorithm Processes collectively agree on sequence numbers (priority) in three rounds Sender sends message m with its id to all receivers; Receivers suggest priority (sequence number) and reply to sender with proposed priority; Sender collects all proposed priorities; decides on final priority (breaking ties with process ids), and resends the agreed final priority for message m Receivers deliver message m according to decided final priority

36. ISIS algorithm for total ordering (Method 2) 2 1 1 2 2 1 Message 2 Proposed Seq P 2 P 3 P 1 P 4 3 Agreed Seq 3 3 Group g: P1, P2, P3, P4

37. ISIS algorithm for total ordering 1.sender p B-multicasts with message m and unique id i to everyone. 2.On receiving m (first time) 1.m is added to a priority queue and tagged as undeliverable 2.reply to sender with proposed priority, i.e., a sequence number »seq number = 1 + largest seq number heard so far, suffixed with the recipient’s process ID 3. priority queue is always sorted by priority 3.Sender 1.collects all responses from the recipients, 2.calculates their maximum, and 3.re-multicasts (B-multicast) original message with this as the final priority for m 4.On receiving m (with final priority) 1. mark the message as deliverable, 2.reorder the priority queue, and 3.deliver the set of lowest priority messages that are marked as deliverable.

38. Proof of Total Order (By Contradition) For m 1, consider the first process p that delivers m 1 –At p, let m 1 have the agreed sequence number (finalpriority(m 1 )) and marked deliverable (at the front of the hold-back priority queue) –Let m 2 be another message that has not yet been delivered »i.e., m 2 is on the same queue (it has not been assigned its sequence number) or has not been seen yet by p –Then »finalpriority(m 2 ) ≥ proposedpriority(m 2 ) due to: “max” operation at sender & »proposedpriority(m 2 ) ≥ final priority (m 1 ) due to: proposed priorities by p only increase (m 1 is ahead of the queue) Suppose there is some other process q that delivers m 2 before it delivers m 1. Then at q –Finalpriority(m1) ≥ proposedpriority(m1) ≥ finalpriority (m2) Contradiction !

39. Atomic Multicast Example 10/27/2015 39 P 1 sends m 1 then m 2. P 2 replies to m 1 by sending m 3. P 3 replies to m 3 by sending m 4. Although atomic multicast imposes no ordering on these messages, the sequence of the events dictates that P 1 must be delivered m 1 before sending m 2. Likewise, P 2 must receive m 1 then m 3, while P 3 must receive m 3 before m 4. Hence any atomic delivery order must preserve the order m 1- m 3- m 4. The remaining message m 2 can, however, be interleaved with these messages in any manner. Thus an atomic multicast will result in the messages being delivered to each of the processes in one of the following orders: m 1- m 2- m 3- m 4, m 1- m 3- m 2- m 4, or m 1- m 3- m 4- m 2. For example, each process may be delivered the messages in this order m 1- m 3- m 2- m 4,.