1. Communication (II) Chapter 4
4/21/2017

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

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

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

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

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

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

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

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

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

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

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

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

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

15. Gossip-based protocol: k fanout4 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

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

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

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

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

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