To the Sponsored Research Committee:

The attached proposal was submitted last year (Oct 2001). I am resubmitting it with a new cover letter that I hope will position the proposal accurately.

The aim of this work is to form a software laboratory in which students can explore advanced computer science topics some of which can lead to research topics. We want (at TESC) to encourage faculty to form research agendas that are accessible to students. Yet (in computer science) many research areas are inaccessible to students until very late in their academic studies. The reasons behind this include:

  1. The amount of preliminary work that must be done is extensive.
  2. The material is often very abstract.
  3. We lack supporting resources so that students have to start from "scratch" each year.

In the physical sciences we provide laboratory equipment to support skill development, concept development, as well as research activities. The results of previous work are accessible in the form of collected data and papers. However in computer science we do not have analogous equipment. A student wishing to study (for example) operating systems scheduling algorithms has a very high bar to climb. In addition to the theoretical work on the algorithm, the student must them implement the algorithm and test her hypothesis. Altering a scheduler in a running system is the final result of this sequence, not the process. To test her algorithm she will have to write a simulator on which to experiment with different models. This itself is a big job, depending on the required degree of simulation. Assuming the student succeeds, she then proceeds to test her ideas. After the student has completed her work, there is little that future students can use for further research in this area. The programs written may not be complete. The simulator may not have been written with any general applications in mind. The languages may differ. The work done by the student was not written with the intent of providing a modular component system for reuse into the future (itself a major development project).

The consequence of this is that each generation of students has to start from the ground up. We never provide a skeleton and more important we don't provide a way that the skeleton can be fleshed out from year to year.

I imagine a software lab to have the following high level structure regardless of the topic actually under investigation:

The structure of such a lab would allow students in programs to use Box F ( foundations ) to further their skills and concept understanding, making abstract topics more tangible. More advanced students can propose and implement extensions to the foundation system. Extending the operating system example above, the foundations might include general scheduling algorithms and a vanilla brand operating systems simulation. Entry level students can explore these algorithms and modify workload in order to understand how scheduling decisions affect system performance. Advanced students could propose experimental algorithms that give preferential treatment to certain kinds of processes or different kinds of workloads. These can be used locally in Box E ( exploratory ) and if judged of general interest, exported back to Box F. Lastly, if a student or group of students or faculty want to do research on scheduling algorithms in less well understood areas (such as distributed systems) they could implement these algorithms in Box R ( research ). While the functionality of physical labs is extended by the purchase of equipment, the facilities of a software lab are extended by writing software. This provides a 2-way opportunity for students: they can extend their understanding by using the lab and they can explore how new capabilities can be expressed and how they relate to the existing system.

A lab of this sort is also enduring: it's state persists beyond the program year. Projects conceived in one year may be pursued in following years by other students. It has a coherence of its own (beyond the program) as well as a resource to a program.

It is difficult to select which computer science topics will be most fruitful to explore at TESC. By starting on a selection of such labs with the intent to grow them into the structure suggested above each could grow at the rate suggested by student and faculty interest. Although we have little data on how such a lab would work in practice, this past year I developed a software simulation of a mini-operating system that would only support the implementation of different schedulers and the identification of different classes of workload sets. Students in Data to Information used this simulation to construct small projects exploring the behavior of schedulers. This year, a group of advanced students are using the simulator as the basis for a simulator on a distributed system conducted in the network lab. This is a proof of concept. I hope with the investment of the upfront development work needed to establish a set of foundation systems (Box F) in different topics, we could have a mix of advanced topics that can grow with student and faculty interest.