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.¶
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF). Note that other groups may also distribute working
documents as Internet-Drafts. The list of current Internet-Drafts is
at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 20 March 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.¶
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.¶
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.¶
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 [5].¶
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 [23], it is not possible to
let clients fetch a job, process it later and maybe someday upload the
result.¶
Jobs may be partitionable, i.e., they can be split up into smaller
pieces which can be processed independently and the processing results
can be concatenated with 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
raises the following requirements for 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.¶
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
[16], [12].¶
RSerPool allows specifying server selection rules by pool member
selection policies [7]. 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 conducted on the subject of load distribution
efficiency of pool policies in Distributed Computing scenarios: see
[12], [15],
[19], [20],
[14], [13] for details.¶
Dynamic addition and removal of PEs is a feature of RSerPool
[3].¶
The control/data channel concept [2] 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 using client-based state synchronization [15],
[18] 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 [24]
using the RSerPool session layer in a Distributed Computing application
is described in [17].¶
When applying RSerPool to distributed computing applications, the duties
of the RSerPool architecture remain 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.¶
The RSerPool reference implementation RSPLIB, including example
Distributed Computing applications, can be found at
[24]. It supports the functionalities
defined by [2], [3],
[4], [5] and
[6] as well as the options
[8],
[10] and
[9]. An introduction to this
implementation is provided in [12].¶
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 [22]
and [21]. Further information can be found on
the project website [25].¶
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 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
[1]) applicability statement
[11] for guidance on this issue.¶
Stewart, R., Tüxen, M., and K. Nielsen, "Stream Control Transmission Protocol", RFC 9260, DOI 10.17487/RFC9260, , <https://www.rfc-editor.org/info/rfc9260>.
[2]
Lei, P., Ong, L., Tuexen, M., and T. Dreibholz, "An Overview of Reliable Server Pooling Protocols", RFC 5351, DOI 10.17487/RFC5351, , <https://www.rfc-editor.org/info/rfc5351>.
[3]
Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate Server Access Protocol (ASAP)", RFC 5352, DOI 10.17487/RFC5352, , <https://www.rfc-editor.org/info/rfc5352>.
[4]
Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. Silverton, "Endpoint Handlespace Redundancy Protocol (ENRP)", RFC 5353, DOI 10.17487/RFC5353, , <https://www.rfc-editor.org/info/rfc5353>.
[5]
Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters", RFC 5354, DOI 10.17487/RFC5354, , <https://www.rfc-editor.org/info/rfc5354>.
[6]
Stillman, M., Ed., Gopal, R., Guttman, E., Sengodan, S., and M. Holdrege, "Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats", RFC 5355, DOI 10.17487/RFC5355, , <https://www.rfc-editor.org/info/rfc5355>.
Dreibholz, T. and X. Zhou, "Definition of a Delay Measurement Infrastructure and Delay-Sensitive Least-Used Policy for Reliable Server Pooling", Work in Progress, Internet-Draft, draft-dreibholz-rserpool-delay-37, , <https://datatracker.ietf.org/doc/html/draft-dreibholz-rserpool-delay-37>.