BWCTL: Scheduling Tests Without Conflict

The decentralized design of the Internet hampers the provision of services that are coordinated across operating domains, such as end-to-end path analysis. Users attempting to run bandwidth tests could not be certain they were scheduling tests when other tests were not running (to avoid skewed results) and found it difficult to get permission to run tests to certain locations (due to security restrictions at those sites). Internet2’s piPEs, for which BWCTL was created, gives the average user a tool to locate problems and identify the administrative domain responsible for its solution. A battery of regularly scheduled active tests provides data on loss, jitter, throughput, and one- way latency. If the necessary data is not included in the database, a test can be scheduled on demand. For the initial implementation of piPEs, a full mesh of regularly scheduled tests on the 11-node Abilene backbone was planned; the designers realized that piPEs must have a method to control when both regularly scheduled tests were performed and allow on-demand tests users need (without allowing those tests to interfere with the regular testing). These are requirements beyond the scope for which Iperf was designed. BWCTL was born of that need; it is a command line client application and a scheduling and policy daemon that wraps Iperf. BWCTL actually executes the Iperf command line program (although that may be changed in the future). The client application works by contacting a daemon process on both the remote system and on the local system to request that they perform a specific Iperf test between them. The daemon process manages and schedules the resources of the host on which it runs. Note : The client can arrange for a test between two servers that are not even on the same host as the client (as in Figure 1)!
Figure 1: BWCTL Client Arranging a Test Between Two Servers	bwctl contacts a daemon on each test endpoint to ensure more than one Iperf process does not happen at the same time on either host. In the event that the local host is one of the endpoints and there is no local bwctld running, bwctl will spawn additional processes to execute the local side of the test directly. In this case, a diagram of the processes involved would look like the illustration in Figure 2. BWCTL was designed to enable non-specific Iperf tests to a host without having to give full user accounts on the given system. Many users want the ability to run Iperf to determine the achievable (or available) bandwidth between a pair of hosts. It is often useful to test to multiple points along a network path to determine the network characteristics along that path. Typically, users who want to conduct path decomposition must directly contact the network or system administrators who control the hosts along the path. Each administrator must either run half of the test for the user or provide a user account on the host, which is untenable for all but well-known testers. Most network paths involve multiple administrators. These hurdles make path decomposition difficult in practice. BWCTL can help with this problem: it allows an administrator to configure a given host as an Iperf endpoint, which canbe shared by multiple users without concern that those users will interfere with each other. Specific policy limits can be applied to specific users (or groups of users), and individual tests are scheduled so they will not interfere with each other.
Figure 2: BWCTL Client Directly Testing with a Server	BWCTL allows the administrator to classify incoming connections based upon a user name and AES key (generated by a passphrase) combination or, alternatively, based upon an IP/netmask. Once the connection is classified, the daemon process can determine the exact type and intensities of Iperf tests that will be allowed. (More details on policy controls can be found in the manual pages.) To join the group of early adopters, please contact Jeff Boote (boote@internet2.edu) or subscribe to one of the two mailing lists that support this project: bwctl-users: A general discussion list for users to discuss problems. This list is monitored by the designer. bwctl-announce: This list is used to announce new versions or significant developments with regard to the software. Information about these lists, including links to subscribe, is at https://mail.internet2.edu/wws/lists/engineering. A detailed description of BWCTL and full documentation is available at: http://e2epi.internet2.edu/bwctl/. “We have been using the BWCTL tool [for] some of our testing in preparation for an upcoming e-VLBI experiment [the outcome of which is described in a Use Study at http://e2epi.internet2.edu/case-studies/VLBI/index.html]. I think the flexibility that BWCTL is providing us is a real step up from the usual performance testing we do with Iperf/nuttcp-type tools. In particular, being able to deploy this to remote sites that are managed by people who might not have a background in testing is a big help.” -- Dr. David Lapsley (Massachusetts Institute of Technology, Haystack Observatory)

© 1996 - 2008 Internet2 - All rights reserved | Terms of Use | Privacy | Contact Us 1000 Oakbrook Drive, Suite 300, Ann Arbor MI 48104 | Phone: +1-734-913-4250