| D. Mosberger and L. L. Peterson. Making paths explicit in the Scout operating system. In Proc. OSDI, pages 153--167. ACM Press, 1996. |
....This often results in massive, unstructured protocol stacks that are very hard to adapt. As a methodology for creating maintainable and customizable protocol stacks, a pipelined architectural style [4] has been proposed. Examples of pipeline protocol stack architectures are NetScript [1] Scout [14] and Click [13] Such architecture forces a programmer to define basic protocol stack entities (called components) that process incoming packet streams. These components are plugged one after the other to create a functional system (such as a protocol stack) 2.2 Anonymous interaction model ....
D. Mosberger and L. Peterson. Making Paths Explicit in the Scout Operating System. In Proceedings of OSDI '96, pages 153-168, October 1996.
....Access Control isolating data streams into a single address space, and isolates the effect of other applications by making scheduling decisions at each resource multiplexing point implementing an equivalent service to resource reservation in our model. Similarly, the Scout operating system[12, 15] introduces a path abstraction representing an I O channel. The paths are then schedulable and enforceable entities in Scout. This abstraction is similar to the notion of resource principal. Both Nemesis and Scout are operating systems built from scratch to efficiently account and enforce resource ....
D. Mosberger and L. Peterson. Making Paths Explicit in the Scout Operating System. In Proceedings of the Second Symposium on Operating Systems Design and Implementation, Oct. 1996.
....to offer guaranteed response time, e.g. for a real time client. Several operating systems have avoided these problems by enhancing the kernel with a powerful policy for metadata management. In the Scout system, it is possible to limit the amount of kernel resources used by a particular I O path [40], which has been demonstrated to be an effective defense against denial of service attacks [49] The Resource Container abstraction provides systems with a method to account kernel resources towards individual activities, and to impose limits on their resource usage [3] Other operating systems ....
....I O, while the rest is subjected to the normal paging scheme and can be paged out to backing store. Thus, the size of the metadata used by the kernel can exceed the amount of physical memory. Several other approaches introduce a new abstraction for resource principals. The Scout operating system [40, 49] supports a special path abstraction that represents a stream of data flowing through several subsystems, e.g. packets of a certain TCP connection. Resource Containers [3] can be used to account resource consumption towards individual activities; for example, a single thread can serve requests ....
David Mosberger and Larry L. Peterson. Making paths explicit in the Scout operating system. In Proceedings of the second symposium on Operating systems design and implementation, pages 153--167. ACM Press, Oct 1996.
....it desires its current activity (e.g. the consumption of CPU cycles, or the protocol processing for the tra#c on a particular socket) to be accounted. Eclipse [Bruno99] provides a similar form of resource control, using a reservation file system to model hierarchical resource guarantees. Scout [Mosberger96b] takes the two preceding ideas a step futher, representing all activity in terms of paths. The informal notion of a path, commonly used in terminology such as fast path and data path , is formalised to consist a set of modules referred to as routers that process a particular class of ....
David Mosberger and Larry L. Peterson. Making Paths Explicit in the Scout Operating System. In OSDI [OSD96], pages 153--167. (p 35)
....context switch overhead. We support this thread per packet approach for Infopipe components that are implemented in a way that allows direct method calls. Alternatively, developers may choose to program in an thread like style if this simplifies the program structure. The Scout operating system [23] generalizes from the x kernel by combining linear flows of data into paths. Paths provide an abstraction to which the invariants associated with the flow can be attached. These invariants represent information that is true of the path as a whole, but which may not be apparent to any particular ....
D. Mosberger and L. L. Peterson. Making paths explicit in the Scout operating system. In Proceedings of the second USENIX symposium on Operating systems design and implementation (OSDI). USENIX, October 1996.
....components across protection domains or networks. THINK does not employ wholeprogram optimization and relies on dynamic dispatch. We do not believe this model, with its associated runtime cost, is appropriate for network embedded systems. Other component oriented systems include Click [36] Scout [37], and the x kernel [17] These systems are more specialized than nesC and do not support wholeprogram optimization (apart from several optimizations in Click [24] or bidirectional interfaces. Traditional real time and embedded operating systems, such as VxWorks [51] QNX [42] and WinCE [33] ....
D. Mosberger and L. L. Peterson. Making Paths Explicit in the Scout Operating System. In Operating Systems Design and Implementation, pages 153--167, 1996.
....be dynamically downloaded and installed into the OS kernel and binding plugin instances to flows. PromethOS s plugin concept has been inspired mostly from this project. While ANN provides many of the concepts implemented, PromethOS requires less modification of the original network stack. Scout [19] proposes a path based approach where the functionality of a standard IPcompliant router is decomposed into a sequence of a interconnected components forming a path. Recently, Scout has been ported to Linux [4] however requiring to replace most of the Linux network stack with the Scout ....
David Mosberger, Larry Peterson, "Making Paths Explicit in the Scout Operating System," Operating Systems Design and Implementation, pages 153-167, 1996.
....libraries, allowing ordinary users fine grained control. Alternatively, extensions were developed for both operating systems to allow applications to define application specific handlers that may be installed directly into the kernel (Plexus [14] and ASHs [27] Operating systems such as Scout [21] and x kernel [16] were designed explicitly to support sophisticated network based applications. In these systems, users may even redefine network or transport layer protocol functions in an application specific fashion [6] With TESLA, our goal is to bring some of the power of these systems ....
MOSBERGER, D., AND PETERSON, L. L. Making paths explicit in the Scout operating system. In Proc. OSDI '96 (Oct. 1996), pp. 153--167.
....is not efficient enough compared with other programming languages and thus not adequate for many networking services, whereas our approach supports all programming languages. The Naccio project of MIT [2] uses also the mechanisms provided by Java. Joust [6] is a Java active OS implemented in Scout [12] and provides a Java virtual machine for the execution of active services. The measurements were made with a Pentium III 800 machine running Linux 2.4.18 kernel and AMnet version 1 [17] XI Regarding active networking projects, the Seraphim project [10, 13] must be mentioned. It follows the ....
David Mosberger and Larry L. Peterson. Making paths explicit in the scout operating system. In Operating Systems Design and Implementation, pages 153--167, 1996.
....the cost of context switching and to provide predictable scheduling. The RIO work built on these ideas and moved them from the NetBSD environment to a multi threaded, preemptive kernel environment with the protocol processing moved back into the kernel. I O subsystem support for QoS: The Scout OS [77, 78] employs the notion of a path to expose the state and resource requirements of all processing components in a flow. Similarly, our RIO subsystem reflects the path principle and incorporates it with TAO to create a vertically integrated real time ORB endsystem. For instance, RIO subsystem resources ....
D. Mosberger and L. Peterson, "Making Paths Explicit in the Scout Operating System," in Proceedings of OSDI '96,Oct. 1996.
....PLANet [9] is another active networking project. The project uses a type safe, resource limited, functional programming language with dynamic type verification. The Naccio project of MIT [2] uses also the mechanisms provided by Java. Joust [6] is a Java active OS implemented in Scout [13] and provides a Java virtual machine for the execution of active services. The key idea behind history based access control [1] is to maintain a selective history of the access requests made by individual programs and to use this history to improve the differentiation between safe and potentially ....
David Mosberger and Larry L. Peterson. Making paths explicit in the scout operating system. In Operating Systems Design and Implementation, pages 153--167, 1996.
....with messages rather than with protocols, a thread shepherds a message through a series of protocols without context switches. The Scout operating system takes the idea of minimizing the cost of multiple protocol layers one step further and explicitly specifies paths through the protocol stack [70]. Thus the system is able to apply software optimizations such as common subexpression and dead code elimination, inlining and constant folding at a large scope and with better results. In addition, scheduling decisions can be based on the entire path of a message, thus enabling the kernel to ....
D. Mosberger and L.L. Peterson, "Making Paths Explicit in the Scout Operating System," Proc. Usenix 2nd Symp. OS Design and Implementation (OSDI `96), Usenix Assoc., Berkeley, Calif., 1996, pp. 153-168. 182
....servers using the native Java serialization and RMI mechanisms. Servlet sessions include only application state, however, and do not reference any network connections or system resources (e.g. files, locks, timers, etc. that may be needed. In contrast, Resource Containers [10] and Scout paths [71] both provide mechanisms to associate application and system resources, allowing system resources to be charged to individual sessions. IO Lite [86] goes one step further by blurring the distinction between system and application state. Network buffers in IO Lite are at once application and system ....
David Mosberger and Larry L. Peterson. Making paths explicit in the Scout operating system. In Proc. 2nd USENIX Symposium on Operating Systems Design and Implementation, pages 153--167, Seattle, Washington, October 1996.
.... i terrupt latency.Si)#I rly, ihi h speed local andwi5# area networks, selectiq proper blocksi( toexploi i ntriqRW concurrencyi n communiR ti npi eli5# i a key iq sue [7] 27] As the final example where communi cati on pi eli;H di;HHq performances we menti5 path ori6 ted operati ng systems [16]. Therefore,i ti s not surpri si ng that recently thequestiq of how toiq)W ve the performance of a system pi eliR recei ed a great deal of attenti5 i n computer archi(C( q6# operati5 systems, andcompi;Iq communi#WCq The essence of the problemi s abstractedi n a recent work [24] where thediC5;Iq6H ....
D. Mosberger, L.L. Peterson. Making paths explicit in the Scout operating sy stem. USENIX Symposium on Operating Systems Design and Implementation, pp. 28-31, October 1996.
....feedback on application performance when determining allocations. One important exception is feedback driven scheduling [13] in which application performance is used to tune scheduling parameters. Reservation and share based resource limits have been explored in depth by systems such as Scout [14], Nemesis [12] Resource Containers [3] and Cluster Reserves [2] These techniques work well for real time and multimedia applications, which have relatively static resource demands that can be expressed as straightforward, fixed limits. For this class of applications, guaranteeing resource ....
D. Mosberger and L. Peterson. Making paths explicit in the Scout operating system. In Proc. OSDI '96, October 1996.
....often be modified which people are hesitant to do. An alternative approach is to change the internals of an existing operating system while maintaining the user API (application programming interface) Paper E presents SILK (Scout in the Linux Kernel) which is a port of the Scout operating system [43] to run as a kernel module in the popular Linux operating system. SILK is a modular, configurable, communication oriented operating system developed from scratch for small network appliances. By running in the Linux kernel, SILK can take advantage of existing Linux applications with small or no ....
....use, so far. New QoS mechanisms for mainstream operating systems are often only available for specific versions of the operating system. Due to feature interaction problems between di#erent kernel patches, it is often impossible to combine several of these mechanisms into one system. Scout [43] is a modular, configurable, communication oriented operating system tailored for small network appliances. Scout combines features such as early demultiplexing, early dropping, resource accounting, explicit scheduling and extensibility into a single abstraction called a path. SILK is a port of ....
D. Mosberger and L. Peterson. Making paths explicit in the Scout operating system. In USENIX Symposium on Operating Systems Design and Implementation, pages 153--168, Seattle, WA, USA, October 1996.
....Panama. Specifically, it attempts to make routers open and general purpose computation and communication systems so that they can support a wide variety of protocol specific and application specific packet processing functions. The Extensible Router uses an explicit path abstraction, introduced in [2], that models data flow from input device to output device, possibly with computation interposed along the way. Moreover, a hierarchy of such paths is proposed with different combinations of hardware, kernel and user level subpaths. A classification hierarchy is also proposed, to support ....
D. Mosberger, L. Peterson; "Making Paths Explicit in the Scout Operating System"; Proc. OSDI 1996.
....a Proboscis a data access path to a storage device. The current set of code modules allows a node in the cluster to construct Proboscises that provide access to a remote storage device as a local storage device. Presently, the framework does not support dynamic reconfiguration. Previous research [27, 26] has shown that modular approaches can be efficient, and as the Proboscis extensions are coarsegrained, e.g. an access control extension, the overhead due to modularity is low. The current extensions implement a block based view of the storage devices, but other views, e.g. object based ....
....multiprocessors has previously been proposed by Kotz et.al. 22] Our work adds a framework for remote disk access with more complex functionality and provides a validation based on modern cluster hardware. The design of the Proboscis data structure is inspired by the path concept used in Scout [27]. In Scout, however, the concept of a path is viewed as extending beyond a single node, but the actual path data structures are confined to a single node. Furthermore, Proboscis focuses on optimizing data storage traffic, and as such, is less general in its scope. A Proboscis views a data path in ....
D. Mosberger and L. L. Peterson. Making Paths Explicit in the Scout Operating System. In Proc. of the Second USENIX Symposium on Operating System Design and Implementation, pages 153--167, September 1996.
....to flexible binding is not new. Several works, e.g. 4, 10, 27] have proposed flexible binding models for distributed middleware platforms. The Nemesis operating system [13] introduces bindings for the handling of multimedia communication paths. The path abstraction in the Scout operating system [19] can be understood as an in system binding abstraction. And channels in the NodeOS operating system interface for active routers [22] correspond to low level packetcommunication oriented bindings. None of these works, however, has considered the use of a general model of component binding as a ....
....namely a resource management framework and a communication framework. The resource management framework is original, whereas the communication framework is inspired by the x kernel [11] Other operating system level component based frameworks include Click [18] Ensemble [15] and Scout [19]. These frameworks, however, are more specialized than THINK or OSKit: Click targets the construction of modular routers, Ensemble and Scout target the construction of communication protocol stacks. We thus believe that THINK is unique in its introduction and systematic application of a flexible ....
D. Mosberger and L. Peterson. Making Paths Explicit in the Scout Operating System. In OSDI'1996 [21].
....maintain paint colors, and operate on any packets that fit the match criteria of existing reflection requests according to rules presented in Chapters 3 and 4. 5. 2 Hardware The ns implementation of reflection and painting could easily be ported to software routers, such as Click [23] or Scout [28]. It would also be an appropriate codebase for the addition of the primitives to standard operating systems. High speed routers, however, are likely to have very di#erent requirements. The data path of a high speed router should consist of steps that can be implemented in hardware. For the ....
David Mosberger and Larry L. Peterson. Making paths explicit in the Scout operating system. In Proc. 2nd Symposium on Operating Systems Design and Implementation (OSDI '96), pages 153--167, October 1996.
No context found.
D. Mosberger and L. L. Peterson. Making Paths Explicit in the Scout Operating System. In Proc. 2nd OSDI, pages 153--167, Seattle, WA, Oct 1996.
No context found.
David Mosberger and Larry Peterson. Making paths explicit in the Scout operating system. In Proceedings of the Second Symposium on Operating Systems Design and Implementation, pages 153--168, October 1996.
No context found.
D. Mosberger and L. L. Peterson. Making paths explicit in the Scout operating system. In Proc. OSDI, pages 153--167. ACM Press, 1996.
No context found.
D. Mosberger and L. L. Peterson. Making Paths Explicit in the Scout Operating System. In Operating Systems Design and Implementation, 1996.
No context found.
David Mosberger and Larry L. Peterson. Making paths explicit in the Scout operating system. In Proceedings of the 2nd Symposium on Operating Systems Design and Implementation (OSDI '96), pages 153167, Seattle, WA, October 1996.
No context found.
D. Mosberger and L. L. Peterson. Making paths explicit in the Scout operating system. In Proc. OSDI, pages 153--167. ACM Press, 1996.
No context found.
D. Mosberger and L. L. Peterson. Making paths explicit in the Scout operating system. In Proc. OSDI, pages 153--167. ACM Press, 1996.
No context found.
D. Mosberger and L. Peterson, "Making paths explicit in the Scout operating system," OSDI'96, 1996.
No context found.
David Mosberger, Larry Peterson, Making Paths Explicit in the Scout Operating System, Operating Systems Design and Implementation, pages 153-167, 1996.
No context found.
David Mosberger and Larry L. Peterson. Making paths explicit in the Scout operating system. In Proceedings of the Second Symposium on Operating Systems Design and Implementation (OSDI '96), pages 153-- 167, Seattle, Washington, October 1996.
No context found.
D. Mosberger and Larry Peterson, "Making Paths Explicit in the Scout Operating System," Proceedings of the Symposium on Operating Systems Design and Implementation, October, 1996.
No context found.
D. Mosberger and L. L. Peterson. Making paths explicit in the scout operating system. In Proceedings of the Second Symposium on Operating Systems Design and Implementation, Seattle, WA, Oct. 1996.
No context found.
D. Mosberger and L. L. Peterson, "Making paths explicit in the Scout operating system ". In Operating Systems Design and Implementation, pp. 153--167, 1996.
No context found.
D. Mosberger and L. L. Peterson. Making paths explicit in the Scout operating system. In Proc. of the 2nd OSDI, pp. 153--167, Seattle, WA, Oct. 1996.
No context found.
D. Mosberger and L. Peterson, \Making paths explicit in the Scout operating system," OSDI'96, 1996.
No context found.
D. Mosberger and L. L. Peterson. Making paths explicit in the Scout operating system. In Proceedings of the second USENIX symposium on Operating systems design and implementation (OSDI). USENIX, October 1996.
No context found.
MOSBERGER, D., AND PETERSON, L. L. Making Paths Explicit in the Scout Operating System. In OSDI (1996).
No context found.
D. Mosberger and L. L. Peterson. Making paths explicit in the Scout operating system. In Proceedings of the Second Symposium on Operating Systems Design and Implementation, pages 153--167, Seattle, WA, Oct. 1996. USENIX Association.
No context found.
D. Mosberger and L. L. Peterson. Making Paths Explicit in the Scout Operating System. In OSDI, 1996.
No context found.
David Mosberger and Larry L. Peterson. Making Paths Explicit in the Scout Operating System. In Operating Systems Design and Implementation, pages 153-167, 1996.
No context found.
D. Mosberger and L. Peterson, "Making paths explicit in the Scout operating system," OSDI'96, 1996.
No context found.
D. Mosberger and L. L. Peterson, "Making Paths Explicit in the Scout Operating System", presented at In Proceedings of the Second Symposium on Operating Systems Design and Implementation, 1996.
No context found.
Mosberger D, Peterson LL. Making paths explicit in the Scout operating system. In Proceedings of the second USENIX symposium on Operating systems design and implementation (OSDI). USENIX, 1996; .
No context found.
D. Mosberger and L. L. Peterson. Making paths explicit in the Scout operating system. In Proc. of the 2nd OSDI, pp. 153--167, Seattle, WA, Oct. 1996.
No context found.
D. Mosberger and L. L. Peterson. Making Paths Explicit in the Scout Operating System. In Proceedings of the Second USENIX Symposium on Operating System Design and Implementation (OSDI), pages 153--167, Seattle, Washington, October 1996.
No context found.
D. Mosberger and L. L. Peterson. Making Paths Explicit in the Scout Operating System. In Proceedings of the 2nd Symposium on Operating Systems Design and Implementation (OSDI), pages 153--167, 1996.
No context found.
D. Mosberger and L. L. Peterson. Making Paths Explicit in the Scout Operating System. In OSDI, 1996.
No context found.
D. Mosberger and L. Peterson. "Making Paths Explicit in the Scout Operating System." Proceedings of the Symposium on Operating Systems Design and Implementation, October, 1996.
No context found.
Mosberger, D. and L. Peterson, Making Paths Explicit in the Scout Operating System. 1996, Technical Report 96-05, Dept. of Computer Science, University of Arizona.
No context found.
D. Mosberger and L. Peterson, "Making Paths Explicit in the Scout Operating System," Proc. OSDI '96.
First 50 documents Next 50
Online articles have much greater impact More about CiteSeer.IST Add search form to your site Submit documents Feedback
CiteSeer.IST - Copyright Penn State and NEC