content_image/429457.jpg content_image/429456.jpg
<img src='content_image/429457.jpg'>

IPOP [41] and Brunet [4]. We present the advantage of using relays over overlay routing when NAT traversal does not work. Then we examine the effects of using dif- ferent relay selection mechanisms. Afterwards, we eval- uate the system overheads of OpenVPN, Hamachi, and our P2P VPN to determine the OS resource costs and the cost of each in a distributed environment. Finally, we present a quantitative comparison of our two full tunnel models. 

## 5.1 Motivation for Relays in the Overlay 

The purpose of this experiment is to quantify the per- formance benefits of autonomic relays. For this experi- ment we use the MIT King data set [22], a data set con- taining all-to-all latencies between 1,740 well-distributed Internet hosts. We reviewed many different sizes of net- works up to 1,740 nodes, evaluating each network size 100 times. Our experiments were executed by running the VPN software in simulated mode, which reuses the code base of IPOP to faithfully implement its function- ality, but using event-driven simulated times to emulate WAN latencies in a LAN environment. Once at steady state, we then calculate the average all-to-all latency for all messages that would have taken two overlay hops or more, the average of our low latency relay model, and the average of single hop communication. In the low latency relay model, each destination node form a connection to the source node’s physically closest peer as determined via latency (in a live system by application level ping). 

Then this pathway is used as a two-hop relay between source and node. We only look at two overlay hops and more, as a single hop would not necessarily benefit from the work and would be the cause of a triangular inequal- ity. The simulations were performed on a distributed grid platform, Archer [14], that uses IPOP for its virtual net- working component. 

<img src='content_image/429456.jpg'>

Our results are presented in Figure 5. We performed the tests for varying network sizes. We began our tests at 25, because network sizes around 20 and under tend to be fully connected due to the connectivity require- ments of the system. It is not until the network size expands past 100 and towards 200 nodes that relays be- come significantly beneficial. At 100 nodes, there is ap- proximately a 54% performance increase, whereas at 200 there is an 87% increase and it appears to grow propor- tionately to the size of the pool. The key take away is that latency-bound applications using a reasonably sized overlay would significantly benefit from the use of two- hop relays. 

## 5.2 Comparing Relay Selection 

In this experiment, we share our experience of test- ing the use of latency-aware relays using our public P2P pool running on Planet-Lab as well as Hamachi-Free and Hamachi-Pro relays. Due to Hamachi not supporting re- lays in Linux, this experiment was performed in Win- dows Vista 64-bit. The testing platform consists of two virtual machine located on the same host with a fire- wall preventing them from establishing direct connec- tions. All experiments were repeated 5 times using a clean configuration each time. In Hamachi, this meant that the server would need to re-evaluate NAT traversing capabilities and the optimal relay to use. In IPOP, this meant that the VPNs would generate a new node ID and become peers with different members of the overlay. Our results are presented in Table 3. 

