Transport protocol processing at GBPS rates

Abstract

approach and might prove difficult to adapt to This paper proposes an architecture for accomplishing transport protocol processing at Gbps rates. The limitations of currently used transport protocols have been analyzed extensively in recent literature. Several benchmark studies have established the achievable throughput of IS0 TP4 and TCP to be in the low Mbps range; several new protocols and implementation techniques have been proposed to achieve 100 Mbps and higher throughput rates. We briefly review some of these protocols and establish the need for a radically different approach to meet our objective.An estimate of the aggregate processing power required for Gbps throughput is developed. It is proposed that a cost effective and practical solution to the processing requirements could be based on a multi-processor system. The opportunities for parallel processing in a typical transport protocol are examined.Several alternate parallel processing approaches are examined and arguments are advanced for selecting a favored approach.A corresponding parallel processing architecture is described. Data structures used to preserve packet ordering and techniques for reducing contention in a multi-processing environment are discussed. An implementation methodology for conventional transport protocols (e.g. TP4) is outlined. Some suggestions are made for improving efficiency by making modifications to the protocol that do not compromise functionality. The performance achievable with thii modified architecture is analyzed and some suggestions for further work are presented. changing needs. The other approach is to take a fairly general multi-processing platform and customize it to the needs of a particular transport protocol. We shall establish that not only is the latter approach feasible, but is also achievable at a relatively modest cost. We assume that the protocol processing up to (and includiig) the transport level is performed in a dedicated frontend system that is connected to the host computer by a high-speed interface and that all higher level processing takes place in the host or other satellite systems.Several articles have appeared in recent literature dealing with applications of parallel processing to protocol impl.emcntation. An excellent analysis of the opportunities for parallel processing withii a protocol layer appears in [8]. The concept of division into horizontal and vertical sub-layers is discussed and illustrated with specific examples of application to TP4 and other protocols. In [9]. the authors discuss several possibilities for parallel processing within the transport layer. One of these is to view the protocol as a composition of state machines which can be implemented on distinct processors. In this paper, we describe a somewhat different approach based on processing packets in parallel which seems to offer more potential for speed-up.

Measuring the Impact of Alternative Parallel Process Architectures on Communication Subsystem Performance

“…This Module uses its read-side svc method to (1) transform network messages into the canonical internal message format that is processed by higher-level components in a Stream and (2) demultiplex incoming messages onto the appropriate transport layer connection. 4 Once a message has been demultiplexed onto a connection, all that connection's context information is directly accessible within the address space of the associated process. This is beneficial since (1) pointers to messages may be passed between protocol layers via simple procedure calls (rather than using more complicated and costly interprocess communication mechanisms used for Layer Parallelism process architecture), (2) cache affinity properties may be preserved since messages are processed largely within a single PE cache, and (3) minimal internal locking is required within a connection.…”

“…A number of process architectures have been proposed as the basis for parallelizing communication subsystems [1,2,3,4]. There are two fundamental types of process architectures: task-based and message-based.…”

ADAPTIVE: A dynamically assembled protocol transformation, integration and evaluation environment

“…Several different approaches have been proposed to map Task-based and Message-based process architectures onto multiple PEs [18,19,10,20,21]. Figures 1 and 2 illustrate four models of process architecture parallelism: Layer Parallelism and Task Parallelism are Task-based process architectures; Connectional Parallelism and Message Parallelism are Message-based process architectures.…”

“…Message-based Process Architectures: Message-based process architectures associate OS processes with messages and connections rather than with protocol layers or tasks [4,20].…”

A Reduced Operation Protocol Engine (ROPE) for a multiple-layer bypass architecture

“…The heavy processing load is due to a combination of operating system overhead, protocol complexity, and per-octet processing on the data stream. To alleviate the end-system bottleneck one may consider new protocols [10], improved software implementation of existing protocols [5,35], parallel processing techniques [14,21,38], special protocol structures [15,30] and hardware assist [22] by offloading all or part of the protocol functions to an adaptor. This paper takes the latter approach.…”