Distributed Systems Multicast & Group Communication Services

Transcription

1 Distributed Systems Multicast & Group Communication Services Department of Computer Science The Johns Hopkins University 1 Multicast & Group Communication Services Lecture 3 Guide to Reliable Distributed Systems (Birman). Also: slides and resources can be found at: IP Multicast is documented in IETF RFC s and Internet-Drafts which can be found at: 2

2 The Multicast Paradigm a c P a a b c b d a P a P P P P P P Ordering (Unordered, FIFO, Causal, Agreed). Delivery guarantees (Unreliable, Reliable, Safe/Stable). Open groups versus close groups. Failure model (Omission, Fail-stop, Crash & Recovery, Network Partitions). Multiple groups. 3 Using Traditional Transport Protocols for Multicast Point to point (TCP/IP) Automatic flow control Reliable delivery Connection service 2 Complexity (n ) Linear (?) degradation in performance 4

3 Using Traditional Transport Protocols for Multicast (cont.) Unreliable broadcast/multicast (UDP, IP-Multicast) Employs hardware support for broadcast and multicast. Message losses : 0.01% at normal load, 10%, 20%, 30% or more at high load. Buffers overflow (in the network and in the OS). Interrupt misses. Not a connection-oriented service. 5 IP Multicast Multicast extension to IP. Best effort multicast service. No accurate membership. Class D addresses are reserved for multicast: to and are used as group addresses. The standard defines how hardware Ethernet multicast addresses can be used if these are possible. The Internet 6

4 IP-Multicast Logical Design Network 2 Network 1 The Internet 7 IP Multicast (cont.) Extensions to IP inside a host: A host may send IP multicast by using a multicast address as the destination address. A host manages a table of groups and local application processes that belong to this group. When a multicast message arrives at the host, it delivers copies of it to all of the local processes that belong to that group. A host acts as a member of a group only if it has at least one active process that joined that group. 8

5 IP Multicast Group Management Extensions to IP within one local area network The Internet Group Management Protocol (IGMP) A host that joins a group transmits a report message to IP multicast address (all hosts group) A multicast router sends periodic general query messages to discover IP multicast groups with local hosts to A host replies after setting a random timer for each group it is a member of The host sends a report message for that group only if no other host replied by the random timer expiration. 9 IP Multicast Group Management Extensions to IP within one local area network The Internet Group Management Protocol (IGMP) cont. When the host that replied last leaves the group, it sends a Leave Group message on IP multicast address (all routers group). The multicast router then sends a group specific query to check whether there are additional members in the group After a timeout with no positive host responses for a certain group, the IP Multicast router stops participating in that group (beyond the local area network) 10

6 IP-Multicast Routing Extensions to IP between routers in one network Distance Vector Multicast Routing Protocol (DVMRP, PIM-DM) Messages ABOUT groups are sent on the special all hosts group Time to live: limits the distance messages travel. Dense method: Flood & Prune. All routers get packets initially, then prune out parts of the network that do not have group member hosts. Tunneling: encapsulates multicast packets in regular packets in order to pass through routers that do not support IP Multicast. 11 IP-Multicast Routing (cont.) IP Multicast between routers in one network PIM-SM Sparse Method for better scalability only routers that participate, or are on the way to routers that participate, get IP multicast messages In contrast to Dense Method that employs Flood and Prune Utilizes rendezvous points for each group Rendezvous point router is determined via hashing the group address into a list of possible RP routers in the network (maintained by a bootstrap router) 12

7 IP-Multicast Routing(cont) PIM-SM (Sparse Method) Join Operation Join Request Join Confirm 13 IP-Multicast Routing(cont) IP Multicast between routers in one network MOSPF Extensions to Open Shortest Path First the link state routing protocol common in the Internet Group membership of local areas in the network is based on IGMP and is flooded between the routers on the network. Shortest path trees are calculated on demand for each source to each group (of destinations) it participates on Can work with inter-as Multicast Routing (MBGP+) to support IP Multicast operation beyond a single network (beyond an AS Autonomous System) 14

8 IP Multicast Challenges Scalability with the number of applications / groups. How many groups are needed on a world-wide basis? What happens to the core routers with many global groups? Turned off by ISPs. Can you think why? What can be done about that? 15 IP Multicast Challenges Scalability with the number of applications / groups. How many groups are needed on a world-wide basis? What happens to the core routers with many global groups? Turned off by ISPs. Can you think why? What can be done about that? Private networks using IP multicast e.g. for IPTV Overlay networks using unicast. 16

9 The Overlay Networks Approach Application-level routers working on top of a physical network. Overlay links consist of multiple physical links. Incurs overhead. Placement of overlay routers not optimal. Flexible use of peer-protocols. Provides added value. Actual node in the physical network Actual overlay network daemon Overlay network node Physical network link Physical link used by the overlay network Virtual overlay network link 17 Multicast Using Overlay Networks Routing is not optimal. But functional and does not require state at intermediate routers just at overlay routers. Multiple overlay networks can coexist in the Internet without overhead to Internet routers. All the multicast traffic is seen as unicast packets at the network level. No need for hardware support. Group names space extends only to the scope of the application (no longer global). 18

10 Reliable Multicast Services Service-Type S A F E A G R E E D C A U S A L Cost (latency) F I F O R E L I A B L E 19 Reliable Multicast Services (cont.) Fifo Order cause m --> m if send (m) --> send (m ) Causal Order cause m --> m if deliver (m) --> send (m ) Agreed Order q q - Total order - Consistent with Causal order and overlapping groups Safe Delivery - Consistent with Agreed order - Message is delivered after received by all processors 20 q * Not ordering q

11 Multicast Protocols Outline Vector Timestamps (ISIS System) Trans Protocol (used by Transis) Lamport Timestamps Single Ring Protocol (Totem) Accelerated Ring Protocol (Spread) 21 Vector Time Stamp: Reliability and Causal Ordering (ISIS system) Each process maintains a time vector of size n. Initially VT[i] = 0. When p sends a new message m: VT[p]++ Each message is stamped with VTm which is the current VT of the sender. When p delivers a message, p updates its vector: for k in 1..n: VTp[k] = max{ VTp[k], VTm[k] }. 22

12 Isis Causal Order (Cont) Comparing messages: VT1<VT2 iff for k= 1..n VT1[k] VT2[k] and k VT1[k]<VT2[k] Determining causality: m1 m2 iff VT1<VT2 Determining whether a message sent by q can be delivered: for any k in 1..n: VTm[k] = VT[k]+1 if k=q. VTm[k] VT[k] otherwise. 23 Example 1 p 1,0,0 0,1,0 Time q 0,1,0 1,0,0 r 0,1,0 1,0,0 Messages {1,0,0} and {0,1,0} are not causally related, so they can be delivered in any order 24

13 p Example 2 1,0,0 1,1,0 Time q 1,0,0 1,1,0 r 1,1,0 1,0,0 1,1,0 Message {1,0,0} causally precedes {1,1,0}, so {1,0,0} must be delivered before {1,1,0} 25 Example 3 p 1,0,0 1,1,0 0,0,1 Time q 1,0,0 1,1,0 0,0,1 r 1,1,0 0,0,1 1,0,0 1,1,0 A process does not update its timestamp until it delivers a message, so r sends {0,0,1}, even though it received {1,1,0} 26

14 Example 4 Time p 1,0,0 2,0,0 3,0,0 q 0,1,1 0,0,1 0,2,2 0,3,3 0,1,2 0,2,3 1,0,0 2,0,0 3,0,0 r 0,0,1 0,1,1 0,1,2 0,2,2 0,2,3 0,3,3 1,0,0 2,0,0 3,0,0 27 Example 4 Time p 1,0,0 2,0,0 3,0,0 0,1,1 0,2,2 0,3,3 0,0,1 0,1,2 0,2,3 q 0,1,1 0,0,1 0,2,2 0,3,3 0,1,2 0,2,3 1,0,0 2,0,0 3,0,0 r 0,0,1 0,1,1 0,1,2 0,2,2 0,2,3 0,3,3 1,0,0 2,0,0 3,0,0 28

15 Isis Agreed (Total) Order Preserves causality. From time to time, the token holder sends an ordering message for all the previous Agreed-order messages it knows that are not yet ordered. Non-token holders cannot deliver Causal messages that are causally after an Agreed message that is not yet ordered. A new token holder may be determined after a membership change. 29 Multicast Protocols Outline Vector Timestamps (ISIS System) Trans Protocol (used by Transis) Lamport Timestamps Single Ring Protocol (Totem) Accelerated Ring Protocol (Spread) 30

16 The Trans Protocol A B C D A Emits: A 1 A 2 A 3... Scenario: A a 1 B 1 b 1 B 2 b 2 C Direct Ack: a 1 B 1 A 1 Indirect Ack: b 2 C 1 A 1, B 1 31 Example Scenario: A B a b B a C c b C A 1 32

17 Example Scenario: A B a b B a C c b C A 1 B 1 33 Example Scenario: A B a b B a C c b C B 2 A 1 B 1 34

18 Example Scenario: A B a b B a C c b C C 1 B 2 A 1 B 1 35 Example Scenario: A B a b B a C c b C C 2 C 1 B 2 A 1 B 1 36

19 Example (Cont.) D received: A B a C c b C Nack:: c b b D C 2 D 1 C 1 B 2 A 1 B 1 37 The DAG The DAG may be revealed in a different way, but its structure will be identical at all the processors!! C 1 C 2 A 2 D 1 B 2 A 1 B 1 38

20 The DAG The DAG may be revealed in a different way, but its structure will be identical at all the processors!! C 1 C 2 A 2 D 1 Total order can be based on the structure of the graph A 1 B 1 B 2 39 Vector Timestamps vs DAG DAG is a compaction of a vector timestamp The DAG method is more efficient networkwise and can scale better with the number of participants However, the DAG requires maintaining a more sophisticated data structure 40

21 Flow Control P-2-P: Last Ack Stop 41 P-2-P: Flow Control Last Ack Stop Multicast? BOOM 42

22 Flow Control for Trans (from the Transis system) Multicast: Network Sliding Window Last All Ack Stop 43 Multicast Protocols Outline Vector Timestamps (ISIS System) Trans Protocol (used by Transis) Lamport Timestamps Single Ring Protocol (Totem) Accelerated Ring Protocol (Spread) 44

23 A Lamport Time Stamp Approach A Lamport Time Stamp (LTS) contains two fields: Counter. Process id. When sending a message. Increment your counter. Stamp your message. Send your message. When receiving a message Adopt the counter on the message if it is bigger than your local counter. Unique for every message. 45 A Lamport Time Stamp Approach A Lamport Time Stamp (LTS) contains two fields: Counter. Process id. When sending a message. Increment your counter. Stamp your message. Send your message. When receiving a message Adopt the counter on the message if it is bigger than your local counter. Unique for every message. It is useful to add an index next to the LTS, such that the index is incremented only when sending new messages. The index helps track how many messages were sent by a process as well as how many were missed from that process. 46

24 A Lamport Time Stamp Approach A Lamport Time Stamp (LTS) contains two fields: Counter. Process id. When sending a message. Increment your counter. Stamp your message. Send your message. When receiving a message Adopt the counter on the message if it is bigger than your local counter. Unique for every message. It is useful to add an index next to the LTS, such that the index is incremented only when sending new messages. The index helps track how many messages were sent by a process as well as how many were missed from that process. Agreed order of messages can be achieved by comparing (counter, process id) on message. FIFO and Causal order as a by-product. 47 Multicast Protocols Outline Vector Timestamps (ISIS System) Trans Protocol (used by Transis) Lamport Timestamps Single Ring Protocol (Totem) Accelerated Ring Protocol (Spread) 48

25 The Single Ring Protocol (Totem) The communication is multicast (UDP/IP). Services: Agreed (which is also FIFO and Causal), Safe. supports message omissions, network partitions, crashes and recoveries. 49 The Ring Ordering Scheme Token fields type - {regular, form}. seq - of last message. aru - replaces acks. rtr - retrans. requests fcc - flow control. 50

26 The Ring Ordering Scheme (cont) How to update the token aru? If token.aru = token.seq and have all the messages then should raise aru together with the seq (when sending new messages). If the token.aru is higher than the highest in-order message (local aru), lower the token.aru to the local aru. If is the one that lowered the aru, and the token.aru is still the same, should set token.aru to its local aru. The trick: Everyone has all the messages up to: min( token.aru, previous token.aru) 51 Multicast Protocols Outline Vector Timestamps (ISIS System) Trans Protocol (used by Transis) Lamport Timestamps Single Ring Protocol (Totem) Accelerated Ring Protocol (Spread) 52

27 Accelerated Ring Protocol Original Ring Protocol Token is passed around a ring of participants A participant multicasts while it holds the token, then passes the token to the next participant Accelerated Ring Protocol Participants pass the token while multicasting Circulates the token faster, allowing more rounds of sending per second Allows controlled parallelism, while maintaining semantics Designed for modern data centers 53 Accelerated Ring Protocol A" 1% 2% 3% 4% 5% 5% 16% 17% 18% 19% 20% 20% B" 6% 7% 8% 9% 10% 10% C" 11% 12% 13% 14% 15% 15% Time% Original Protocol A" 1% 2% 5% 3% 4% 5% 16% 17% 20% 18% 19% 20% B" 6% 7% 10% 8% 9% 10% C" 11% 12% 15% 13% 14% 15% Time% Accelerated Protocol 54

28 Accelerated Ring Protocol Updating token fields seq Original: sequence number of last message sent Accelerated: last sequence number claimed (message will be sent by the time the next token is processed) rtr - how do you decide what to request? Original: request any missing messages with sequence numbers less than seq Accelerated: request any missing messages with sequence numbers less than the value of seq on the token received in the previous round seq may reflect messages that are still on their way or even not yet sent; you don t want to request them unless they are really lost 55 1G Network Results Latency((ms)( 4.5" 4" 3.5" 3" 2.5" 2" 1.5" 1" Simultaneously improves throughput by 60% and latency by 45% 500 Mbps, 1.3 ms latency 800 Mbps, 0.72 ms latency Original"Spread" Original" Daemon9based" Original"Library9 based" Accelerated" Spread" Accelerated" Daemon9based" 0.5" Accelerated" Library9based" 0" 0" 200" 400" 600" 800" 1000" 1200" Agreed(Delivery(Throughput((Mbps)( 56

29 10G Network Results Latency(((ms)( 1.4" 1.2" 1" 0.8" 0.6" 0.4" Spread Original: 1 Gbps, ms latency Simultaneously improves throughput by 20% and latency by 20% Spread Accelerated: 1.2 Gbps, 0.31 ms latency 0.2" 0" 0" 1000" 2000" 3000" 4000" 5000" Agreed(Delivery(Throughput((Mbps)( 57 10G Network Results Latency(((ms)( 1.4" 1.2" 1" 0.8" 0.6" 0.4" Daemon- based Original: 2 Gbps, 0.39 ms latency Simultaneously improves throughput by 40% and latency by 30% Daemon- based Accelerated: 2.8 Gbps, ms latency 0.2" 0" 0" 1000" 2000" 3000" 4000" 5000" Agreed(Delivery(Throughput((Mbps)( 58

30 10G Network Results Latency(((ms)( 1.4" 1.2" 1" 0.8" 0.6" 0.4" 0.2" Library- based Original: 2.57 Gbps, ms latency Simultaneously improves throughput by 35% and latency by 30% Library- based Accelerated: 3.5 Gbps, 0.23 ms latency 0" 0" 1000" 2000" 3000" 4000" 5000" Agreed(Delivery(Throughput((Mbps)( 59 10G Network Results Latency(((ms)( 1.4" 1.2" 1" 0.8" 0.6" 0.4" 0.2" Library- based Original: 2.57 Gbps, ms latency Simultaneously improves throughput by 35% and latency by 30% Library- based Accelerated: 3.5 Gbps, 0.23 ms latency 0" 0" 1000" 2000" 3000" 4000" 5000" Agreed(Delivery(Throughput((Mbps)( 60

31 Latency((ms)( 1.4" 1.2" 1" 0.8" 0.6" 0.4" 10G Network Results Spread: 5.2 Gbps (8850- byte msgs) Daemon- based: 6 Gbps (8850- byte msgs) Library- based: 7.3 Gbps (8850- byte msgs) 0.2" 0" 0" 2000" 4000" 6000" 8000" Agreed(Delivery(Throughput((Mbps)( 61 10G Network Results with Loss (480 Mbps) Average'Latecny'(ms)' 3" 2.5" 2" 1.5" 1" 0.5" Accelerated Protocol Original Protocol * Lower line = beper latency Safe Delivery Worst 5% Safe Delivery Agreed Delivery Worst 5% 0" 0" 5" 10" 15" 20" 25" Loss'Rate'at'Each'Daemon'(%)' Agreed Delivery 62

32 Failure Models Possible faults: Message omissions and delays Processor crashes and recoveries Network partitions and re-merges Most of the time it is assumed that: Message corruption is detected There are no malicious faults 63 Transis Membership Algorithm Utilizes hardware broadcast Ordering and Reliability optimized by DAG Handles crashes and recoveries. Handles network partitions and merges. Terminates in a bounded time (to do that, it allows the extraction of live but inactive processors). Guarantees extended virtual synchrony (relationship between messages and membership events). 64

33 Transis Membership (cont.) Partitioning / crashes detection Timeout: invoked by timeout. Merging Symmetric: no joining-side, accepting-side Spontaneous: invoked after receiving Join messages or foreign messages. Faults may occur at any time (even while merging). 65 Faults & Partitions When Detecting a processor from which we did not hear for a certain timeout : we issue a fault message. FA(p) FA(p) When we get a fault message, we adopt it (and issue our copy). FA(p) FA(p) Problem: maybe p is only slow. 66

34 The Problem When a partition occurs, we cannot always completely determine who received which messages. It is proven that there is no solution to this problem (no common knowledge) 67 Merges time join (A,B,C) join (A,B) join (A,B,C) join (A,B,C) join (B,C) A B C 68

35 The Single Ring Protocol Membership has several stages: Detect that old membership is lost. Gather together all alive members. Form a new ring and send old state. Transfer missing messages. Install new membership. Supports message omissions, network partitions, crashes and recoveries. 69 Membership Events Foreign Message. Attempt join/ Join. Gather timeout. Commit timeout. Form token. Token loss timeout. States Operational state. Gather state. Commit state. Form state. Recover state. 70

36 Token loss timeout Gather Foreign Message Membership (cont) Token loss timeout Operational Token loss timeout Extended Virtual Synchrony Recover Attempt Join OR Join Gather timeout Commit timeout Token loss timeout Join message AND consensus AND representative Form token AND NOT representative Form token AND representative Form token Commit Form token Form Join Message Token loss AND NOT timeout (Consensus AND Representative) 71 Membership (cont..) Representatives are shown shaded 72