Communication (II) Chapter 4 4/21/2017

Topics Fundamentals Stream Multicast Overlay (application layer multicast) Application layer MC vs IP layer MC Epidemic and gossip 4/21/2017

Multicast Multicast: a source sends a message to the subset of network nodes (say a multicast group) Applications: Video conferences, network games, database A source could send through many unicast However, sender may not know individual receivers and efficiency issue Unicast and Broadcast 4/21/2017

Network multicast A “join” protocol (so to send or receive from) multicast group - Internet Group Management Protocol (IGMP) Routers forward mcast-addressed datagrams to hosts that have “joined” that multicast group Multicast Routing protocols -- different trees for diff groups Group-shared tree Source-based trees 4/21/2017

Overlay multicast An application forms their own multicast network - overlay network A network that has only hosts who wants to join the MC application -- “routers” are hosts! Network links are TCP connections. The network can be a tree or a mesh or … 4/21/2017

Overlay Construction The relation between links in an overlay and actual network-level routes. 4/21/2017

Overlay multicast metrics Problem: logical links vs physical links Metrics: Link stress (per link): how often a packet crosses the same link Closer to 1, the better Stretch or relative delay penalty (RDP): Measures the ratio in the delay between two nodes in the overlay, and the delay that those two nodes connecting in the underlying network. Smaller the ratio (minimum be 1), the better Tree cost: minimum spanning tree. 4/21/2017

Application architectures Rendezvous node Well know node, keep the tree members For a single source based applicaiton Find a best parent node Direct to the source (the stretch is 1 !)... Disadvantage? Consider nodes’ load (degree), e.g., k neighbor. 4/21/2017

Topics Fundamentals Stream Multicast Overlay (application layer multicast) Epidemic and gossip 4/21/2017

Data Dissemination Simple techniques for spreading information in very large-scale distributed systems. Want efficiency, robustness, speed, scale Tree distribution is efficient, but fragile (plus configuration is difficult) Flooding is robust, but inefficient No central control Gossip is both efficient and robust, but has relatively high latency Or epidemic. 4/21/2017

Probabilistic multicast Distributed local information (local view) Loose or no synchronization Scalable Reliable Probabilistic guarantees on full delivery No delay upper bound Graceful degradation in the presence of failure Delete message Replication, fault-tolerant 4/21/2017

Gossip-based Protocols Anti-entropy propagation model Node P picks another node Q at random Subsequently exchanges updates with Q Differ by the number of time they gossip the same message or the number of gossip targets they select each time. Some “epidemic” related terms: Infected – holds the data and willing to spread further Susceptible – not seen the data yet. Removed – has the date but will not send to others. 4/21/2017

Push and Pull Approaches to exchanging updates P only pushes its own updates to Q P only pulls in new updates from Q P and Q send updates to each other (1) when many are infected, push may induce long delay for spreading Pull is better: a susceptible asks around, high chance to hit a infected. (2) when data entries are big, send a “digest” (instead of the data directly) of the state, and the recipient can request anything it doesn’t already have. Apply to push, pull and push-pull. 4/21/2017

Centralized algorithm Round: picking node, picking a piece of data log2(n), for n nodes. 4/21/2017

Gossip-based protocol: k fanout 4 3 5 1 2 9 One of gossip-based algorithms works as follow. A node receiving a multicast, select randomly among the group members k (k is called the fanout, 3 in this example) others nodes to gossip to. And so on and so forth. Eventually the message reach everybody with a certain probability. Note that this algorithm have a bimodal behavior either the fanout is too low and the algorithm dies very quickly with reaching almost nobody or it reaches almost evrybody. In a previous work, we actually showed that the probability of fanout can be related to the fanout. Log(N) id usually a good value Fanout = k Probability of reliable delivery : P = exp(-exp(-s)) If k = log n + s 8 7 6 4/21/2017

Analysis Probability of infection n nodes, k member infected, Anybody can infect anyone else with equal probability. What is the probability Pinfect(k, n) that a particular uninfected member is infected in a round if k are already infected? 4/21/2017

Analysis For simple epidemic Gossip propagation time Expected number of rounds Expected # of rounds # rounds 4/21/2017

Analysis s: fraction of nodes remain uninfected: 1/k: probability of stopping infecting others. 4/21/2017

Further design issues How to know the n? Or , scalable membership protocol? Paper, [SCAMP: lightweight membership service for gossip-based protocols] Removing data: Early deletion cause restore old data keep record - Death certificates Repeat spreading Death certificates When to clean up? 4/21/2017

Applications Reputation and trust in distributed systems Paper [EBAY]: R. Zhou and K. Hwang, "PowerTrust: A Robust and Scalable Reputation System for Trusted Peer-toPeer Computing," Information aggregation Paper: textbook Jelasity, 2005b. pg 649, “Gossip based aggregation in large dynamic networks”  paper [Kempe]: "Gossip-Based Computation of Aggregate Information" 4/21/2017