Latency Bandwidth (ms) stdev Kbit/s stdev Hamachi-Free 60.8 2.54 40.2 0.87 Hamachi-Pro 60.2 1.68 1000 1.29 Latency-aware 58.1 35.5 2245 1080 Table 3: Results of the evaluation comparing latency and band- width of Hamachi relays and IPOP latency-aware autonomic relay selection. As Hamachi was started and figured out that NAT traversal was not possible, it began using multiple dif- ferent relays as evident by several different ping times. Eventually Hamachi settled on a relay server and it ap- peared to be the same one every time, for both Hamachi- Free and Hamachi-Pro. The only difference between Hamachi-Pro and Hamachi-Free is that in Pro there is a bandwidth cap of approximately 1 Mbit/s whereas Free is limited to 40 Kbit/s. The P2P system IPOP used has nodes both on Planet- Lab but also dedicated systems for Archer [14]. These machines are at Universities and thus have a high band- width and low latency connection to the testing site. As witnessed by the results, it appears that in most if not all these experiments peers had a low latency connection to a University compute resource and it was chosen ahead of Planet-Lab. The two apparent take aways are 1) the benefit of being able to deploy your own relay servers and to reuse com- pute nodes as relay systems and 2) as our network grows, we too may need to implement some form of bandwidth limit at relay nodes. 5.3 Comparing System Overheads In this experiment, we attempt to understand the bounds imposed by OpenVPN, Hamachi, and IPOP. We used Amazon EC2 [2] to dynamically create various sized networks ranging from 1 to 129 with one client used as the control. In the bootstrap phase, the con- trol machine initiates communication with a subset of the remaining clients in the VPN. Once the system has warmed, the control continues pinging this subset every 15 seconds for the next 10 minutes. We capture bytes transmitted into and out of the system, as well as the memory size of the VPN application at the end of each stage. As we test the varying network sizes, we begin by communicating with 0 peers and exponentially increase the amount (powers of two) until the control is commu- nicating with all members of the VPN. For these evalua- tions, we used a licensed version of Hamachi, but due to very recent changes in Hamachi, the Linux client will not support networks larger than 16. Due to amount of data collected and space limitations, we only present figures In Figures 6, we present the bandwidth results for client network sizes of 128. Our evaluation scaled from having the control communicate with 0 to 128 clients ex- ponentially, though as mentioned already, Hamachi only supports network sizes of 16, so we used a linear regres- sion to extrapolate the bandwidth results. The results are somewhat predictable as Brunet, IPOP’s P2P infras- tructure, primarily uses UDP connections and thus must maintain application layer connections and NAT map- pings. It is not obvious that Hamachi is doing the same, which may be due to the fact that the peers all have pub- lic IP addresses. In fact, Hamachi’s behavior appears to be similar to that of OpenVPN. Additionally, OpenVPN does not need to maintain NAT mappings as the servers are location on public addresses, thus a client does not Figure 6: Comparison of bandwidth costs for member activ- ity versus network size. As stated in the text, Hamachi limits the system to network sizes of 16, so to estimate the Hamachi bandwidth we used the following formula using a linear regres- sion model based upon our data sets: . 049+ . 002 KB/s ∗ N + . 02 KB/s ∗ A , .049 the bandwidth in a network size of 0, i.e., keep-alives with the central server, N is the network size, and A is the active links. for results that provide interesting data and summarize the rest in the text. Memory, for the most part, exhibited an intuitive be- havior: for each additional connection there was more memory used. The OpenVPN control client showed neg- ligible additional memory usage for additional nodes, though the server showed a linear increment, around 1 MB, for each additional client in the system, while ac- tivity had negligible effect on the results. Hamachi had a base line of a less than 1 MB and like OpenVPN, each ad- ditional client in the system had a linear effect on mem- ory, on the order of 4 KB, there was no change based upon activity. The effect of additional inactive nodes in an IPOP network had negligible effect on memory, unlike Hamachi and OpenVPN. The only time IPOP’s memory consumption increased was during activity and it scaled at a 200 KB per additional node. 10