BWCTL
(bandwidth control)
Jeff Boote
Internet2

What is it?
A resource allocation and scheduling daemon for arbitration of iperf tests

Problem Statement
Users want to verify available bandwidth from their site to another.
Methodology
Verify available bandwidth from each endpoint to points in the middle to determine problem area.

Typical Solution
Run “iperf” or similar tool on two endpoints and hosts on intermediate paths

Typical road blocks
Need software on all test systems
Need permissions on all systems involved (usually full accounts*)
Need to coordinate testing with others *
Need to run software on both sides with specified test parameters *
(* bwctl was designed to help with these)

Functionality (bwctl)
Bwctl client application makes requests to both endpoints of a test
Communication can be “open”, “authenticated”, or “encrypted”
Requests include a request for a time slot as well as a full parameterization of the test
Current client is limited in that one of the endpoints must be the localhost, but the protocol is designed to support 3 parties
Same “basic” command line options as iperf (some options limited or not implemented.)

Functionality (bwctld)
bwctld on each test host
Accepts requests for “iperf” tests including time slot and parameters for test
Responds with a tentative reservation or a denied message
Reservations by a client must be confirmed with a “start session” message
Resource “Broker”
Runs tests
Both “sides” of test get results

Scheduling
A time slot is simply a time-dependant resource that needs to be allocated just like any other resource. It therefore follows the resource allocation model.

Resource Allocation Model
Spheres of control
Is the basic parameterization of the requested test allowed?
Does the bwctld have enough resources to allow test?
Does this host have enough resources?
Does this <higher level…> have enough resources?

Resource Allocation (bwctld)
Each connection is “classified” (authentication)
Each classification is associated with a set of hierarchical limits
bwctld.limits

Architecture

Iperf as the “tester”
Well known – widely used
Level of integration
Iperf server initialization (port number allocation)
Iperf error conditions
End of session detection
(iperf designed to do diagnostics, we are using it to benchmark)

Specific difficulties
UDP
Iperf doesn’t always send at requested rate
Iperf sender hangs (likely Linux/iperf interaction – could be due to signal handling of the bwctl level)
End of session is difficult to detect, which is problematic for a “scheduled” timeslot
Iperf sometimes takes large amounts of time to finish

Specific difficulties
TCP
Large pipe to small pipe
Launch a large window
Test waits until completion
Terminate test to remain within schedule
Ž Sets of incomplete tests to interpret
Full mesh presents difficulties for window size selection (and other path specific charactoristics)
bwctl uses the peer to peer server connection to deduce a “reasonable” window
If at all possible path specific parameters need to be dynamically configured

Future Possibilities
Server-less client side for end hosts
Closer integration with tester (iperf API?)
Better error detection
Better timing control (begin and end of test is currently a problem)
3-party tests (client not on one of the endpoints)
Open source development

Availability
Beta version currently available
www.internet2.edu/bwctl/
Mail lists:
bwctl-users
bwctl-announce
https://mail.internet2.edu/wws/lists/engineering