Internet-Draft PSHMP Core August 2026
Kolomytsev Expires 3 March 2027 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-kolomytsev-pshmp-core-00
Published:
Intended Status:
Informational
Expires:
Author:
A. Kolomytsev
Independent Researcher

PSHMP Core: Decentralized L4 Overlay for Resilient Data Delivery and Proactive Self-Healing Networks

Abstract

PSHMP Core is a decentralized data delivery and proactive self-healing network core designed for distributed systems operating over existing IP infrastructure. PSHMP Core provides an intelligent network layer above the existing IP network and enables distributed nodes to participate in dynamic multi-hop data delivery without requiring changes to the underlying Layer 3 routing infrastructure.

The architecture is designed around decentralized path selection, continuous node and path assessment, dynamic relay chains, proactive recovery, and diversity-aware reconstruction of delivery paths. The system can detect degradation of network participants and reconstruct affected delivery paths before or during service degradation. This approach is intended to reduce recovery time, improve resilience, and maintain reliable data delivery in environments where individual nodes, paths, or network segments may become unstable.

This document provides a high-level architectural overview of PSHMP Core, its primary components, operating principles, and potential application areas. This document intentionally does not disclose implementation-specific algorithms, internal scoring details, proprietary optimization techniques, or other information that may be required for commercial implementation.

Status of This Memo

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 3 March 2027.

▲

Table of Contents

1. Introduction

Modern distributed systems increasingly depend on network connectivity between geographically distributed nodes. Cloud infrastructure, edge computing, distributed databases, telecommunications systems, real-time applications, autonomous systems, and other network-intensive platforms may operate across networks where connectivity characteristics are not constant. Packet loss, latency variation, jitter, node failures, overloaded links, local network disruptions, and partial connectivity can significantly affect the reliability of distributed applications. Traditional network recovery mechanisms generally operate within the boundaries of the underlying network infrastructure. PSHMP Core approaches the problem from a different architectural layer. Instead of replacing the existing IP infrastructure, PSHMP Core introduces an overlay network layer capable of:

The primary objective is to provide a resilient network foundation for distributed systems rather than a standalone end-user networking product.

2. Scope

PSHMP Core is intended as a technology foundation that can be integrated into larger distributed platforms. Potential application areas include:

PSHMP Core is not intended to replace the Internet Protocol or conventional IP routing. Instead, it operates above the existing IP infrastructure and provides additional mechanisms for resilient data delivery between participating nodes.

3. Architectural Position

PSHMP Core operates as an overlay network layer above existing IP connectivity. A simplified architecture can be represented as:

+------------------------------------------------------+
|                  Distributed Application             |
+------------------------------------------------------+
|                     PSHMP Core                       |
|                                                      |
|  Path Selection | Chain Relay | Self-Healing        |
|  Node Evaluation | Diversity | Failure Tracking     |
+------------------------------------------------------+
|                    Existing IP Network               |
+------------------------------------------------------+
|              Physical / Virtual Infrastructure       |
+------------------------------------------------------+
Figure 1

Figure 1: PSHMP Core Architectural Position

The underlying IP network remains responsible for basic connectivity. PSHMP Core uses this connectivity as a substrate for establishing logical delivery paths between participating nodes. This separation allows PSHMP Core to be introduced without requiring fundamental changes to existing Layer 3 routing.

4. L4-Oriented Data Delivery

PSHMP Core is designed as an intelligent network layer operating at the transport-oriented level of the architecture. The system does not require modification of the underlying Layer 3 routing domain in order to construct its logical delivery paths. This allows a PSHMP-enabled system to operate over different IP environments while maintaining its own logic for:

The resulting architecture can be described as: Application

|
v
Figure 2

PSHMP Core

|
Figure 3

| Dynamic logical delivery path

|
v
Figure 4

Existing IP Infrastructure

|
v
Figure 5

Network / Internet This model is particularly relevant for distributed systems where the application requires additional resilience beyond what can be provided by a single conventional network path.

5. Decentralized Data Delivery

A fundamental characteristic of PSHMP Core is decentralized participation in data delivery. A conventional architecture may rely on a relatively fixed path: Source -> Gateway -> Server -> Destination A PSHMP-based architecture can construct a logical multi-hop delivery path: Source

|
v
Figure 6

Relay A

|
v
Figure 7

Relay B

|
v
Figure 8

Relay C

|
v
Figure 9

Destination The participating nodes can be selected dynamically according to current network conditions. The objective is not simply to create additional hops. The objective is to create a delivery path that can adapt when the quality or availability of individual participants changes. This enables the network to treat participating nodes as a distributed pool of potential relay resources.

6. Dynamic Chain Relay

PSHMP Core uses dynamic relay chains to construct logical multi-hop delivery paths. A relay chain consists of a sequence of participating nodes through which data can be delivered. The chain can be reconstructed when:

The system can therefore move from: Source -> A -> B -> C -> Destination to: Source -> A -> D -> E -> Destination without requiring the underlying IP routing infrastructure to be redesigned. The exact path construction and optimization algorithms are implementation-specific.

7. Node and Path Evaluation

Reliable dynamic routing requires continuous information about the condition of participating nodes. PSHMP Core includes a node evaluation mechanism based on multiple network and node characteristics. The evaluation can take into account parameters such as:

The resulting assessment can be used by the routing subsystem when selecting candidates for delivery paths. The purpose is to avoid treating all available nodes as equivalent. A node that is technically reachable but currently experiencing significant degradation can therefore be considered less suitable for a delivery path than a stable alternative.

8. Node Quality Metric (K-Factor)

PSHMP Core uses a composite quality metric (referred to as K-Factor) for evaluating the condition of participating nodes. The K-Factor is an aggregate evaluation rather than a single network measurement. Conceptually:

Node condition

|
*-- Packet loss
*-- Latency
*-- Jitter
*-- Availability
*-- Failure history
|
v
Figure 10

K-Factor

|
v
Figure 11

Routing decision

The K-Factor can be used to distinguish between:

The exact weighting, thresholds, and internal evaluation logic are implementation-specific and are not defined by this document.

9. Proactive Self-Healing

A central design principle of PSHMP Core is proactive recovery. Traditional recovery often follows this sequence: Failure

|
v
Figure 12

Detection

|
v
Figure 13

Decision

|
v
Figure 14

Route reconstruction

|
v
Figure 15

Recovery PSHMP Core attempts to reduce the impact of this sequence by continuously monitoring network conditions and preparing alternative delivery paths when degradation becomes apparent. The conceptual model is: Degradation detected

|
v
Figure 16

Condition evaluated

|
v
Figure 17

Alternative path selected

|
v
Figure 18

Delivery chain reconstructed

|
v
Figure 19

Traffic continues This allows the system to react not only to complete node failures but also to progressive degradation. In the current implementation, internal testing has demonstrated recovery behavior in the approximate hundreds-of-milliseconds range under the tested scenarios. Specific recovery time depends on network topology, node count, network conditions, configuration, and workload.

10. Local Mesh Recovery

PSHMP Core includes a local mesh recovery mode designed for situations where multiple nodes within the same relay chain degrade simultaneously. The mechanism can activate locally for an affected chain instead of forcing a complete reconstruction of the surrounding network. The local mesh mode can:

Conceptually: Original chain: A -> B -> C -> D -> E -> F B C D

|   |   |
+---+---+
Figure 20

degraded Local recovery: A -> G -> H -> I -> E -> F G H I

|     |     |
Figure 21

different failure domains The purpose of diversity-aware selection is to reduce the probability that multiple relays in the newly constructed chain are affected by the same local failure condition. The internal candidate scoring and selection mechanisms are implementation-specific.

11. Diversity-Aware Recovery

Network failures are not always independent. Several nodes may become unavailable because they share:

For this reason, simply selecting the highest-scoring available nodes may not provide sufficient resilience. PSHMP Core can apply diversity constraints during recovery. A simplified representation is: Group A Group B Group C A1 B1 C1 A2 B2 C2 A3 B3 C3

\       |       /
 \      |      /
  \     |     /
Figure 22

New Chain The objective is to reduce concentration of relay nodes within a single potential failure domain.

12. Failure Tracking

PSHMP Core maintains information about recent node failures and degradation events. Repeatedly unstable nodes that are immediately reused can cause persistent recovery failures. Failure tracking reduces this risk by temporarily excluding recently failed nodes from new path construction. Failure tracking can be used to:

A quarantine mechanism can temporarily prevent a recently failed node from immediately becoming part of a newly reconstructed path. The precise timing and failure scoring policies are implementation- specific.

13. Distributed Network State

A decentralized network requires mechanisms for distributing information about participating nodes and network conditions. PSHMP Core incorporates decentralized state-distribution mechanisms including Gossip and DHT-oriented components. At a high level: Node A / \ / \ Node B ---- Node C

|             |
|             |
Figure 23

Node D ---- Node E Information about node availability and network state can propagate between participating nodes without requiring every decision to depend on a single centralized component. DHT-based candidate discovery can provide additional mechanisms for locating suitable relay candidates.

14. Gossip-Based Information Exchange

Gossip-based information exchange can be used to distribute network state between participating nodes. The general model is: Node A

|
+----> Node B
|        |
Figure 24

| +----> Node D

|
+----> Node C
         |
         +----> Node E
Figure 25

This allows information to propagate through the network without requiring a single central distribution point. Gossip can complement other discovery and coordination mechanisms within PSHMP Core.

15. DHT-Based Candidate Discovery

PSHMP Core includes DHT-oriented mechanisms for discovering potential relay candidates. The DHT layer can provide candidate information to the chain construction subsystem. Candidate selection can consider:

The DHT layer is therefore used as a candidate discovery mechanism rather than simply as a generic distributed key-value store.

16. Failure-Domain Awareness

PSHMP Core can associate participating nodes with logical groups. A group may represent a potential failure domain such as:

During ordinary routing, group diversity may not be required. During recovery, however, the system can increase the importance of selecting nodes from different groups. This allows the routing system to adapt its selection policy according to the severity of network degradation.

17. Adaptive Recovery Policies

PSHMP Core does not require a single fixed recovery policy for all network conditions. Different network conditions may require different levels of routing constraints. The recovery subsystem can therefore operate using a fallback sequence. Conceptually: Strict recovery policy

|
v
Figure 26

Relaxed quality requirements

|
v
Figure 27

Relaxed diversity requirements

|
v
Figure 28

Emergency recovery The objective is to preserve connectivity whenever possible while maintaining quality constraints whenever sufficient resources are available. This approach allows the system to distinguish between:

18. Batch Acknowledgement and Gap Recovery

PSHMP Core includes mechanisms designed to reduce control traffic associated with data delivery. Instead of requiring an individual acknowledgement for every transmitted unit, the receiver can report delivery state in batches and identify missing ranges. A conceptual representation is: Received: 1 2 3 4 5 7 8 9 10 Gap: 6 The receiver can communicate the missing sequence information as a gap rather than generating a separate acknowledgement exchange for every unit. This approach can reduce protocol overhead in environments where control traffic represents a significant portion of total network traffic. Internal testing has demonstrated control-traffic reductions of up to approximately 75% under specific tested conditions. Actual savings depend on traffic patterns, loss rates, packet sizes, and configuration.

19. Transport and Connectivity

PSHMP Core is designed to operate over existing IP connectivity. The implementation includes support for transport and connectivity mechanisms suitable for distributed environments. Depending on deployment requirements, the system can integrate with:

The purpose of these mechanisms is to provide transport flexibility while preserving the higher-level PSHMP routing and recovery model.

20. Security Considerations

A decentralized network architecture must account for malicious or unstable participants. PSHMP Core includes mechanisms intended to mitigate several classes of network abuse. These mechanisms include:

PSHMP Core is not intended to replace conventional cryptographic security mechanisms. Deployments should use authentication, encryption, and identity management appropriate to their environment. The exact security model depends on the deployment architecture and trust model. PSHMP Core should not be considered a complete security system by itself. Applications integrating PSHMP Core should implement additional authentication, authorization, identity management, and operational security controls appropriate to their environment.

21. Scalability

PSHMP Core is designed with distributed deployment in mind. The architecture includes components intended to support larger node populations through:

The current implementation has been tested using network simulations involving thousands of nodes. Internal testing has included configurations exceeding 5,000 simulated or emulated nodes. Performance and scalability characteristics depend heavily on topology, workload, network conditions, and implementation configuration. The numbers described in this document should therefore be interpreted as implementation test results rather than protocol guarantees.

22. Current Implementation

PSHMP Core is currently implemented in Go. The current implementation includes approximately:

The implementation is currently positioned as a Pilot-Ready MVP and technology foundation rather than a finished mass-market product.

23. Implementation Architecture

A simplified implementation view is:

       +----------------------+
       |   Application Layer  |
       +----------+-----------+
                  |
                  v
       +----------------------+
       |      PSHMP Core      |
       |                      |
       |  Chain Relay         |
       |  Path Selection      |
       |  Self-Healing        |
       |  K-Factor            |
       |  Local Mesh          |
       +----------+-----------+
                  |
+-----------------+-----------------+
|                 |                 |
Figure 29

v v v

+---------+       +---------+       +---------+
|   DHT   |       | Gossip  |       | Failure |
| Discovery|      |  State  |       | Tracker |
+---------+       +---------+       +---------+
     |                 |                 |
     +-----------------+-----------------+
                       |
                       v
            +----------------------+
            | Existing IP Network  |
            +----------------------+
Figure 30

This diagram represents the conceptual architecture only. Implementation details and internal module interfaces are intentionally omitted.

24. Example Operational Scenario

Consider a distributed system using six relay nodes: Source

|
v
Figure 31

Relay A

|
v
Figure 32

Relay B

|
v
Figure 33

Relay C

|
v
Figure 34

Relay D

|
v
Figure 35

Relay E

|
v
Figure 36

Destination Suppose Relay B, Relay C, and Relay D begin experiencing degradation. The PSHMP Core can detect the degradation through node and path evaluation. Instead of continuing to use the affected chain indefinitely, the recovery subsystem can:

The resulting path may become: Source

|
v
Figure 37

Relay A

|
v
Figure 38

Relay F

|
v
Figure 39

Relay G

|
v
Figure 40

Relay H

|
v
Figure 41

Relay E

|
v
Figure 42

Destination The underlying IP network remains unchanged. Only the logical delivery path maintained by PSHMP Core changes.

25. Performance Characteristics

Internal testing of the current implementation has produced the following representative results:

+----------------------------+----------------------------------+
| Characteristic             | Observed result                  |
+----------------------------+----------------------------------+
| Tested node population     | 5,000+ nodes                     |
| Packet loss scenario       | up to 25%                        |
| Delivery in tested scenario| 100%                             |
| Recovery behavior          | hundreds of milliseconds range   |
| Control-traffic reduction  | up to 75%                        |
| Local mesh recovery        | implemented                      |
| Diversity-aware recovery   | implemented                      |
| DHT candidate discovery    | implemented                      |
| Failure tracking           | implemented                      |
+----------------------------+----------------------------------+
Figure 43

These values represent internal implementation testing. They are not protocol-level guarantees and should not be interpreted as universal performance benchmarks. Independent validation under production network conditions is required before making deployment-specific performance claims.

26. Potential Benefits

Integration of PSHMP Core into a distributed platform can provide several potential operational benefits.

26.1. Reduced Recovery Time

Proactive path reconstruction can reduce the period during which degraded nodes affect data delivery.

26.2. Improved Network Resilience

Dynamic multi-hop paths provide additional options when individual nodes or network segments become unavailable.

26.3. Reduced Dependence on Individual Components

Decentralized candidate discovery and dynamic relay selection can reduce dependence on fixed network paths or individual infrastructure components.

26.4. More Efficient Control Traffic

Batch acknowledgement and gap-based reporting can reduce protocol overhead in appropriate traffic scenarios.

26.5. Infrastructure Reuse

Because PSHMP Core operates over existing IP connectivity, it can potentially be integrated without replacing the underlying network infrastructure.

26.6. Adaptive Recovery

Local mesh recovery and fallback policies allow the system to adapt its behavior to the severity of network degradation.

27. Integration Model

PSHMP Core is intended to be integrated into an existing distributed platform rather than deployed as an isolated consumer application. A potential integration model is: Existing Platform

|
+----------------------+
|                      |
Figure 44

v v Application Logic PSHMP Core

|
v
Figure 45

Existing Network The integrating company can retain ownership of:

PSHMP Core provides the underlying network resilience layer.

28. Deployment Considerations

A production deployment should evaluate:

PSHMP Core should be evaluated through controlled pilot deployments before production-wide adoption.

29. Monitoring and Observability

The current implementation includes operational observability mechanisms. Relevant metrics can include:

Prometheus-compatible metrics are supported by the current implementation. Example conceptual events: [MESH] enabled [MESH] rebuild [MESH] disabled The exact logging and metric schema is implementation-specific.

30. Interoperability

PSHMP Core is designed to operate over conventional IP networks. Its overlay-oriented architecture allows it to coexist with existing:

The system does not require the underlying network to implement PSHMP-specific Layer 3 routing.

31. Design Principles

The architecture is based on several principles.

31.1. Decentralization

Network state and candidate discovery should not depend exclusively on a single centralized component.

31.2. Proactive Recovery

Network degradation should be treated as a signal for recovery rather than waiting exclusively for complete failure.

31.3. Dynamic Paths

Delivery paths should adapt to changing network conditions.

31.4. Diversity

Recovery should consider potential shared failure domains rather than only individual node quality.

31.5. Layer Independence

The overlay should operate above existing IP infrastructure without requiring changes to the underlying routing domain.

31.6. Graceful Degradation

When ideal candidates are unavailable, the system should progressively relax recovery constraints while attempting to preserve connectivity.

32. Limitations

PSHMP Core does not eliminate all network failures. The system cannot guarantee connectivity when insufficient network resources are available or when the underlying network becomes completely disconnected. Performance depends on:

The recovery times and traffic reductions presented in this document are based on internal testing and should be independently validated for production environments.

33. Security and Trust Model

A deployment must define how participating nodes are authenticated and trusted. Possible deployment models include:

For untrusted environments, additional mechanisms may be required for:

The current document does not define a universal trust model.

34. IANA Considerations

This document has no IANA actions.

35. Terminology

The following terms are used throughout this document. PSHMP Core The network core described by this document. Overlay A logical network operating over an existing underlying network. Relay A participating node that forwards data between other nodes. Relay Chain A dynamically constructed sequence of relay nodes used for data delivery. K-Factor An aggregate composite metric representing node quality and stability. Self-Healing Automatic reconstruction or replacement of degraded delivery paths. Local Mesh A recovery mode operating on an affected relay chain using alternative relay candidates. Diversity Selection of nodes from different logical groups or potential failure domains. Failure Tracker A subsystem maintaining information about recent node failures and degradation. DHT A distributed mechanism for discovering participating nodes and candidate resources. Gossip A distributed state propagation mechanism between participating nodes.

36. Conclusion

PSHMP Core is a decentralized data delivery and proactive self- healing network core designed for distributed systems operating over existing IP infrastructure. Its architecture combines:

The core objective is to provide distributed platforms with an additional network resilience layer without requiring replacement of the underlying IP infrastructure. The current implementation demonstrates the feasibility of the architecture through internal testing and a working Go implementation. PSHMP Core is intended to serve as a technology foundation that can be integrated into larger distributed systems, telecommunications platforms, edge infrastructure, and other network-intensive environments. The implementation is available for technical evaluation, pilot integration, and further development.

37. References

[RFC768]
Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC768, , <https://www.rfc-editor.org/info/rfc768>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8446]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, , <https://www.rfc-editor.org/info/rfc8446>.

Author's Address

Alexander Kolomytsev
Independent Researcher