This chapter establishes the vocabulary and fundamental concepts required to understand the path-architecture of Scout. As motivated in the previous chapter, paths are intended to facilitate tackling problems that are difficult or impossible to solve in purely modular systems.
The systems research community has long harbored an intuitive notion of what a path is. For example, it often refers to the fast path through a system [85, 73, 2, 112], implying that the most commonly executed sequence of instructions have been optimized. As another example, it sometimes talks about optimizing the end-to-end path [17, 15] meaning the focus is on the global performance of the system (e.g., from I/O source to sink), rather than on the local performance of a single component. As a final example, it sometimes distinguishes between a system's control path and its data path, with the former being more relevant to latency and the latter more concerned with throughput [27, 84]. But the wide-spread use of this term has so far not been translated into a well-defined abstraction that could serve as a foundation of system design. The reason for this is probably two-fold: first, the recognition that many path-like techniques could be unified with an explicit path-abstraction has been missing in the past, and, second, even once the usefulness of a unified path abstraction is recognized, it is non-trivial to define and explain an abstraction that is, on the one hand, general enough to be widely applicable and, on the other hand, specific enough to facilitate the various path-based optimizations and resource management benefits.