At an early stage of system development, one can analyze and predict system behavior through analysis and simulation. However, a true evaluation of system performance can only be obtained through implementation and direct measurement and experimentation of the prototype. Hence, an important task of our research is system prototyping and building. Given below is a list of software release we have made with our research results.

1. Task management — DistCondor

DistCondor is a task management software. The software is an enhanced and decentralized version of the Condor software developed at the University of Wisconsin --Madison. Refer to our task management project for technical details. A technical paper that summarizes the design, implementation, and experimentation of DistCondor can be found here. The software has been ported to the JPL site and will be included as one of the JPL X2000 demonstration efforts.

2. J-Sim

J-Sim (formerly known as JavaSim) is a component-based, compositional simulation environment. It has been built upon the notion of the autonomous component programming model. We recently made another open-source release (version 1.3) that includes classes for wireless/sensor network simulation, in addition to classes for simulating the Internet with best-effort, integrated, and differentiated services. All the source codes, white papers, tutorials, examples, and manuals are available on-line at http://www.j-sim.org.

The corresponding technical detail can be found in network modeling and simulation.

3. End-to-end measurement of available bandwidth — bTrack

bTrack is a non-intrusive measurement tool of the available bandwidth along an end-to-end network path. It periodically sends a couple of probing packet pairs with different packet sizes and estimates the available bandwidth based on the analytical model of the packet pair technique along a multiple-hop link. bTrack can continuously report a time-trace of the available bandwidth at a fine granularity while consuming a very low probing traffic, whose bandwidth is adjustable by its performance parameters. The technical details can be found in here.

4. End-to-end measurement of cross traffic — cTrack

The end-to-end measurement tool: cTrack,  aims to measure the cross traffic between two end hosts in the network. It is assumed that the bottleneck link bandwidth is known (tools exist to probe the bottleneck link bandwidth). We use proactive method to measure the cross traffic. It consists of two parts, sending part and receiving part, running as application level commands.

We applied three methods: prediction, reconstruction and interpolation. In each method, the sending part sends probe packet pairs, whose intervals are determined by the packet size and the bottleneck link bandwidth. The exact probe packet pair patterns are determined by the specific method applied. For the prediction and reconstruction methods, the probe packets are sent using an On-Off pattern. During the On periods, a bunch of probe packet pairs are sent, while in Off periods, no probe packet is sent out. For the interpolation method, evenly distributed probe packet pairs are sent out. On the receving part, the receiver infers the cross traffic by measuring the time interval between the two packets in a probe packet pair. The prediction and reconstruction methods can use the inferred information during the On periods to estimate the information during the Off periods, where no probe packet can be obtained by the reciever. The interpolation method can use the inferred cross traffic information for any two time points to interpolate the information for the period between the two points. In this way, we do not need to send too many probe packets (non-intrusive probing) while we can keep track of the cross traffic between the two end hosts.

5. End-host congestion management — COCOON in Linux

Coordinated Congestion Control (COCOON) [1] is an end-host congestion control mechanism. The basic idea behind COCOON is to identify and group connections that are destined for the same destination host/subnet and coordinate among them all the congestion avoidance/control operations. For example, the RTT information can be shared among TCP connections in the same group. When a TCP connection in a group incurs packet loss, the other TCP connections should also be subject to congestion control, as they are likely routed along the same backbone links over the Internet. The rationale behind grouping connections destined for the same subnet is grounded on several characteristic studies of WWW client-based: clients on the same subnet usually do share common interest, and it is highly likely that more than one clients from the same subnet visit some popular website at the same time (e.g., employees from the same corporate usually connect to the same website).

The size of a COCOON group can be dynamically adjusted so as to magnify the benefits of congestion management. COCOON also allows a new connection to commerce with a congestion window that is large enough to catch up with other connections while not inducing congestion. Finally, COCOON takes into account nonresponsive UDP connections and “bundles” them into a virtual connection that is subject to TCP-like congestion control. COCOON requires only minor modification at server hosts, does not require router support, and hence can be incrementally deployed over the Internet.

We implemented part of COCOON in Linux kernel 2.4.22. The implementation details can be found here, and the source code can be found here.

[1] Y. Gao, G. He, J. Hou, and S. Paul, COCOON: an alternate approach to end-point congestion management, http://lion.cs.uiuc.edu/sw_documents/cocoon.pdf.