G. Chesson, "The Protocol Engine Project," Proceedings of the Summer 1987.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....the application level transfer rates on existing local area networks remain much lower and it is doubtful that they can keep pace with medium speed. For example, out of the 10 Mbit sec available at the medium of an Ethernet network, only around 1. 2 Mbit sec bandwidth is available for applications [10]. Consequently, it has been established that current clusters of workstations have the aggregate computing power to provide an environment for high performance distributed computing, while high speed networks, capable of supporting these com puting rates, are becoming a standard (e.g. ATM, ....

G. Chesson, "The Protocol Engine Project," Proceedings of the Summer 1987.

....to the token holding time we can achieve high throughput and bounded response time. To increase the efficiency of the protocol, computationally intensive functions should be moved from high layers to lower layers. This will lead to implementation of protocols in hardware, and as pointed out by [11] real time processing of incoming packets will avoid potential bottlenecks. For example, a checksum calculation at the transport layer will be implemented in software and will run on the host processor. If performed at the data link layer a checksum will be implemented in hardware on the NIU. ....

....frame design. The separation of header from control data in a frame eases the implementation of protocol functionalities in hardware. This separation allow simple addition deletion of protocol headers. Proper placement of header information fields allows parallel processing of incoming packets [11]. Segmentation based on application requirements: i.e. application layer framing [15] The responsibility of retransmission is assigned to higher layers. One or two bits in error will trigger a checksum error. However, this may only cause a change in gray level readings in one or two pixels in an ....

G. Chesson, "The protocol engine project," in Unix review, September 1987.

....Xpress Transfer Protocol (XTP) A Tutorial Robert M. Sanders Department of Computer Science University of Virginia ABSTRACT Throw away. Throw away. Introduction Throw this page away. asdas asdasd asdasd [1] wer wer wer dfsdffsdsdfsdf. [2] wer wer wer dfsdffsdsdfsdf. 3] wer wer wer dfsdffsdsdfsdf. 4] wer wer wer dfsdffsdsdfsdf. 5] wer wer wer dfsdffsdsdfsdf. 6] The Xpress Transfer Protocol (XTP) A Tutorial Robert M. Sanders and Alfred C. Weaver Computer Networks Laboratory Department of Computer Science ....

.... Hall University of Virginia Charlottesville, Virginia 22903 rms4t virginia.edu, weaver virginia.edu Introduction XTP is a reliable, real time, lightweight transfer 1 layer protocol being developed by a group of researchers and developers coordinated by Protocol Engines Incorporated (PEI) [1,2,3 ] Current transport layer protocols such as DoD s Transmission Control Protocol (TCP) 4] and ISO s Transport Protocol (TP) 5] were not designed for the next generation of high speed, interconnected reliable networks such as FDDI and the gigabit second wide area networks. Unlike all previous ....

Chesson, Greg, "The Protocol Engine Project", UNIX Review, Vol. 5, No. 9, September 1987.

....surveyed here because it is largely concerned with issues intrinsic to parallel host computers rather than with the off host design issues presented in chapter two. 3.2. Chesson A pioneering effort in the development of off host protocol architectures was Greg Chesson s Protocol Engine project [9]. The goal of this project was to develop the Protocol Engine, a custom VLSI protocol processor for the Xpress Transfer Protocol (XTP) XTP possesses two unique architectural features relevant to off host protocol processing. First, 39 it is a transfer layer 1 protocol spanning both the ....

G. Chesson, "The Protocol Engine Project," Unix Review, September 1987.

....acknowledgments is likely to add significant latency. The throughput is also expected to drop. We will study these aspects quantitatively in detail. VISTAnet NIU Communications Research pg. 10 Much has been written in the literature about alternative protocols for high speed low error networks [2,3,4,7] as well as adaptations of common protocols [4] The feasibility of alternative transport protocols for the NIU will be evaluated in conjunction with efforts to install these protocols on the Cray and medical workstation. 4.3 Hardware Architecture 4.3.1 Buffer size Because of expected buffer ....

G. Chesson, "The protocol engine project," UNIX Rev., vol. 5, no. 9, pp. 70-77, Sept., 1987.

....the application level transfer rates on existing local area networks remain much lower and it is doubtful that they can keep pace with medium speed. For example, out of the 10 Mbit sec available at the medium of an Ethernet network, only around 1. 2 Mbit sec bandwidth is available for applications [18]; it is therefore not enough to have a Gigabit data link if user applications could only use a small portion of that bandwidth. Consequently, it has been established that current clusters of workstations have the aggregate computing power to provide an environment for high performance distributed ....

....processes can be given as R global = n Delta R where n is the number of parallel activities in a given application. HCP protocol aims at providing applications with rates comparable to the medium speed and not a small portion (around 10 ) of it as it is now in the existing standard protocols [18]. Furthermore, owing to the simple error flow control scheme, HCP can cope and handle with mediums operating in Gigabit or even Terabit range; in existing standard protocols, at high transmission rates, the network interface processor should process an incoming packet within a very short time ....

[Article contains additional citation context not shown here]

G. Chesson, " The Protocol Engine Project," Proceedings of the Summer 1987 USENIX Conference, pp. 209-215, June 1987.

....packets used in opening, closing, and checking the virtual connection over which data is transmitted. 1.3. 7 Express Transfer Protocol Express Transfer Protocol (XTP) is a recent transport protocol being designed for implementation in a specialized VLSI architecture called the Protocol Engine (PE) [102] [112] XTP was designed in the late eighties as a high performance protocol to provide the necessary services for distributed systems such as remote procedure calls, rapid request response operations, multicasts, concurrent multiple processes, and transaction based file access in addition to ....

.... using VLSI and hardware not only at the switching level, but also at the protocol levels [142] 143] Recent research includes design of protocol engines or specialized VLSI architectures to perform protocol operations at very high speeds matching the speed of the fiber transmission media [102] [112] Also, there have been studies on design of programmable protocol engines operating at high speeds to be used by various protocol and networking applications [113] In order to provide ease for hardware support in protocol implementations, it is important to design protocols as ....

. G. L. Chesson. "The Protocol Engine Project". Unix Review 5, 9 (September 1987), 70-77.

....the application level transfer rates on existing local area networks remain much lower and it is doubtful that they can keep pace with medium speed. For example, out of the 10 Mbit sec available at the medium of an Ethernet network, only around 1. 2 Mbit sec bandwidth is available for applications [10]. Consequently, it has been established that current clusters of workstations have the aggregate computing power to provide an environment for high performance distributed computing, while high speed networks, capable of supporting these computing rates, are becoming a standard (e.g. ATM, SONET, ....

G. Chesson, " The Protocol Engine Project," Proceedings of the Summer 1987 USENIX Conference, pp. 209-215, June 1987.

....the application level transfer rates on existing local area networks remain much lower and it is doubtful that they can keep pace with medium speed. For example, out of the 10 Mbit sec available at the medium of an Ethernet network, only around 1. 2 Mbit sec bandwidth is available for applications [14]; it is therefore not enough to have a Gigabit data link if user applications could only use a small portion of that bandwidth. Consequently, it has been established that current clusters of workstations have the aggregate computing power to provide an environment for supercomputing, while high ....

G. Chesson, " The Protocol Engine Project," Proceedings of the Summer 1987 USENIX Conference, pp. 209-215, June 1987.

....the FDDI backbone network is 100 Mbits sec and the effective delay per packet (T effFDDI ) available at the application layer equal to 0.7 msecs [14] 3. The bandwidth of the ethernet LAN s is 10 Mbits sec and the effective delay per packet (T effLAN ) available at the application layer is 6. 6msec [15]. 4. An analytic approach is used to calculate the FRT s with the assumption that the system is an open system with M M 1 queues. All distributions are assumed to be exponential and all arrivals to be Poisson. 5. The arrival rate of tasks ( is 15 tasks hour user. Let N p kt(k) be the number of ....

Greg Chesson, The Protocol Engine Project, In Proceedings of the Summer 1987 USENIX Conference, pages 209--215, June 1987.

....A suitable transport protocol must provide reliable transport services to higher layers while attaining maximum bandwidth utilisation. 2. 1 Implementation Issues One of the major drawbacks identified in existing protocols is the extreme reliance on the host CPU to perform protocol processing [4,5]. This results in heavy usage of timers, interrupts and context switching, thus causing severe overheads at the host to support protocol processing. For a high speed network operating at 1Gb s, with a packet size of 1 Kbytes, a processing time of 8 microseconds for each packet is required. Given ....

....adapter board[7] Their analysis has shown that 6 of the delay in packet processing is due to network delay, 12 is due to processing on the network adapter board and 88 is due to host processing. Although it is possible to design dedicated hardware for a specific protocol, as demonstrated in XTP[5], the drawback is the difficulty in adapting to changing requirements. Another approach that meets cost constraints and yet remains adaptable to changing requirements is the application of parallel processing techniques using commercially available microprocessors such as transputers[4] A network ....

G. Chesson, "The Protocol Engine Project," Unix Review, Sept 1990.

....distributed computing environment could be built in cost effective manner as an alternative of supercomputing platform. However, in current local area networks, the bandwidths achievable at the application level are often an order of magnitude lower than that provided at the network medium [3, 7]. It is therefore not sufficient to have even a Gigabit data link if user applications could only use a small portion of that bandwidth. In this paper, we present a software and hardware support to transform a local area network of workstations into a high performance distributed computing ....

....supercomputing environments. The primary barrier is the limited communication bandwidth available at the application level. In current local area networks (LAN) the bandwidths achievable at the application level are often an order of magnitude lower than that provided at the network medium [3, 7]. For example, out of the physical bandwidth of 10 Mbit sec available at the medium level of the Ethernet, only about 1.2 Mbit sec is available to the application [3] it is therefore not sufficient to have even a Gigabit data link if user applications could only use a small portion of that ....

[Article contains additional citation context not shown here]

G. Chesson, " The Protocol Engine Project," Proceedings of the Summer 1987 USENIX Conference, pp. 209-215, November 1987.

.... it include the best ideas of existing standard and experimental protocols, that it include network layer routing capabilities, that the algorithms were designed for VLSI implementation, and that it provide clean, regular mechanisms for service without mandating a use or paradigm for that service ([CHES87]) The Xpress Transfer Protocol is the result of this effort. This project has garnered the interest and support of many industry and research institutions, as well as becoming the protocol of choice for the lightweight protocol stack in the Navy SAFENET project ( NOSC91] 4.1. XTP Design XTP ....

Chesson, G., "The Protocol Engine Project", UNIX Review, Vol. 5, No. 9, (September 1987).

.... it include the best ideas of existing standard and experimental protocols, that it include network layer routing capabilities, that the algorithms be designed for VLSI implementation, and that it provide clean, regular mechanisms for service without mandating a use or paradigm for that service [19]. The Xpress Transfer Protocol is the result of this effort. XTP provides mechanisms for communication upon which users may implement a wide variety of policies and paradigms. By offering a set of orthogonal mechanisms, the user is provided a functionally rich yet efficient matrix of data transfer ....

Chesson, G., "The Protocol Engine Project," UNIX Review, Vol. 5, No. 9, (September 1987).

....for ease of implementation in hardware to further speed up in protocol processing. The next approach is concerned with the implementation of protocols on an outboard hardware protocol processor platform. Such implementations can come in the form of dedicated VLSI hardware for a specific protocol [4] or using a general multiprocessor platform. The main advantage of a dedicated VLSI hardware solution is the high processing speed achievable and consequently higher throughput performance. However, this advantage is offset by the high cost and difficulty in adapting to changing requirements. On ....

G. Chesson, "The Protocol Engine Project," Unix Review, Sept 1990. 15

.... the second phase involves the actual transfer of the data, and the final phase involves synchronizing state (this may involve the receiver requesting retransmission of any packets it may not have been received) Transport protocols based on rate control include NETBLT [4] VMTP [2] and XTP [3]. These protocols are concerned with maintaining a high end to end throughput. In the case of audio conferencing the throughput requirements are quite modest (around 100Kbps) However, audio has the real time requirement of making the data available to the receiver before its playback time ....

G. Chesson, "The Protocol Engine Project," UNIX Review, Vol. 5, No. 9, Sept. 1987.

....with explicit connection setup. Ease of VLSI implementation is often ensured, thereby allowing additional performance gains by hardware implementation. 3 Light weight transport protocols are for example Delta t [Watson89] NETBLT [Clark88] RTP [Schulzrinne93] VMTP [Cheriton89] and XTP [Chesson87] 3 . Designing and optimizing new protocols naturally leads to performance improvements. However, since new protocols must still perform a set of well known functions, these improvements are limited and additional approaches are required. Adaptive Protocol Stacks A disadvantage of using a ....

.... Sparc10 Stack [R tsche93a] TCP IP, and ST II 2 Transputers plus VLSI (Analysis) Layer [Woodside93] OSI Transport and Session VME 68020 Multiprocessor Entity [Balraj92] Prompt Dedicated VLSI Entity [Blair93] OSI TP (95) Multi Transputer Entity [Braun92a] XTP, VMTP Multiple Transputer Entity [Chesson87] Schwaderer90] XTP Multiprocessor VLSI Entity [Diot91] TP4 Multiple Transputers VLSI Entity [Jain90] TP4 Analysis Entity [Kaiserswerth91] ISO 8802.2 2 (LLC 2) 4 Transputers with shared memory Entity [Kanakia88] VMTP Single processor and hardware Entity [Laouar92] ISO 8802.2 2 (LLC 2) 5 ....

[Article contains additional citation context not shown here]

Chesson, G. "The Protocol Engine Project," Unix Review, Vol.5 No.9, Sept. 1987, pp.70--77

No context found.

G. Chesson, "The Protocol Engine Project," Pr'oceedigs of the Summer 1937.

No context found.

G. Chesson, "The protocol engine project," Unix Rev., vol. 5, no. 9, pp. 70-77, Sept., 1987.

No context found.

CHES87b Chesson, G., "The Protocol Engine Project", Unix Review, September 1987.

No context found.

Chesson, G. [1987] The Protocol Engine Project. UNIX Review, Vol. 5, No. 9, Sept. 1987, pp.70-77.

No context found.

G. Chesson, " The Protocol Engine Project," Proceedings of the Summer 1987 USENIX Conference, pp. 209-215, June 1987.

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