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

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:

evaluating the condition of participating nodes and paths;
constructing dynamic multi-hop delivery chains;
monitoring changes in network conditions;
identifying degradation before complete failure;
proactively rebuilding affected delivery paths;
using alternative nodes when existing paths become unreliable;
distributing network state through decentralized mechanisms;
operating without requiring modifications to the underlying Layer 3 routing architecture.

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

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

distributed computing platforms;
edge computing;
telecommunications infrastructure;
resilient data delivery systems;
distributed storage;
real-time communication systems;
IoT infrastructure;
industrial and infrastructure networks;
geographically distributed services;
decentralized network architectures;
high-availability overlay networks.

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.

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

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.

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:

path selection;
relay selection;
delivery-chain construction;
node evaluation;
failure detection;
recovery;
traffic adaptation.

The resulting architecture can be described as: Application

PSHMP Core

| Dynamic logical delivery path

Existing IP Infrastructure

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.

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

Relay A

Relay B

Relay C

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.

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:

a relay becomes unavailable;
packet loss increases;
latency becomes excessive;
jitter increases;
node quality decreases;
a local network segment becomes unstable;
multiple nodes within the same delivery path degrade simultaneously.

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.

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:

packet loss;
latency;
jitter;
node availability;
recent failures;
path quality;
historical behavior;
local network conditions.

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.

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

K-Factor

Routing decision The K-Factor can be used to distinguish between:

healthy nodes;
degraded nodes;
unstable nodes;
nodes that should temporarily be excluded from new delivery paths.

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

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

Detection

Decision

Route reconstruction

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

Condition evaluated

Alternative path selected

Delivery chain reconstructed

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.

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:

identify multiple degraded nodes within a chain;
obtain additional relay candidates;
exclude recently failed or quarantined nodes;
prefer candidates from different groups;
construct an alternative relay chain;
validate the resulting chain;
replace the affected chain atomically.

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

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

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.

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

the same physical location;
the same network segment;
the same infrastructure provider;
the same failure domain;
the same local connectivity problem.

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

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

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:

identify repeatedly unstable nodes;
temporarily exclude problematic nodes;
prevent immediate reinsertion after failure;
gradually rehabilitate nodes after stable operation;
improve future path selection.

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.

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

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.

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 | | ]]> | +----> Node D

Node C | +----> Node E ]]> 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.

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:

node availability;
node quality;
group membership;
recent failures;
diversity requirements;
current recovery conditions.

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

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

geographic region;
infrastructure segment;
logical cluster;
provider;
availability zone;
deployment group.

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.

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

Relaxed quality requirements

Relaxed diversity requirements

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:

normal operation;
degraded operation;
multi-node failure;
emergency recovery.

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.

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:

UDP-based communication;
TCP-based communication;
TLS/DTLS-protected channels;
WebRTC DataChannel;
TURN-assisted connectivity.

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

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:

rate limiting;
connection controls;
Proof-of-Work mechanisms;
authenticated and encrypted transport options;
failure tracking;
temporary node quarantine.

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.

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

distributed state propagation;
DHT-based discovery;
sharding;
decentralized candidate selection;
optional coordinated cluster mechanisms.

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.

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

15,900+ lines of Go code;
90+ Go source files;
dynamic chain relay;
DHT-based candidate selection;
Gossip integration;
K-Factor node evaluation;
Self-Healing Engine;
local mesh recovery;
diversity-aware candidate selection;
failure tracking;
quarantine and rehabilitation;
adaptive recovery policies;
sharding support;
optional Raft-based coordination;
WebRTC connectivity;
Prometheus metrics;
Docker-based deployment support.

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

Implementation Architecture A simplified implementation view is:

v v v

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

Example Operational Scenario Consider a distributed system using six relay nodes: Source

Relay A

Relay B

Relay C

Relay D

Relay E

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:

identify the degraded nodes;
activate local mesh recovery;
obtain alternative candidates through decentralized discovery;
exclude recently failed or quarantined candidates;
apply diversity-aware selection;
construct a replacement chain;
validate the resulting chain;
replace the affected path.

The resulting path may become: Source

Relay A

Relay F

Relay G

Relay H

Relay E

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

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

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.

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

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

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

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

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

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

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

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

v v Application Logic PSHMP Core

Existing Network The integrating company can retain ownership of:

application logic;
user-facing services;
infrastructure;
identity systems;
deployment model;
commercial product.

PSHMP Core provides the underlying network resilience layer.

Deployment Considerations A production deployment should evaluate:

network topology;
node density;
expected packet loss;
latency characteristics;
failure domains;
security requirements;
node identity;
discovery mechanisms;
operational monitoring;
capacity requirements.

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

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

node condition;
path condition;
recovery events;
chain reconstruction;
mesh activation;
candidate selection;
failure events;
network traffic;
protocol-level statistics.

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.

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

routers;
switches;
cloud networks;
virtual networks;
data centers;
edge infrastructure;
telecommunications infrastructure.

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

Design Principles The architecture is based on several principles.

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

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

Dynamic Paths Delivery paths should adapt to changing network conditions.

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

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

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

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:

topology;
available relay nodes;
network quality;
node distribution;
workload;
configuration;
implementation environment.

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

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

trusted private networks;
controlled infrastructure;
federated environments;
authenticated distributed networks.

For untrusted environments, additional mechanisms may be required for:

node identity;
authorization;
cryptographic authentication;
key management;
abuse prevention;
isolation of malicious participants.

The current document does not define a universal trust model.

IANA Considerations This document has no IANA actions.

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.

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:

decentralized data delivery;
L4-oriented overlay networking;
dynamic relay chains;
continuous node evaluation;
K-Factor-based routing decisions;
proactive self-healing;
local mesh recovery;
diversity-aware path reconstruction;
failure tracking;
DHT-based candidate discovery;
Gossip-based state propagation;
adaptive recovery policies.

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.