Ideas for a Next Generation of the Reliable Server Pooling Framework

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 (RSerPool) has been defined as RFCs in , , , , , , , . There is also a detailed introduction provided by as well as lots of further information material on . RSerPool is therefore not introduced in more detail here.

The scope of this document is to collect some ideas of what to update/change for a next generation of the RSerPool framework. It is a result of lessons learned with more than one decade 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 ).

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 ID) and Pool Registrar Identifiers (PR ID) are 32-bit random numbers used for the identification of PEs and PRs. Since 64-bit CPUs are standard since quite 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 probably not an issue any more?) PR failures lead to possible concentration of all PUs and PEs at a single PR. To achieve a better load balancing, the solution ENRP Takeover Suggestion -- as defined in -- should be included in ENRP. For a Handle Resolution, a PR has to decide on how many PEs to select. Selecting too many ones causes additional overhead (which might be unnecessary), selecting too few ones may cause problems for the applications. The extension Handle Resolution Option -- defined in -- provides a possibility for the PU to specify the amount of PEs to be selected. This possibility should be integrated into ASAP. RSerPool defines SCTP (defined in ) as transport protocol for RSerPool. TCP and particularly Multi-Path TCP (MPTCP; see ) should be possible further transport protocols for all RSerPool traffic. SCTP should still be the recommended choice, but allowing TCP/MPTCP could make the deployment much easier. (SCTP is superior, but it lacks of support in operating systems and support by underlying network infrastructure, like firewalls and middleboxes.)

Security considerations for RSerPool can be found in .

This document introduces no additional considerations for IANA.

The RSerPool reference implementation RSPLIB, including example 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 .

NorNet is a large-scale and realistic Internet testbed platform with support for Reliable Server Pooling as well as the underlying transport protocols SCTP and MPTCP. A description of and introduction to NorNet is provided in , , . Further information can be found on the project website .

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