The University of Arizona, Department of Computer Science

The ubiquity of computer networks is fueling an explosion in small, special-purpose, and often mobile computing devices. These devices, which are sometimes called network appliances, include network-attached disks, cameras, and displays; set-top boxes and web browsers; hand-held and portable devices; application gateways; and special-purpose servers (e.g., web and file servers). Network appliances have several unique characteristics that suggest a re-thinking of operating system design.

Communication-Oriented: Handling I/O---moving data from an input device to an output device---is the primary function of a network appliance. For example, a network camera might read input from a video frame grabber, compress each frame, break the frame into one or more packets, and write the packets to a network device. While the data is sometimes transformed (e.g., compressed), it is more accurate to think of such processing as something that happens to the data as it moves through the system, rather than an end in its own right. Conventional operating systems are typically structured around computation-centric abstractions (e.g., processes, jobs, tasks), with I/O treated as incidental. For a network appliance, it makes more sense to structure the OS around communication-oriented abstractions.

Specialized/Diverse Functionality: Network appliances typically perform a single specialized function. For example, a network camera captures, compresses, and transmits video frames. It is unlikely that such a device would suddenly be asked to compile a Fortran program or respond to a database query. This specialization is not a particularly good match for conventional operating systems, which are commonly made as general as possible so they can support the widest range of applications possible. This generalization often comes at the cost of performance---it is difficult to make a general tool as efficient as one that is specialized for a particular task. While a single network appliance is likely to perform a single function, the collection of all network appliances span a wide range of functionality. To avoid writing the OS for each network appliance from scratch---as well as to avoid using a general-purpose OS that doesn't necessarily offer exactly the right functionality---one would like the OS to provide a general framework that can be specialized (configured) for a particular need.

Predictable Performance with Scarce Resources: Because network appliances often have a human as the ultimate consumer of the data, it is important that their performance be predictable. For example, a network display may be asked to receive and display video frames at some constant frame rate. Said another way, network appliances often have real-time constraints (usually soft) that must be supported by the OS. Unfortunately, this need for predictable performance cannot be achieved by over-specifying the hardware, as is often done in real-time systems. As the name suggests, a network appliance is probably viable only if it is also affordable. Keeping costs down, in turn, implies that a given network appliance must be built using the fewest resources required to perform the specialized functionality. Even the $100 it costs to add 16MB of memory might make such an appliance impractical. In addition to cost, mobility considerations (e.g., size, weight, and power consumption) might contribute to a minimization of resources. This means that the OS must pay attention to the behavior of the system under load, which is especially challenging in light of the need to support predictable (realtime) performance.

We are designing, implementing, and evaluating a new operating system, called Scout, that is targeted at network appliances. Scout addresses the three issues outlined above. First, it is designed around a novel communication-oriented abstraction called the path, which is essentially an extention of a network connection into the host OS. Second, Scout is configurable; an instance of Scout targetted for a particular network appliance is generated from a collection of building-block modules. This framework is general enough to support a wide range of network appliances, but also facilitates the optimization of each specific configuration. Third, Scout includes scheduling and resource allocation mechanisms that offer predictable performance under load. These mechanisms are designed to squeeze the most performance out of the fewest resources.

The path abstraction at the core of Scout, while communication-oriented, also plays a central role in addressing the second two issues. In the case of specialization, paths expose global context that various optimization techniques can then exploit. In other words, Scout achieves specialization through configurability, with the resulting modular system optimized on a path-by-path basis. In the case of resource managment, all scheduling decisions are made on a per-path basis. Scout allocates to a given path all the resources (e.g., CPU, memory, bus, cache) it needs to provide the same quality of service as supported by the network connection to which it is attached. A paper describing the path abstraction and illustrating how paths can be used to address the resource allocation problem can be found in [OSDI96]. A companion paper that illustrates how paths can be exploited by code optimization techniques can be found in [SIGCOMM96].

In addition to path-based techniques, Scout also generates a diverse collection of specialized network appliances through the use of small languages. These are special-purpose programming languages that can be used to specify some component of Scout, and from which OS code can be automatically generated. Again, the idea is that various components of the OS need not be either implemented from scratch for each network appliance or general-purpose, but instead can be generated according to the specific needs of a given network appliance. Three examples of small languages we've developed for Scout can be found in [SIGCOMM94, OSDI94, POPL96].

[ Scout Home Page | Department Home Page ]
Send mail to: scout@cs.arizona.edu
Last updated March 2, 1998