E. Cooper, P. Steenkiste, R. Sansom, and B. Zill. Protocol implementation on the Nectar communication processor. ACM SIGCOMM Conference (Philadelphia, PA), September 1990.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....reconstruction within the selfsecuring NI software. Although this work is redundant with respect to the host s network stack, it allows self securing NIs to be deployed with no client software modification. For NIs that offload higher level protocols (e.g. IP security or TCP) from the host [11, 13], redundant work becomes unnecessary because the only instance of the work is already within the NI. Self securing NIs enforce policies set by the network administrator, just as a centralized firewall would. In fact, administrators will configure and manage self securing NIs over the network, ....

Eric Cooper, Peter Steenkiste, Robert Sansom, and Brian Zill. Protocol implementation on the Nectar communication processor. ACM SIGCOMM Conference (Philadelphia, PA), September 1990.

....This approach allows for implementation in hardware. This leaves the handling and recovery of erroneous packets to upper layers. 3. 2 Buffer Management As many researchers have pointed out, implementing protocols in hardware must be coupled with efficient buffer management located on the NIU [12, 13, 14]. Otherwise we will not get the high performance required for PACS. Additionally, avoiding copying from NIU to host memory will reduce the number of trips over the host bus. Thus, memory on the NIU should serve two purposes. First, as NIU buffer to do the conventional task of buffering message ....

E. C. Cooper, Peter A. Steenkiste, R. D. Sansom, B. D. Zill, "Protocol implementation on the Nectar communication processor," in SIGCOMM '90 Symposium on communications architectures and protocols, Philadelphia, P.A., Sept. 24-27, 1990.

....is to improve the spatial and temporal locality of protocol code. Another approach is to move transport protocol processing off the host and onto the network adapter. This is usually done by adding a dedicated microprocessor to the network adapter. The Nectar CAB (communication accelerator board) [17, 18] is an interface to a 100 Mbit second fiber optic network (called Nectar) that uses an on board 16.5 MHz SPARC processor and connects to a host via the VME bus. Unfortunately the on board processor is not fast enough to deal with small packets. When the packet size is 512 bytes, only 12 ....

E. Cooper, P. Steenkiste, R. Sansom and B. Zill, Protocol implementation on the Nectar Communication Processor, Proceedings of ACM SIGCOMM '90, September 1990.

.... have used page remapping and smart interface buffer allocation to accelerate processor tointerface communication, including the fbufs work at the University of Arizona [Druschel93] the Medusa FDDI interface [Lumley92, Banks93] and the follow on Afterburner project [Dalton93] The Nectar system [Cooper90] allowed applications direct access to its communication interface memory in order to eliminate copies at the cost of all accesses being to memory in the I O space. It achieved round trip RPC latencies of 500s across a 100Mb s network. ATM network interfaces can use virtual circuit identifiers ....

Eric Cooper, Peter Steenkiste, Robert Sansom, and Brian Zill. Protocol implementation on the Nectar communication processor. Proceedings of the ACM SIGCOMM`90 Symposium (Philadelphia, PA), September 1990.

....of a given protocol [Cla89] These techniques depend on the environment more than on the protocol itself. The proposed solutions focused on the enhancement of the protocol implementation performance in a given software or a hardware environment: outboard protocol processors (e.g. Kan88] [Coo90]) hardware protocol implementations (early work on XTP Protocol Engine [Che89] or parallel implementations of transport protocols [Bra92] Rut92] Lap92] Bjo93] A detailed survey of protocol implementation optimization techniques can be found in [Dab91] and [Fel93b] The performance of ....

E. C. Cooper, P. A. Steenkiste, R. A. Sansom, and B. D. Zill. "Protocol Implementation on the Nectar Communication Processor", In Proceedings ACM SIGCOMM '90, Philadelphia, PA, September 1990, pp. 135-144.

....interface memory could pose a serious resource problem. Memory hogs or bug ridden applications with memory leaks can easily deplete the interface memory available for use [15] A variant of this approach that uses a dedicated coprocessor for protocol processing is described by Cooper et al. [4]. 3.2.2 Kernel network shared memory To alleviate the resource problem described above, this scheme lets the operating system kernel manage the interface memory, and uses direct memory access (DMA) or program I O (PIO, i.e. CPU copy) to move data between interface memory and application ....

E. Cooper, P. Steenkiste, R. Sansom, and B. Zill. "Protocol Implementation on the Nectar Communication Processor," Proceedings of SIGCOMM `90 Conference on Comm. Architectures, Protocols and Applications, Aug. 1994.

....in particular Transmission Control Protocol Internet Protocol (TCP IP) do not form performance bottlenecks, provided that the protocols are properly implemented. The host system architecture, which provides the environment in which protocols are executed, is really the key performance factor [22]. For instance, it is essential for efficient implementation of a protocol to minimize the number of accesses to the host memory. In traditional host interface implementations for Ethernets, there can be as many as six accesses to or from the host memory for each word received from or transmitted ....

E. C. Cooper, P. A. Steenkiste, R. D. Sansom, and B. D. Zill. Protocol implementation on the nectar communication processor. In Proc. SIGCOMM `90 Symposium on Communications Architectures and Protocols, Philadelphia, Sep. 1990.

....Figure 1: Block diagram of a HARTS node. 5 device interface to the application processors which are responsible for executing higher level protocols. The Nectar system [5] uses a communications adapter board (CAB) which features a general purpose SPARC processor. The CAB software organization [11] is similar to our design and provides a high level interface to the host processors. However, these systems do not deal with the problem of real time communication. This paper is organized as follows. In Section 2 we describe the communication model that we use for time constrained ....

E. C. Cooper, P. A. Steenkiste, R. D. Ransom, and B. D. Zill, "Protocol implementation on the Nectar communication processor," in Proceedings of the SIGCOMM Symposium, pp. 135--144. ACM, September 1990.

.... nucleus of the transport system. However, protocol and session architecture components may actually reside inside the OS kernel (BSD UNIX [8] and System V UNIX [7] in user space (Mach [20] and the Conduit [9] in either location (e.g. the x kernel [2] or in off board processors (Nectar [21] and VMP [4] As shown by the shaded portions of Figure 2, this paper focuses on the protocol and kernel architectures. A thorough discussion of the application interface and session architecture levels is beyond the scope of this paper; they are included in Figure 2 for completeness and to ....

E. C. Cooper, P. A. Steenkiste, R. D. Sansom, and B. D. Zill, "Protocol Implementation on the Nectar Communication Processor," in SIGCOMM Symposium on Communications Architectures and Protocols, (Philadelphia, PA), pp. 135--144, ACM, Sept. 1990.

.... work done by the CPU and by peripheral processors moves in cycles over time; they referred to this as the wheel of reincarnation [MS68] Over the last decade, numerous hardware experiments were conducted and suggestions were made for putting more functionality into the network adapter [Kan88, CSSZ90, Che87, Sid91, DWB 93, Dav91, TS91, BJM 96, SWR91, BPP91, DPD91, TP96] Most of the more radical features have not been accepted into mainstream adapters. Some of these approaches have not been adopted into the mainstream because they are specific to Open Systems Interconnection (OSI) or ....

Eric C. Cooper, Peter A. Steenkiste, Robert D. Sansom, and Brian D. Zill. Protocol implementation on the Nectar communication processor. In Proc. SIGCOMM '90, pages 188--199. ACM, 1990.

....of previous and related work we slightly extend a classification in [6] 1. User Accessible Interface Memory: A scenario with minimal data transfer overhead is one in which the network interface memory is accessible and pre mapped into the user and kernel address space (variation described in [7]) This approach requires complicated hardware support and substantial software changes. 2. User Level Network Interface (U Net) or Virtual Interface Architecture (VIA) Another alternative is to choose a low level hardware abstraction for the network interfaces and leave the implementation of a ....

Eric Cooper, Peter Steenkiste, Robert Sansom, and Brian Zill. Protocol Implementation on the Nectar Communication Processor. In SIGCOMM90, pages 135--143, Philadelphia, September 1990. ACM.

.... et al. Cooper et al. developed the Nectar Communications Accelerator Board (CAB) a flexible communications architecture in which various transport and network layer protocols may execute off host on a general purpose RISC processor, supported by some proto 43 col independent custom hardware [11][43] This protocol processor is but one component in the Nectar project, which aims to construct a local area network that can function as a multiprocessor composed of workstation nodes. In this scenario, the designer s primary goal was to achieve low host to host message latency. The main ....

E. C. Cooper, P. A. Steenkiste, R. D. Sansom, and B. D. Zill, "Protocol Implementation on the Nectar Communication Processor," Proceedings, SIGCOMM `90, Philadelphia, PA, September 1990, pp. 135-144.

....Mode (ATM) has been suggested as an implementation technology for local as well as wide area networks [22] 6] ATM messages are of fixed length. Each is 53 bytes long with five bytes reserved for header, leaving a 48 byte payload. Several teams are creating prototype ATM host interfaces [11] 12][8]. The Autonet follow on, AN2, will have ATM switches [27] ATOMIC sends variable length packets and it uses the distributed computational and routing capability of a mesh. This sets ATOMIC well apart from ATM based LANs. The fragmentation and reassembly required when ATM carries higher layer ....

Cooper, E. C., Steenkiste, P. A., Sansom, R. D., Zill, B. D., "Protocol Implementation on the Nectar Communication Processor", SIGCOMM 90, ACM 1990, pp. 135-144.

....Moreover, such communication protocols usually operate at the user level and the scheduler does not give them high priority. These factors make it prudent to have the protocol running at a lower level. The lowest level at which a protocol can run is on a special purpose communication card [2, 3]. This, however, makes the protocol specific to that card. Another approach is to build a kernel microkernel in which the protocol runs [6, 7] The drawback of this approach is that a new kernel will have to be written. In both cases, the protocol ceases to be effectively portable. A third method ....

E. C. Cooper, P. A. Steenkiste, R. D. Sansom, and B. D. Zill. Protocol implementation on the Nectar communication processor. In ACM SIGCOMM Symposium on Communications Architectures and Protocols, pages 135--144, Philadelphia, PA, September 1990.

....generated as output of the compiler. The Nectar Communications Accelerator Board (CAB) 2] can be programmed with various protocols. The CAB communicates with the host memory directly, and the programmability can conceivably be used by applications to customize protocol processing. Cooper, et al. [8]. report that TCP IP and a number of Nectar specific protocols have been implemented on the CAB connected to Sun 4 processors. Another approach has been explored for ATM interfaces, which puts minimal functionality in interface hardware [7] The approach is characterized by the assignment of ....

Eric C. Cooper, Peter A. Steenkiste, Robert D. Sansom, and Brian D. Zill, "Protocol Implementation on the Nectar Communication Processor," in Proceeedings, SIGCOMM '90, Philadelphia, PA (September 24-27, 1990), pp. 135-144.

No context found.

Eric Cooper, Peter Steenkiste, Robert Sansom, and Brian Zill. Protocol Implementation on the Nectar Communication Processor. Proceedings of the SIGCOMM '90 Symposium on Communications Architectures and Protocols, ACM, Philadelphia, September, 1990, pp. 135-143.

....Figure 1: Nectar system overview The CAB includes a high performance CPU (a SPARC) memory, and specialized hardware such as timers and DMA controllers. The main function of the CAB is protocol processing for messages sent over the Nectar network but because the CAB runs a flexible runtime system [7], it can also execute higher level support for network computing and even the communication intensive parts of applications. Functions that might be placed on the CAB include monitoring, load balancing, and caching of shared data. Figure 2: Nectar runtime environment In the current environment, ....

Eric Cooper, Peter Steenkiste, Robert Sansom, and Brian Zill. Protocol Implementation on the Nectar Communication Processor. Proceedings of the SIGCOMM '90 Symposium on Communications Architectures and Protocols, ACM, Philadelphia, September, 1990, pp. 135-143.

.... sockets) the single copy architecture might require outboard buffering and checksum support [3] and several projects have proposed or implemented network adapters that include these features [4, 5, 6, 25] Alternatively, it is possible to eliminate copying by using APIs with other semantics [8, 9, 10, 11], or by using copy semantics in a restricted way [12] A detailed study of the impact of API semantics on data passing performance can be found in [13] Many applications use BSD sockets and the Internet protocols for communication, and as a result it is worthwhile to look at how they can be ....

....to eliminate the data access for checksumming. With a single copy stack based on outboard buffering, performance is less sensitive to the alignment and length of the application buffer, but more hardware support is needed. Finally, many groups have implemented APIs with share and move semantics [8, 9, 10, 11]. By changing the semantics of the API it is sometimes possible to achieve single copy communication without the need for outboard buffering. We are evaluating these techniques in the context of the Credit Net project [28, 13, 29] 8 Conclusion We described a network adapter architecture and ....

Eric Cooper, Peter Steenkiste, Robert Sansom, and Brian Zill. Protocol implementation on the nectar communication processor. In Proceedings of the SIGCOMM '90 Symposium on Communications Architectures and Protocols, pages 135--143, Philadelphia, September 1990. ACM.

....is no need to make a copy of the message (Figure 5) On receive, the application is given a pointer to the location of the data, so there is no requirement to copy the message to a specific location in the user s address space. Buffered primitives are used in a number of systems, including Nectar [2] and the Firefly [10] For protocols that store the checksum in the header, such at TCP, buffered sends will require a separate pass over the data to calculate the checksum, as shown in Figure 5. Although it is possible to calculate the checksum during the copy operation to the adaptor, it is not ....

....not reduce the number of bus transfers for applications that use buffered primitives, since the shared buffers already automatically provide retransmit and receive buffering. The exception is when the application is allowed to access the buffers on the adaptor directly, as is the case in Nectar [2]. The Nectar system supports outboard buffering and makes these buffers available through a shared buffer interface. This allows data to be sent and received with only a single transfer over the bus (Figure 12) which is the absolute minimum. However, this organization only performs well if ....

[Article contains additional citation context not shown here]

Eric Cooper, Peter Steenkiste, Robert Sansom, and Brian Zill. Protocol Implementation on the Nectar Communication Processor. Proceedings of the SIGCOMM '90 Symposium on Communications Architectures and Protocols, ACM, Philadelphia, September, 1990, pp. 135-143.

No context found.

E. Cooper, P. Steenkiste, R. Sansom, and B. Zill. Protocol implementation on the Nectar communication processor. ACM SIGCOMM Conference (Philadelphia, PA), September 1990.

No context found.

E. C. Cooper, P. A. Steenkiste, R. D. Sansom, and B. D. Zill, "Protocol implementation on the Nectar communication processor," Proceedings of ACM SIGCOMM '90,ACM, Philadelphia, PA, USA, 1990.

No context found.

[Coo90] Cooper E., Steenkiste P., Sansom R., and Zill B., Protocol implementation on Nectar communication processor. In ACM SIGCOMM'90 Symposium (September 1990).

No context found.

Cooper, E.C., Steenkiste, P. A., Sansom, R. D., and Zill, B.D., "Protocol Implementation on the Nectar Communication Processor" ACM SIGCOMM '90, Philadelphia, Pennsylvania, September 1990, pp. 135-144.

No context found.

Cooper E.C., Steenkiste P.A., Sansom R.D., Zill B.D. [1990] Protocol Implementation on the Nectar Communication Processor. In Proceedings of the ACM SIGCOMM '90 Symposium on Communications Architectures and Protocols, Philadephia, PA, September 24-27, 1990.

No context found.

E.C. Cooper, P.A. Steenkiste, R.D. Sansom and B.D. Zill. "Protocol Implementation on the Nectar Communication Processor." In Proceedings of the ACM SIGCOMM '90 Symposium on Communication Architectures and Protocols. 1994.

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