Tschudin, C. "Flexible Protocol Stacks," Proceeding of the ACM conference on Communications architecture & protocols, 1991, pp. 197-205.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....stacks have been the subject of a considerable amount of research in the past. Related work can be found under the topics of flexible protocol stacks, adaptive protocol stacks, universal asynchronous protocol interfaces, object oriented transport components, configurable protocol stacks, and so on [6 9]; all address the issue of programmable transport, but do not consider issues of QoS. Reference [10, 11] addresses both QoS and programmability issues; 12] presents the x kernel, an operating system environment that provides an explicit architecture for constructing and composing network ....

....key transport system services and illustrates the concepts with a survey of four operating system transport architectures, namely, System V and BSD UNIX, the x kernel, and Choices. Finally, 14] addresses many of the issues related to the implementation of protocol stacks at the user level. In [6] a protocol environment populated by standard communication functions is proposed. Applications have the ability to compose protocol stacks out of the standard protocol entities by interconnecting them. A generic communication bootstrap procedure is proposed, where new protocol components can be ....

[Article contains additional citation context not shown here]

C. Tschudin, "Flexible Protocol Stacks," Proc. ACM SIGCOMM '91, Zurich, Switzerland, 1991, pp. 197--204.

....be a key architectural principle . They suggested Integrated Layer Processing (ILP) for efficiency reasons. That is, combining the operations done in different layers into one. Other systems relax layering constraints by allowing protocol implementations to be composed from protocol entities [9] [10] The x Kernel [11] works similarly, allowing an objectoriented like approach, where the relationship between protocol objects with uniform interfaces are defined to create protocol paths through the protocol objects. However, none of the above systems provide the application programmer ....

C. Tschudin, "Flexible protocol stacks," in ACM SIGCOMM Symposium on Communications Architectures and Protocols, pp. 197--205, September 1991.

....itself encapsulated, as it would be in a layered architecture. 1.3 Prior Work There have been very many papers about di erentways to generalize protocol design and processing, to ease the limitations of strictly layered stacks of complex protocols and of monolithic implementations. Early work [3, 9] emphasized the modular construction of protocol processing stacks for exibility and extensibility. Many later papers have discussed the decomposition of complex protocols into ###############, either for reusability, customization, and ease of programming [1, 5, 8, 6] or to improve protocol ....

C. Tschudin. Flexible Protocol Stacks ##### ### ####### ###, 197-204, 1991.

.... on DECstation5000 200s [12] A number of more recent experiments measured on top of the Exokernel system will appear in [15] 7 Related work There have been many instances of ad hoc ILP, for example, in many networking kernels [4] There is also quite a bit of work on protocol composition [8, 14, 9, 2, 13]. The system to provide an automatic modular mechanism for ILP is Abbott and Peterson [1] They describe an ILP system that composes macros into integrated loops at compile time, eliminating multiple data traversals. Each macro is written with initialization and finalization code and a main body ....

C. Tschudin. Flexible protocol stacks. In Proc. SIGCOMM 1991, pages 197--204, August 1991.

....that upcalls and downcalls through the protocol layers translate into subclass and superclass method invocations seems particularly elegant and useful, although it is inherently static. Others have experimented with flexible protocol composition mechanisms at the lower layers [Hutchinson 1989] [Tschudin 1991]. The concept of a more flexible protocol stack is achievable in OOSI using object oriented techniques and may be incorporated in a future version. Good quantitative performance comparisons of OOSI and ISODE are not available at this time. Measurements shall be obtained in the near future. For ....

Christian Tschudin. "Flexible Protocol Stacks," ACM SIGCOMM'91 Conference Proceedings, September 1991, pp. 197--205.

....infrastructure for concurrent object oriented applications in a multi protocol environment. The goal of this framework is to create an extensible and efficient set of abstractions that facilitate the instantiatiation of multiple and diverse sets of communication services within an application [17]. This object oriented protocol development framework is called OOSI (ooo zi ) Similar research oriented upper layer protocol development environments that we are familiar with include ELROS [2] OTSO [11] DAS [14] and ISODE [15] OOSI was influenced by ISODE, but is engineered for maximum ....

Christian Tschudin. Flexible protocol stacks. In SIGCOMM'91 Conference Proceedings, pages 197--205, September 1991. 16

....better than the transmission subsystem how to 2 process data when there is some lost on the network or when data arrive out of order. But to interact directly and more efficiently with the transport, an application needs a fine grained control over the communication subsystem. Previous work [Tsc91] CD94] SSS 93] has shown the interest of designing and implementing flexible transport and to decompose the protocol in fine grain functions. But we think this approach may be extended to integrate the transmission mechanism into the application [CH94] One major interest of ALF is its ....

C. Tschudin. Flexible Protocol Stack. In SIGCOMM Symposium on Communications Architectures and Protocols, pages 197--205, Zurick, Switzerland, September 1991.

....transport protocol used either TCP IP or a specific transport such as described in [ BN84] More and more new applications using different traffic types such as text, audio and video ask for diverse transport requirements of error or flow control for example. To solve this problem, Tsc91] BSS92] explored the ability to design and implement flexible transport protocols tailored to the application. We think this approach may be extended to integrate the transmission control mechanism within the application. In order to consider the communication requirements within a distributed ....

C. Tschudin. Flexible Protocol Stack. In SIGCOMM Symposium on Communications Architectures and Protocols, pages 197--205, Zurick, Switzerland, September 1991.

....Layering has been the main conceptual approach to structure protocols. The advantage of layering is to reduce complexity of communication systems by hiding information between different layers. However, a number of problems with regard to layering have been identified such as inflexibility [35], inefficiency [33] and even unexpected side effects [12] A lot of work tackles the efficiency problems of layering. Clark [7] and Cooper [10] propose to carefully break up the borders and allow adjacent layers to exchange control information. Clark [8] and Atkins [1] suggested to apply ....

C. Tschudin. Flexible protocol stacks. In Proceedings of ACM SIGCOMM, Zurich, Switzerland, Oct. 1991.

....of new communication modules. Early results with Horus suggest that these compositional formulations simplify implementation but can introduce overheads similar to those encountered when layering MPICH on Nexus: additional message header information, function calls, and messages. Tschudin [28] and the Fox project [2] have explored similar concepts and report similar results. Finally, we note that the concept of a global pointer is used in other systems, notably Split C [9] to support remote put and get operations within homogeneous systems. The global pointer and RSR approach to ....

C. Tschudin. Flexible protocol stacks. In Proc. ACM SIGCOMM '91. ACM, 1991.

....are combined in a single network. Instead of an architecture specific solution, however, we seek an approach general enough for problems involving future architectures as well as today s. Among others considering the general inter operability problem, Tschudin has described a generic protocol [18] allowing communicating systems to exchange descriptions of arbitrary protocols before using them to communicate. Similar in philosophy is the meta protocol concept proposed by Meandzija [8] In contrast, one of the explicit goals of our work is to minimize the number of things (including ....

....for that host are not correctly updated, other hosts will be unable to establish communication with that host. While current network hosts change protocol architectures no more frequently than they change addresses, recent research suggests that this may not always be the case in the future [12, 18]. The question of accuracy of the DNS entries has been raised in the Internet community. Indeed the Internet host requirements document [1] specifically warns that a host should not rely on the WKS entries to provide accurate information regarding the services available from another host. These ....

C. Tschudin. Flexible protocol stacks. In Computer Communication Review, pages 197--205. ACM Press, September 1991.

....networks. 5 Related Work We believe our approach is novel in its application of mobile code, demand loading, and caching techniques within the network layer. The most similar recent work we are aware of is the messenger paradigm [6] and work on flexible protocol stacks that preceded it [18]. Like our system, this work allows new protocols to be deployed. The intent, however, is to investigate the structuring of communicating systems, including distributed operating systems and intelligent agents. As such, it lacks the network layer specializations, e.g. demand loading, that we have ....

C. Tschudin. Flexible Protocol Stacks. In SIGCOMM '91, 1991.

....environment in a way that still guarantees small latencies while also providing strong protection guarantees. 2.3. 3 ILP and protocol composition There have been many instances of ad hoc ILP, for example, in many networking kernels [12] There is also quite a bit of work on protocol composition [6, 27, 28, 58, 59]. The first system to provide an automatic modular mechanism for ILP is Abbott and Peterson [1] They describe an ILP system that composes macros into integrated loops at compile time, eliminating multiple data traversals. Each macro is written with initialization and finalization code and a main ....

....impact on efficiency: since untrusted software cannot augment these operations, any integration that was not anticipated by the network architects is penalized. Given the richness of possible operations, such mismatches happen quite easily. Furthermore, many systems compose protocols at runtime [6, 27, 28, 58, 59], making static ILP infeasible. There are additional disadvantages to static ILP: static code size is quite large, since it grows with the number of possible layers instead of actually used layers, and augmenting the system with new protocols is a heavyweight operation that requires, at least, ....

C. Tschudin. Flexible protocol stacks. In Proc. SIGCOMM 1991, pages 197--204, Zurich, Switzerland, September 1991.

....decomposition (i.e. one protocol graph) for each T service. To create a protocol entity each protocol function must be instantiated by one of its modules. The configuration process selects the most suitable module to configure the best fitting protocol at connection establishment time. 5 Tschudin [9] calls T services anchored instances . A Run time Environment for Da CaPo Proc. INET 93 M. Vogt BFC 3 T CT interface AC interface protocol function dependency A Figure 2: Example of a protocol graph II.B. The Configuration Process (CP) The task of the configuration process (CP) is to ....

Tschudin, C.: "Flexible Protocol Stacks", in: SIGCOMM '91 Conference, Communications Architectures & Protocols, Zürich, Switzerland, Computer Communications Review; Volume 21, Number 4, Sep. 1991, pp. 197-204.

....conventional networks. 5 Related Work We believe our approach is novel in its application of mobile code, demand loading, and caching techniques to the network layer. The most similar recent work we are aware of is the messenger paradigm [8] and work on flexible protocol stacks that preceded it [20]. Like our system, this work allows new protocols to be deployed. The intent, however, is to investigate the structuring of communicating systems, including distributed operating systems and intelligent agents. As such, it lacks the network layer specializations, e.g. demand loading, that we have ....

C. Tschudin. Flexible Protocol Stacks. In SIGCOMM '91, 1991.

....of new communication modules. Early results with Horus suggest that these compositional formulations simplify implementation but can introduce overheads similar to those encountered when layering MPICH on Nexus: additional message header information, function calls, and messages. Tschudin [28] and the Fox project [2] have explored similar concepts and report similar results. Finally, we note that concepts similar to the Nexus communication link are used in other systems. For example, Split C [9] uses a global pointer construct to support remote put and get operations within homogeneous ....

C. Tschudin. Flexible protocol stacks. In Proc. ACM SIGCOMM '91. ACM, 1991.

.... without casting aside good structuring principles and mechanisms, such as information hiding and ADTs The structure efficiency problem is further complicated by today s multi protocol platforms that require flexible composition of protocols in order to meet the diverse needs of applications [14, 68]. The new thinking in protocol engineering is to be less myopic about the structure and performance of the lower layers in isolation and refocus on the structure and performance of the upper layers, with specific concern for the end to end needs of applications. This change in focus is the result ....

Christian Tschudin. Flexible protocol stacks. In SIGCOMM'91 Conference Proceedings, pages 197--205, September 1991.

....Both Multimedia Application Requirements and Network Characteristics: ADAPTIVE configures transport system sessions based upon the network characteristics and the QoS requirements of applications. Other related work on transport systems typically emphasizes either diverse application requirements [6, 25, 30] or network characteristics [3, 19] Moreover, existing implementations of transport systems tend to focus more on (1) traditional data applications such as bulk text file transfer and or (2) traditional local area network environments such as Ethernet or Token Ring. B) Reduction in Transport ....

....network environments [19, 20, 34, 35, 36] 6. Develop alternative transport system architectures based on (a) vertical process architectures [7, 37] b) parallel processing of protocol functions [3, 4, 19] c) flexible protocol stacks that require fewer layers and or are dynamically assembled [6, 25, 26, 30], and (d) modular and extensible transport system software that supports these flexible protocol stacks [2, 18, 38] The ADAPTIVE architecture we are developing extends prior research on flexible transport system architectures. In particular, ADAPTIVE employs techniques from categories 4 ....

[Article contains additional citation context not shown here]

C. Tschudin, "Flexible Protocol Stacks," in Proceedings of the Symposium on Communications Architectures and Protocols (SIGCOMM), (Zurich Switzerland), pp. 197--205, ACM, Sept. 1991.

.... to separate communication software more clearly from the OS s kernel, the STREAMS concept represents an important example of this approach [Strea 90] ffl Dynamically adaptable protocol stacks are proposed as a means to overcome the problems of interworking of different protocol architectures [Tschu 91] ffl A highly layered stack architecture and the use of both micro protocols and virtual protocols have been devised and implemented, showing similar or even better performance than monolithic protocol stacks [OMall 91] ffl In the area of high speed networking, the assembly of protocol ....

....1 with process P 3 . This simb) after link reconfiguration a) before link reconfiguration in P in P P1 P2 P1 P2 P3 P3 Figure 6: A dynamic reconfiguration of a communication link of process P 1 by its father P ple reconfiguration mechanism is the basis for building flexible protocol stacks [Tschu 91] A simple example will show how a COMSCRIPT process can configure its local protocol stack to meet its own requirements; a second one will present how configuration of a remote protocol stack is achieved. 4.1 Local stack (re)configuration: A simple example Building a flexible protocol stack is ....

Tschudin Chr. F., Flexible Protocol Stacks, In SIGCOMM '91 Conference on Communications Architectures & Protocols, pp. 197--204, Sept. 1991.

....protocols. The general idea of using partial evaluation to gain better I O performance in systems has been used elsewhere as well [16] In particular, the notion of specializing a transport protocol to the needs of a particular application has been the motivation behind many recent system designs [12, 23, 27]. 1.2 Alternative Protocol Structures The discussion above argues for alternatives to monolithic protocol implementations since they are deficient in at least two ways. First, having all protocol variants executing in a single address space (especially if it is in kernel) complicates code ....

Christian Tschudin. Flexible protocol stacks. In Proceedings of the 1991 SIGCOMM Symposium on Communications Architectures and Protocols, pages 197--205, September 1991.

....mk byteswap pipe(pl) Compile the two pipes, returning a handle to the integrated function ilp = compile pl(pl, PIPE WRITE) Figure 1: Compose and compile checksum and byteswap pipes. ble operations, such mismatches happen quite easily. Furthermore, many systems compose protocols at runtime [5, 23, 24, 41, 42], making static ILP infeasible. There are additional disadvantages to static ILP: static code size is quite large, since it grows with the number of possible layers instead of actually used layers, and augmenting the system with new protocols is a heavyweight operation that requires, at least, ....

....abort have been recently explored in Optimistic Active Messages [46] The tradeoffs discussed there are applicable here. ILP and protocol composition There have been many instances of ad hoc ILP, for example, in many networking kernels [9] There is also quite a bit of work on protocol composition [5, 23, 24, 41, 42]. The first system to provide an automatic modular mechanism for ILP is Abbott and Peterson [1] They describe an ILP system that composesmacros into integrated loops at compile time, eliminating multiple data traversals. Each macro is written with initialization and finalization codeand a main ....

C. Tschudin. Flexible protocol stacks. In ACM Communication Architectures, Protocols, and Applications (SIGCOMM '91), pages 197--204, Zurich, Switzerland, September 1991.

....new protocols. The x Kernel currently runs as a dedicated protocol server and provides an RPC stub library that implements the socket interface. Our system is complementary to the x Kernel s, as ours facilitates the integration of protocols into a complete operating system environment. Tschudin [Tschudin 91] advocates a protocol server into which protocol implementations can be dynamically loaded and unloaded. We are not aware of an implementation of these ideas. Clark and Tennenhouse [Clark Tennenhouse 90] assert that protocol layering is a desirable design but undesirable implementation ....

Tschudin, C. Flexible Protocol Stacks. In Proceedings of the SIGCOMM '91 Symposium, pages 197--204, September 1991.

.... Principles Adequately supporting the diversity of application requirements and network characteristics described in Section 1 requires a flexible transport system architecture that provides communication service appropriate for the specific traffic sources and underlying network technologies [11, 12, 13]. ADAPTIVE allows the behavior of a communication session to be precisely tailored to the required service by implementing a protocol in terms of a set of independently recombinable protocol mechanisms. This independence is achieved through the strict use of uniform abstract interfaces to each set ....

C. Tschudin, "Flexible Protocol Stacks," in Proceedings of the Symposium on Communications Architectures and Protocols (SIGCOMM), (Zurich Switzerland), pp. 197--205, ACM, Sept. 1991.

.... as well as virtual protocols has been devised and implemented, showing similar or even better performance figures than monolithic protocol stacks [10] ffl Dynamically adaptable protocol stacks are proposed as a mean to overcome the problems of interworking of different protocol architectures [16]. ffl Inside existing operating systems a need has been identified to separate communication software more clearly from the OS s kernel, for which the STREAMS concept is an important example [15] It must be emphazised that such developments go beyond the reference models of virtually all ....

....serialize deserialize operators is needed which also offers XDR [12] and ASN.1 [7] functionality. ffl User Defined Devices and Protocol Entites: The definedevice operator can be used to install new devices which extend in different ways the basic devices offered by the COMSCRIPT interpreter. In [16] this is called an anchored resource because such instances are tied to the environment in which they are created. Protocol Entities on the other side are floating in the sense that they can be defined and instantiated independely of the actual COMSCRIPT interpreter and its set of basic ....

Christian F. Tschudin. Flexible Protocol Stacks. In SIGCOMM '91 Conferenceon CommunicationsArchitectures & Protocols, pages 197--204, September 1991.

No context found.

Tschudin, C. "Flexible Protocol Stacks," Proceeding of the ACM conference on Communications architecture & protocols, 1991, pp. 197-205.

First 50 documents

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