]> Simula Metropolitan Centre for Digital Engineering

Stensberggata 27 0170 Oslo Norway dreibh@simula.no https://www.simula.no/people/dreibh

Internet-Draft This document describes the applicability of the Reliable Server Pooling architecture to manage real-time distributed computing pools and access the resources of such pools.

Introduction Reliable Server Pooling defines protocols for providing highly available services. The services are located in a pool of redundant servers and if a server fails, another server will take over. The only requirement put on these servers belonging to the pool is that if state is maintained by the server, this state must be transferred to the other server taking over. The goal is to provide server-based redundancy. Transport and network level redundancy are handled by the transport and network layer protocols. The application may choose to distribute its traffic over the servers of the pool conforming to a certain policy.

Scope The scope of this document is to explain the way of using Reliable Server Pooling mechanisms to manage and access pools of Distributed Computing resources.

Terminology The terms are commonly identified in related work and can be found in the Aggregate Server Access Protocol and Endpoint Handlespace Redundancy Protocol Common Parameters document .

Distributed Computing using RSerPool

Requirements The application scenario for Distributed Computing is defined as follows:

• Clients generate large computation jobs. Jobs have to be processed by servers as soon as possible (real-time), i.e. unlike concepts like SETI@home , it is not possible to let clients fetch a job, process it later and may be some day upload the result.
• Jobs may be partitionable, i.e. they can be split up to smaller pieces which can be processed independently and the processing results can be concatenated to the processing result of the complete job. Jobs have to be processed by servers.
• Servers may be unreliable; i.e. user computers may be temporarily added to the pool of computing resources and may be revoked when they are used again by their owners. Furthermore, they may simply disappear because of broken network connections (modems, etc.) or power turned off.
• The processing power of servers in a pool of computing resources may be very heterogeneous, i.e. a few supercomputers and many low-end user PCs.

Maintaining a Distributed Computing pool for the scenario described above arises the following requirements to the pool management:

• It must be possible to manage large server pools, e.g. up to some hundreds or even thousands of servers.
• Due to heterogeneous processing resources within a pool, it must be possible to use appropriate server selection procedures to meaningfully utilize the available resources.
• It must be possible to dynamically add and remove servers.
• Servers may be unreliable, especially when the servers are represented by user PCs. Failover mechanisms are required to continue an interrupted computation session.

Architecture All requirements for pool and session management of the Distributed Computing scenario defined in the previous section can be fulfilled by the Reliable Server Pooling architecture:

• An efficient implementation of the handlespace management structures allows pools to contain thousands of elements. Handlespace management structures have been proposed, implemented and analyzed in , .
• RSerPool allows to specify server selection rules by pool member selection policies . A set of adaptive and non-adaptive policies is already defined. To fulfill the requirements of new applications, it is also possible to define new policies. Research has already been made on the subject of load distribution efficiency of pool policies in Distributed Computing scenarios: see , , , , for details.
• Dynamic addition and removal of PEs is a feature of RSerPool .
• The control/data channel concept of RSerPool realizes a session layer. That is, RSerPool already handles the main task of maintaining and monitoring connections between PUs and PEs; the only task of the application layer to provide full failover functionality is to realize an application-dependent failover procedure. By the usage of client-based state synchronization , in the form of ASAP Cookies, a failover may be fully transparent to the PU while only a state restoration is necessary on the PE side. A demo application using the RSerPool session layer in a Distributed Computing application is described in .

Limitations Applying RSerPool for distributed computing applications, the duties of the RSerPool architecture are still limited to the management of pools and independent sessions only. It is in particular a non-goal to provide functionalities like data synchronization among sessions, user authentication, accounting or the support for more than one administrative domain. Such functionalities are considered to be application-specific and are therefore out of the scope of RSerPool.

Reference Implementation The RSerPool reference implementation RSPLIB, including example Distributed Computing applications, can be found at . It supports the functionalities defined by , , , and as well as the options , and . An introduction to this implementation is provided in .

Testbed Platform A large-scale and realistic Internet testbed platform with support for the multi-homing feature of the underlying SCTP protocol is NorNet. A description of NorNet is provided in , some further information can be found on the project website .

Security Considerations The protocols used in the Reliable Server Pooling architecture only try to increase the availability of the servers in the network. RSerPool protocols do not contain any protocol mechanisms which are directly related to user message authentication, integrity and confidentiality functions. For such features, it depends on the IPSEC protocols or on Transport Layer Security (TLS) protocols for its own security and on the architecture and/or security features of its user protocols. The RSerPool architecture allows the use of different transport protocols for its application and control data exchange. These transport protocols may have mechanisms for reducing the risk of blind denial-of-service attacks and/or masquerade attacks. If such measures are required by the applications, then it is advised to check the SCTP (see ) applicability statement for guidance on this issue.

IANA Considerations This document introduces no additional considerations for IANA.

References Normative References This document describes the applicability of the Stream Control Transmission Protocol (SCTP). It also contrasts SCTP with the two dominant transport protocols, User Datagram Protocol (UDP) & Transmission Control Protocol (TCP), and gives some guidelines for when best to use SCTP and when not best to use SCTP. This memo provides information for the Internet community. This document obsoletes RFC 2960 and RFC 3309. It describes the Stream Control Transmission Protocol (SCTP). SCTP is designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks, but is capable of broader applications. SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users: -- acknowledged error-free non-duplicated transfer of user data, -- data fragmentation to conform to discovered path MTU size, -- sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages, -- optional bundling of multiple user messages into a single SCTP packet, and -- network-level fault tolerance through supporting of multi-homing at either or both ends of an association. The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. [STANDARDS-TRACK] The Reliable Server Pooling effort (abbreviated "RSerPool") provides an application-independent set of services and protocols for building fault-tolerant and highly available client/server applications. This document provides an overview of the protocols and mechanisms in the Reliable Server Pooling suite. This memo provides information for the Internet community. Aggregate Server Access Protocol (ASAP; RFC 5352), in conjunction with the Endpoint Handlespace Redundancy Protocol (ENRP; RFC 5353), provides a high-availability data transfer mechanism over IP networks. ASAP uses a handle-based addressing model that isolates a logical communication endpoint from its IP address(es), thus effectively eliminating the binding between the communication endpoint and its physical IP address(es), which normally constitutes a single point of failure. In addition, ASAP defines each logical communication destination as a pool, providing full transparent support for server pooling and load sharing. It also allows dynamic system scalability -- members of a server pool can be added or removed at any time without interrupting the service. ASAP is designed to take full advantage of the network level redundancy provided by the Stream Transmission Control Protocol (SCTP; RFC 4960). Each transport protocol, other than SCTP, MUST have an accompanying transport mapping document. It should be noted that ASAP messages passed between Pool Elements (PEs) and ENRP servers MUST use the SCTP transport protocol. The high-availability server pooling is gained by combining two protocols, namely ASAP and ENRP, in which ASAP provides the user interface for Pool Handle to address translation, load sharing management, and fault management, while ENRP defines the high- availability Pool Handle translation service. This memo defines an Experimental Protocol for the Internet community. The Endpoint Handlespace Redundancy Protocol (ENRP) is designed to work in conjunction with the Aggregate Server Access Protocol (ASAP) to accomplish the functionality of the Reliable Server Pooling (RSerPool) requirements and architecture. Within the operational scope of RSerPool, ENRP defines the procedures and message formats of a distributed, fault-tolerant registry service for storing, bookkeeping, retrieving, and distributing pool operation and membership information. This memo defines an Experimental Protocol for the Internet community. This document details the parameters of the Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) defined within the Reliable Server Pooling (RSerPool) architecture. This memo defines an Experimental Protocol for the Internet community. Reliable Server Pooling (RSerPool) is an architecture and set of protocols for the management and access to server pools supporting highly reliable applications and for client access mechanisms to a server pool. This document describes security threats to the RSerPool architecture and presents requirements for security to thwart these threats. This memo provides information for the Internet community. This document describes server pool policies for Reliable Server Pooling (RSerPool) including considerations for implementing them at Endpoint Handlespace Redundancy Protocol (ENRP) servers and pool users. This memo defines an Experimental Protocol for the Internet community. SimulaMet This document describes the Handle Resolution option for the ASAP protocol. SimulaMet Hainan University This document contains the definition of a delay measurement infrastructure and a delay-sensitive Least-Used policy for Reliable Server Pooling. SimulaMet Hainan University This document describes the Takeover Suggestion Flag for the ENRP_HANDLE_UPDATE message of the ENRP protocol. Informative References