Mega-Merger

Mega-merger is a distributed algorithm aimed at solving the election problem in generic connected undirected graph. ^{[1] [2]}

Introduction

Mega-Merger was developed by Robert Gray Gallager at MIT in 1983. It applies a distributed divide and conquer approach mixed with a rank-based conquer strategy. The algorithm is usually presented through a village-city analogy. Each node in the graph indicates a village, while the edges that connect them are the roads and a rooted spanning tree in a sub-graph is a city. The whole graph is then a mega-city. Mega-Merger pushes villages to bind together to form cities according to each other's rank and edges. Cities are then formed by alliances or by conquering/absorption.

Pre-requisites

Mega-Merger builds a minimum spanning tree over connected graphs provided:

• Total reliability: No message is lost in transmission.
• UI (unique initiator): A single node starts the protocol.
• Bi-directional communications channels: Each edge is bi-directional, communications can travel in both directions.

No further restrictions are necessary.

Algorithm

The algorithm assigns to each village a name and a rank, the former usually unique. The latter states the number of friendly mergers that the city has gone through, and the larger it is, the more powerful a city is considered. Moreover, to each edge is assigned a weight: each village/city ${\displaystyle C}$ has a minimum-weight edge ${\displaystyle e_{merge}(C,C')}$ also called merge link, that is the edge whose traversal has minimum cost.

The algorithm proceeds in consecutive stages until a mega-city is formed. Each city C computes its own merge link and sends a request for merging across ${\displaystyle e_{merge}(C,C')}$. The request is handled by ${\displaystyle C'}$ in the following ways:

1. Friendly merge:${\displaystyle rank(C)=rank(C')\land e_{merge}(C,C')=e_{merge}(C',C)}$: If the cities share the same merge link and have same rank, a friendly merge occurs, and the two cities merge into one. A new name is picked for the newly created city, a ruling village is picked and the path from the previous ruler to the node in the merge link is re-oriented such that it leads to the new leader. The new city also has its rank increased by one. Notice as this is the only way two cities can increase each other's rank.
2. Absorption:${\displaystyle rank(C)<rank(C')}$: If the requesting city has a lower rank, the city in the receiving end enacts an absorption process: ${\displaystyle C}$ is absorbed like in the friendly merge, but loses its name and the resulting city has the rank of ${\displaystyle C'}$.
3. Suspension:${\textstyle rank(C)=rank(C')\land e_{merge}(C,C')\neq e_{merge}(C',C)\lor rank(C)>rank(C')}$: In such cases ${\displaystyle C'}$ freezes the request: it waits to either be absorbed by rule 2 or to merge and increase its rank above the one of ${\displaystyle C}$ in order to be able to enact rule 1 and absorb ${\displaystyle C}$.

Outside messages

No nodes in the graph have a list of villages belonging to their village, hence each time a city wants to look for edges leading outside of it, it has to adopt an ask-reply protocol. The city ruler sends a broadcast message through its spanning tree, and each node ${\displaystyle x}$ receiving it sends requests to its neighbors, excluding the edges to its child(ren) and parent. The response protocol is as follows:

• ${\displaystyle x.city=y.city}$: clearly the edge is an intra-edge in ${\displaystyle C}$. ${\displaystyle x}$ and ${\displaystyle y}$ exchange negative responses.
• ${\displaystyle x.city\neq y.city\land x.rank<y.rank}$: ${\displaystyle x}$ is asking to a city of higher rank. By rule 2 we can assert that no absorption occurs, and ${\displaystyle y}$ indeed belongs to another city.
• ${\displaystyle x.city\neq y.city\land x.rank>y.rank}$: in this case ${\displaystyle y}$ will delay the answer as by rule 3.

Properties

Mega-Merger holds several properties:

• Monotonic rank: Each city ${\displaystyle C}$, mega-city excluded, will eventually rise in rank. By rule 1${\displaystyle C}$ could friendly merge, raising its rank by ${\displaystyle 1}$; by rule 2 and 3${\displaystyle C}$ will have a merge link (by hypothesis ${\displaystyle C}$ is not the mega-city) it will either ask a higher-rank city ${\displaystyle C'}$, getting absorbed and increasing its rank, or wait until ${\displaystyle C'}$ reaches its level and operate a friendly merge.
• ${\displaystyle rank(C)=K\implies |C|\geq 2^{k}}$: we have a level increase each time a friendly merge is operated. We compute by induction: on the base case, ${\displaystyle rank(C)=0}$, exactly one village is in ${\displaystyle C}$. On the inductive case, two cities ${\displaystyle C',C''s.t.rank(C')=rank(C'')=k}$ operate a friendly merge, hence ${\displaystyle |C'-C''|=|C'|+|C''|=2^{k}+2^{k}=2^{k+1}}$ by inductive hypothesis.
• ${\displaystyle \max {rank(C)}\leq \log n}$: by the previous rule cities are built up on an exponential base ${\displaystyle 2}$, hence the inverse ${\displaystyle \log _{2}n}$.
• Deadlock prevention: Mega-Merger doesn't incur in any deadlock. As shown by rule 3 a city ${\displaystyle C}$ can wait for a lower-rank city to answer on merge link ${\displaystyle e}$: in order to incur in a deadlock such city ${\displaystyle C'}$ would have to wait on ${\displaystyle C''}$, and ${\displaystyle C''}$ on ${\displaystyle C'''}$, and so on until a cycle is detected on ${\displaystyle C^{n}}$ waiting on ${\displaystyle C}$ on a merge link ${\displaystyle e'}$. But by hypothesis ${\displaystyle e}$ is the merge-link of ${\displaystyle C}$, hence such chain cannot exist. The other deadlock-inducing situation is a request from ${\displaystyle C}$ to ${\displaystyle C'}$ where ${\displaystyle C'}$ has a different merge link than ${\displaystyle C}$. Still, as shown by monotonic rank either ${\displaystyle C'}$ will grow its rank to absorb ${\displaystyle C}$, or will consume all its merge links to be the only city in the graph with ${\displaystyle C}$. Trivially in such case the two merge links would coincide and ${\displaystyle C'}$ would be forced into absorption by rule 2.

Termination

Termination is granted by deadlock prevention and total reliability.

Cost

The cost analysis has two components, the stage-cost and the stage upper-bound. A city ${\displaystyle C}$ enacts a stage by requesting a merge link from its villages and applying one of the above rules according to the desired situation. We can divide this stage in five steps:

1. Broadcast request for merge link to the ${\displaystyle \leq n}$ nodes in the tree.
2. Each node forwards an ${\displaystyle outside?}$ message to its ${\displaystyle \leq n}$ neighbors and waits for their ${\displaystyle \leq n}$ answers.
3. The nodes then send the answers back to the city ruler by convergecast for a total of ${\displaystyle \leq n}$ messages.
4. The root then decides on a merge link and sends a message to the elected node. Trivially this message will need to travel ${\displaystyle height(Tree)\leq n}$ nodes.

These five phases of request, outside discovery, communication and delivery have a total cost of ${\displaystyle n+2n+n+n\leq 5n}$. As for the wasted messages in the ${\displaystyle outside?}$ between internal nodes, each node ${\displaystyle x}$ has at most ${\displaystyle deg(x)-2}$ internal edges, or ${\displaystyle deg(x)-1}$ if ${\displaystyle x}$ is a leaf, for a total of ${\displaystyle 2m-n}$ wasted internal messages.

Now for the number of stages. By the previously presented property on the cities size, each city of level ${\displaystyle k}$ has ${\displaystyle \geq 2^{k}}$, hence the largest reachable rank is ${\displaystyle log_{2}{n}}$. Since cities can merge/be absorbed only once per stage, we have a total of ${\displaystyle 2m+n+5n\log {n}}$total messages.

Correctness

Mega-Merger creates a minimum spanning tree by merging sub-trees through the minimum cost path, i.e. the merge link. By definition of minimum spanning tree, a minimum spanning tree is a set of minimum spanning trees connected through minimum-cost paths. By construction Mega-Merger forwards a request through its merge-link, and that sooner or later that edge is going to be part of the tree by deadlock prevention.

References

1. Gallager, Robert (1983). "A distributed algorithm for minimum spanning tree" (PDF). Massachusetts Institute of Technology.
2. Awerbuch, Baruch (1987). "Optimal Distributed Algorithm for Minimum Weight Spanning Tree, Counting, Leader Election and Other Problems" (PDF). SIAM Journal on Computing.