As discussed earlier, this dissertation establishes the basic Scout and path architecture and provides initial evidence that the architecture is indeed appropriate for communication-oriented appliances. At the same time, it leaves many questions unanswered. For example, exactly what kinds of path invariants are meaningful and exploitable in different subsystems, and what tools can be used to exploit these invariants certainly warrants further research. Similarly, the usefulness of quasi-invariants likely deserves more attention. For the networking subsystem, there are cases where quasi-invariants could be beneficial, and the same is expected to be true for other parts of the system as well. For example, IP routing information changes infrequently relative to the life time of paths, but since that information is not guaranteed to remain constant, the current Scout system does not permit paths that depend on IP routing information to extend beyond IP. With quasi-invariants, it would be trivial to avoid this limitation. However, whether or not the advantages due to quasi-invariants would outweigh the additional complexity they introduce is not obvious. To answer such questions, it is necessary to collect more experience in designing, building, and studying actual appliances that span a wide range of applications. A few examples are discussed next.
Scout focuses on information appliances which implies that both soft realtime and non-realtime tasks need to be accommodated, that tasks are created dynamically at runtime, and that the CPU scheduler should be able to operate well in a mostly autonomous fashion. The requirement of autonomous operation is due to the fact that appliances should not rely on a sophisticated user that ensures a given task mix is reasonable. This is because either the user is not sophisticated, does not want to worry about such menial tasks, or does not exist at all (e.g., in case of a remote operated appliances).
Finding an appropriate soft realtime scheduler is difficult because, unlike many hard realtime schedulers, it must be fairly general. For example, it cannot assume that synchronization constraints within a task are trivial or negligible. Non-trivial synchronization makes it difficult to employ planning-based approaches, such as the one presented in [53]. On the other hand, if a user is committed to a certain realtime task, then it probably would not be acceptable if starting another unrelated task, which may not even be a realtime task, would cause the realtime task to start to misbehave. The desire to support at least a certain level of fate isolation makes it difficult to use fair share based schedulers such as the one presented in [70]. At the same time, hierarchical schedulers such as the ones presented in [36, 41] are not of much help since realtime scheduling by its very nature is not hierarchical (time is absolute).
On the positive side, it should be possible to exploit the relatively simple linear structure of paths to improve scheduling decisions. For example, for I/O bound tasks the size of the input and output queues convey important information. Similarly, average path execution time and related quantities should help in solving the scheduling problem.
Aside from finding an appropriate scheduling mechanism, the question of finding a useful, easy to understand policy is crucial in its own right. Many sophisticated scheduling mechanism make use of priorities, deadlines, latency tolerances, and various other parameters. In an appliance-like environment, a policy would be required that could derive these parameters either fully automatically, based on observing (remote) user behavior, or based on simple hints by the user.
At present Scout paths do not extend beyond the boundary of a single system. Extending paths to cover end-to-end data flows even when distributed across multiple systems is both a logical and useful step. For example, distributed paths are necessary to provide truly end-to-end quality-of-service assurances. Distributed paths are particularly important when operating in a wide-area network where network bandwidth and latency are often the limiting factors to overall performance.
Distributed paths are likely to be realizable on top of existing Scout paths and corresponding network concepts, such as flows [11]. The more interesting questions relate to how path creation should be controlled in a distributed environment. For example, the source and destination machines may want to coordinate the values for certain path invariants (e.g., maximum packet size or throughput may depend on the network connection being used). Thus, new networking protocols may be needed to support exchanging such meta-path information.
An interesting observation is that Scout paths and the virtual circuits they are modeled after appear to be on a course of convergence. Research in active networks [103] effectively makes it, at least theoretically, possible to build network routers that perform processing as complex as that in Scout modules. It is therefore fully expected that Scout distributed paths will be able to leverage off of research in active networks and vice versa.
Scout paths encapsulate dataflows. Since the task of a secure system is often to safe-guard dataflows, it appears that Scout paths could provide a natural foundation for building secure systems. Securing data flows could occur at two levels: in a distributed environment where each individual Scout machine executes code that is trusted or within a single Scout machine where there is a certain level of internal mistrust. The latter would require adding mechanisms to Scout to enforce the safety of paths, such as hardware protection domains or sand-boxing [95].