Kernel modules, developed for Linux, that retrofit quality of service (QoS) support into the operating system (OS) are discussed in this paper. The basic idea is to add request classifiers that can divide requests into different levels of service as needed by applications. By assigning a separate server instance to each class, applications can be scheduled according to request availability and desired service levels. The applications need not be changed, except for being divided into separate servers. An additional, user-level component, the QoS manager, notes the arrival of service requests, and the service levels they receive, and adjusts service behavior when needed (namely, the connection acceptance rates used at the kernel level).

The evaluation of the kernel extension uses multiple application-level servers to demonstrate the generality of the request classification-based approach to QoS control: a Web server that offers different delays for different service classes, an Internet message access protocol (IMAP) server that does the same, and a file transfer protocol (FTP) server for which bandwidth usage is constrained for different client classes.

I found the paper interesting, in that it follows a current trend to add QoS functionality to off-the-shelf class of service (COS) operating systems. The methods used here, however, are more limited than what is offered by other approaches, including previous work on kernel-level methods for request differentiation. This paper’s use of such methods for throttling Web requests is also strongly related to techniques described in earlier work. If the authors had included a thorough discussion of such related work in this paper, it would have provided readers with a much better feel for the current state-of-the-art in the field.

There are also some interesting issues to be considered in conjunction with this paper’s contributions. One issue is whether this approach extends to multiple machines, as with Web servers and their proxies. Another issue is what functionality belongs in an OS kernel in the first place. In this paper, for instance, the QoS manager is outside the kernel, whereas the rest of the support is at the kernel level. Is that an artifact of the authors’ current implementation, or is it appropriate or necessary? The Distributed Extensible Open Systems (DEOS) project at Georgia Tech chose to implement somewhat richer kernel-level functionality. Previous work by this paper’s authors, and most current and past work on distributed adaptive systems, used middleware-only solutions. A discussion of the relative weaknesses and advantages of these different approaches would be interesting.