0 100 200 300 400 500
−1.5
−1
−0.5 0 0.5 1 1.5x 104
Bytes / s
nodes
(a) Traffic, 0 % weak nodes
0 200 400 600
−1.5
−1
−0.5 0 0.5 1 1.5x 104
Bytes / s
nodes
(b) Traffic, 30 % weak nodes
0 200 400 600
−1
−0.5 0 0.5 1
x 104
Bytes / s
nodes
(c) Traffic, 50 % weak nodes
0 100 200 300 400 500
−200
−100 0 100 200
s
(d) Uptime, 0 % weak nodes
0 200 400 600
−200
−100 0 100 200
s
(e) Uptime, 30 % weak nodes
0 200 400 600
−200
−100 0 100 200
s
(f) Uptime, 50 % weak nodes
0 100 200 300 400 500
−3
−2
−1 0 1 2 3
(g) Send / received , 0 % weak nodes
0 200 400 600
−3
−2
−1 0 1 2 3
(h) Send / received , 30 % weak nodes
0 200 400 600
−3
−2
−1 0 1 2 3
(i) Send / received , 50 % weak nodes
Figure 2.10: Traffic distribution, uptime and send / received ratio among nodes for various ratios of weak nodes
getting the benefit of the response. To minimize the effect of the very short lived nodes in our analysis we added the condition that a node must have an uptime greater than 5 seconds to be presented, and then plotted the same data as in figure 2.9 in figure 2.10.
In figure 2.10(e) we still see a cluster of nodes that does not seem to be influenced by the extra condition on uptime.
common approach when simulating DHTs is to only simulate a static de-lay between nodes. Such a network model will not introduce packet drops, reordering or delay variations due to congestion in the network. To be able to model a more dynamic network, we needed a more expressive simulator.
Our choice of NS-2 was based on the fact that it is a de facto standard within the community, and also that it has good supporting tools like topology gen-erators etc.
The choice to simulate a DHT in NS-2 showed time consuming. Imple-menting the DHT functionality from scratch was needed to be able to make simplifications, and simplifications where needed to be able to study some-what large networks. As memory is a constraint in simulations, we needed to implement some extra support for dynamic allocation of simulation re-sources. Our experience is that NS-2 is not a tool that fits simulations of large, dynamic, overlay networks well. For example, we have not been able to simulate more than 60 minutes of real time when simulating a 200 nodes network with 30 % weak nodes on a 2 GB Ram machine. Fortunately, that time has been enough for the networks to stabilize so we have been able to get data from stable networks. The way we set up the networks offline 2.5.2 also shortened stabilization times compared to real experiments.
In conclusion we think that more bandwidth studies of DHTs are needed as they are becoming more common as building blocks in distributed sys-tems. The simulation approach can be valuable but a simulator which is less detailed compared to NS-2 and more complex than the delay only simulators would be a good tool for such analysis.
Bibliography
[1] Hari Balakrishnan, Scott Shenker, and Michael Walfish. Peering Peer-to-Peer Providers. In 4th International Workshop on Peer-to-Peer-to-Peer-to-Peer Systems (IPTPS ’05), Ithaca, NY, February 2005.
[2] Fredrik Bjurefors, Lars ˚Ake Larzon, and Richard Gold. Performance of pastry in a heterogeneous system. In Proceedings of the fourth IEEE International Conference on Peer-to-Peer Computing, 2004.
[3] Yatin Chawathe, Sriram Ramabhadran, Sylvia Ratnasamy, Anthony LaMarca, Scott Shenker, and Joseph Hellerstein. A case study in build-ing layered dht applications. In SIGCOMM ’05: Proceedbuild-ings of the 2005 conference on Applications, technologies, architectures, and protocols for computer communications, pages 97–108, New York, NY, USA, 2005.
[4] Brent Chun, David Culler, Timothy Roscoe, Andy Bavier, Larry Pe-terson, Mike Wawrzoniak, and Mic Bowman. PlanetLab: An Overlay Testbed for Broad-Coverage Services. ACM SIGCOMM Computer Com-munication Review, 33(3):00–00, July 2003.
[5] Sally Floyd and Steve McCanne. ns network simulator. Online:
http://www.isi.edu/nsnam/ns, 2003.
[6] The Bamboo distributed hash table. Online: http://bamboo-dht.org/, 2003.
[7] Eddie Kohler, Mark Handley, and Sally Floyd. Designing dccp: con-gestion control without reliability. SIGCOMM Comput. Commun. Rev., 36(4):27–38, 2006.
[8] Ralph C. Merkle. A digital signature based on a conventional encryption function. In Carl Pomerance, editor, Proceedings of the annual interna-tional cryptology conference(CRYPTO), pages 369–378. Springer-Verlag, 1988.
[9] Sylvia Ratnasamy, Paul Francis, Mark Handley, Richard Karp, and Scott Schenker. A scalable content-addressable network. In Proceed-ings of the 2001 ACM SIGCOMM conference on applications, technolo-gies, architectures, and protocols for computer communications, pages 161–172, 2001.
[10] Sean Rhea. OpenDHT: A Public DHT Service. PhD thesis, University of California, Berkeley, August 2005.
[11] Sean Rhea, Dennis Geels, Timothy Roscoe, and John Kubiatowicz. Han-dling churn in a DHT. In Proceedings of the 2004 USENIX Annual Tech-nical Conference (USENIX ’04), Boston, Massachusetts, June 2004.
[12] Sean Rhea, Brighten Godfrey, Brad Karp, John Kubiatowicz, Sylvia Ratnasamy, Scott Shenker, Ion Stoica, and Harlan Yu. OpenDHT: a public DHT service and its uses. SIGCOMM Comput. Commun. Rev., 35(4):73–84, 2005.
[13] Antony Rowstron and Peter Druschel. Pastry: Scalable, decentralized object location, and routing for large-scale peer-to-peer systems. Lecture Notes in Computer Science, 2218, 2001.
[14] Sean Rhea and Dennis Geels and Timothy Roscoe and John Kubiatow-icz. Handling churn in a DHT. Technical Report UCB/CSD-03-1299, University of California, Berkeley, December 2003.
[15] Ion Stoica, Daniel Adkins, Shelley Zhuang, Scott Shenker, and Sonesh Surana. Internet indirection infrastructure, 2002.
[16] Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, and Hari Balakrishnan. Chord: A scalable peer-to-peer lookup service for internet applications. In Proceedings of the 2001 ACM SIGCOMM conference on applications, technologies, architectures, and protocols for computer communications, pages 149–160, 2001.
[17] Sven Westergren. Notenet - range queries in a DHT. Master’s thesis, Uppsala University, 2007.
[18] Ben Y. Zhao, John D. Kubiatowicz, and Anthony D. Joseph. Tapestry:
An infrastructure for fault-tolerant wide-area location and routing.
Technical Report UCB/CSD-01-1141, UC Berkeley, April 2001.
Chapter 3
Paper B: Vendetta - A Tool for Flexible Monitoring and
Management of Distributed
Testbeds
Abstract
Writing a powerful tool for monitoring and management of a testbed can have a positive effect when doing research on the testbed. Despite this, many testbeds use primitive scripts for data collection, code updates and other basic tasks.
We introduce Vendetta, a flexible and powerful platform for monitoring and management of distributed testbeds. It is designed to be relatively easy to adapt to different testbeds by having a modular design, being written in Java and defining much of the testbed-specific behavior in two configuration files.
The novelty in comparison with similar tools is the integration of a GUI supporting 3D graphics, flexible monitoring and management into one single tool. We will present the general design of Vendetta and then illustrate how it has been used for monitoring and management of an experimental DHT deployment running on Planetlab. Experiences from this combination shows that usage of a tool like Vendetta simplifies testbed management and makes it easier to discover and analyze different phenomena.
3.1 Introduction
The last decade has shown an increasing need of distributed testbeds to sup-port networking research. One reason for this is that experimental results from an actual deployment - if only in a limited testbed - can reveal phe-nomena that never will appear in a simulator. An important factor is the increased availability of platforms on which distributed testbeds can be de-ployed. Emulab[6] and Planet-lab[2] are two of the most well-used examples for both experiments and deployment of new services.
When creating a distributed testbed, focus tend to be on actual function-ality of the software to be deployed, with less efforts to provide a good user interface for monitoring and management features. Not uncommonly, code distribution, experiment synchronization, data gathering and similar tasks are done using customized scripts specific to the testbed. As functional as these script-based solutions can be, they are not always very user-friendly.
Complete data collection for post-mortem analysis is also common in dis-tributed testbeds. This approach typically provide researchers with large amounts of data on which data mining is done using third-party software.
We introduce Vendetta, which provides a flexible platform for develop-ing user-friendly monitordevelop-ing and management functionality in distributed testbeds. It is primarily aimed at medium-sized testbeds used in smaller projects with limited resources and incentives to develop testbed-specific software with similar functionality. Vendetta is designed to be flexible yet powerful by allowing users to create testbed-specific modules that work like plugins. The testbed-specific parts of Vendetta consists of two configuration files plus Java code to collect and parse data. It is also possible to construct a graphical canvas to illustrate testbed-specific details in a more intuitive way.
The software includes highly customizable functionality for basic monitoring and management tasks that can be used to produce a powerful testbed-specific monitoring/management solution at a relatively low programming effort.
This paper is organized as follows. In the following section, we present the design and features of Vendetta in more detail. After that, we will present a case where Vendetta is used for monitoring and management of a distributed hash table (DHT) testbed running on PlanetLab. After a discussion about the features and limitations with a platform like Vendetta, the paper is con-cluded with ongoing development efforts and planned future work.
Figure 3.1: Vendetta layout for a DHT testbed