# A Tale of Many Networks: Splitting and Merging of Chord-like Overlays in Partitioned Networks
## 5 Evaluation Results
### Evaluation Results for Setups E.1-2: Parameter Studies and Clurn  
In Setups E.1-2, after all nodes have joined the network, a group of 400 nodes is isolated from the global Chord ring in minute 180. In this section, we examine the behavior of the Ring Reunion Algorithm in the context of churn and different parameter settings, in order to determine a suitable configuration of our algorithm in realistic use cases. More specifically, in Setup E.1, the interval with which the public list selects merging candidates, i.e., the interval with which merger processes are started, is set to 5 min. Value \(\alpha\), which regulates the number of merger attempts per construct, is set to 10 and 100. With this setting, we show that the message overhead is larger than the overall effect of the merger algorithm. In Setup E.2, we set \(\alpha=10\) and vary the interval with which merger processes are started from 5 min to 20 min in steps of 5 min. In both setups, we investigate the effect of parallel merger instances on the Ring Reunion Algorithm reliability. Figure 17 reveals the behavior of the Ring Reunion Algorithm if multiple parallel instances are distributed by the first initiator node. In this scenario, every 5 min, the public list tests a contact node to determine how reachable it is. In Figure 17a,c, one can see that the merger algorithm is able to unify the disrupted network, no matter if 10 instances per construct are started or 100. On the contrary, if the number of parallel instances is too high, the merger algorithm operates poorly in some cases. In 50 percent of our simulations, with 64 parallel instances, the number of constructs suddenly rises after the network isolation stops, so that in the end the merger shows to be unsuccessful, as to be seen in Figure 17g. Nevertheless, Figure 17b,d,f,h prove that the message overhead produced by the Ring Reunion Algorithm depends on the number of overlay constructs and can be limited by reducing the number of merger attempts per construct by adjusting parameter \(\alpha\). Figure 18 shows the results of a simulation in which multiple parallel instances have been tested in combination with different intervals for starting merger instances with \(\alpha=10\). Considering the number of constructs in Figure 18, it can be observed that high numbers of parallel instances lead to better operation, with fewer attempts being started to merge the overlay. Considering the quantity of messages, on the other hand, reveals that the number of simultaneous instances does not affect traffic overhead and the resulting bandwidth consumption. Figure 16: D.1 Complex, realistic scenario in which multiple network partitioning events occur. The public node list approach is combined with \(\alpha=10\) mergers per overlay construct. Figure 17: E.1: Ring Reunion Algorithm with parallel instances, \(\alpha\in\{10,100\}\). The behavior of the Ring Reunion Algorithm can be explained as follows: if the network is not yet fully stabilized after a partitioning event, and if multiple merger instances have been started, the current overlay constructs are suddenly reordered. As a consequence the number of overlay constructs rises in this short period of time, as can be seen best in Figure 18g for all intervals greater than 5 min. Furthermore, in some cases, the determination of the additional merger instances takes more time than the actual merger process or  
Figure 18: E.2: Ring Reunion Algorithm with parallel instances and various values for interval parameter, \(\alpha=10\). the interval within which new merger attempts are started. Hence, the additional started merger instances disrupt current overlay constructs again. In a few cases, this behavior leads to a dysfunction of the merger process which is caused by wrong parameter choices. Another reason for this wrong behavior is changes in the routing table, due to churn. If one node leaves the overlay suddenly, it might happen that too many instances try to unify the falsely detected overlay partition again.