Ideas for a Next Generation of the Reliable Server Pooling Framework

Introduction

Abbreviations

ASAP: Aggregate Server Access Protocol
ENRP: Endpoint Handlespace Redundancy Protocol
ID: Identifier
MPTCP: Multi-Path Transmission Control Protocol
PE: Pool Element
PR: Pool Registrar
PU: Pool User
RSerPool: Reliable Server Pooling
SCTP: Stream Control Transmission Protocol
TCP: Transmission Control Protocol
VNFPOOL: Virtual Network Function Resource Pooling

Reliable Server Pooling Reliable Server Pooling (RSerPool) is defined in , , , , , , , . There is also a detailed introduction provided in as well as further informational material at . RSerPool is therefore not introduced in more detail here.

Scope The scope of this document is to collect ideas on what to update/change for a next generation of the RSerPool framework. It is a result of lessons learned over roughly two decades of RSerPool deployment (see also , , ) as well as ongoing discussions on applying RSerPool for Virtual Network Function Resource Pooling (VNFPOOL; as introduced in more detail in ).

What to Change in the Next Generation of RSerPool?

ENRP servers denote the management systems in the context of RSerPool. The term "server" is misleading, since ENRP servers are actually ENRP peers. Literature on RSerPool -- for example -- therefore uses the more accurate term "Pool Registrar" (PR). A future revision of RSerPool should also use this term. (The RSerPool documents did not use "registrar" to avoid confusion with SIP registrars.)
Pool Element Identifiers (PE IDs) and Pool Registrar Identifiers (PR IDs) are 32-bit random numbers used for the identification of PEs and PRs. Since 64-bit CPUs have been standard for a long time, these IDs should be extended to 64 bits.
ENRP uses the Internet-16 checksum defined in to detect handlespace inconsistencies. It is trivially possible to extend the underlying algorithm to 32 bits, and the computation is more efficient on today's CPUs. The checksum algorithm should therefore be changed. (The Internet-16 checksum was finally chosen in 2005 after long decisions to avoid any possible patent issues. The trivial extension of Internet-16 to Internet-32 is likely no longer an issue.)
PR failures lead to a possible concentration of all PUs and PEs at a single PR. To achieve better load balancing, the solution ENRP Takeover Suggestion -- as defined in -- should be included in ENRP.
Upon handle resolution, a PR has to decide on how many PEs to select. Selecting too many entries causes additional overhead (which might be unnecessary), selecting too few may cause problems for applications. The extension Handle Resolution Option -- defined in -- allows the PU to specify the number of PEs to be selected. This possibility should be integrated into ASAP.
RSerPool defines SCTP (defined in ) as the transport protocol for RSerPool. TCP, Multi-Path TCP (MPTCP; see ), and QUIC (see ) should be supported as additional transport protocols for all RSerPool traffic. SCTP should still be the recommended choice, but allowing TCP/MPTCP could make deployment much easier. (SCTP is superior, but it lacks support in operating systems and underlying network infrastructure, such as firewalls and middleboxes.)

Security Considerations Security considerations for RSerPool can be found in .

IANA Considerations This document introduces no additional considerations for IANA.

Reference Implementation The RSerPool reference implementation RSPLIB, including example applications, can be found at . It supports the functionalities defined in , , , , 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 and . Further information can be found on the project website .

Acknowledgments The author would like to thank Randall R. Stewart, Michael Tüxen, and Ning Zong for their discussions and support.