Network Working Group A. Kolomytsev Internet-Draft Independent Researcher Intended status: Informational 30 August 2026 Expires: 3 March 2027 PSHMP Core: Decentralized L4 Overlay for Resilient Data Delivery and Proactive Self-Healing Networks draft-kolomytsev-pshmp-core-00 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/. Kolomytsev Expires 3 March 2027 [Page 1] Internet-Draft PSHMP Core August 2026 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. Copyright Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Architectural Position . . . . . . . . . . . . . . . . . . . 5 4. L4-Oriented Data Delivery . . . . . . . . . . . . . . . . . . 5 5. Decentralized Data Delivery . . . . . . . . . . . . . . . . . 6 6. Dynamic Chain Relay . . . . . . . . . . . . . . . . . . . . . 7 7. Node and Path Evaluation . . . . . . . . . . . . . . . . . . 8 8. Node Quality Metric (K-Factor) . . . . . . . . . . . . . . . 8 9. Proactive Self-Healing . . . . . . . . . . . . . . . . . . . 9 10. Local Mesh Recovery . . . . . . . . . . . . . . . . . . . . . 11 11. Diversity-Aware Recovery . . . . . . . . . . . . . . . . . . 12 12. Failure Tracking . . . . . . . . . . . . . . . . . . . . . . 12 13. Distributed Network State . . . . . . . . . . . . . . . . . . 13 14. Gossip-Based Information Exchange . . . . . . . . . . . . . . 13 15. DHT-Based Candidate Discovery . . . . . . . . . . . . . . . . 14 16. Failure-Domain Awareness . . . . . . . . . . . . . . . . . . 14 17. Adaptive Recovery Policies . . . . . . . . . . . . . . . . . 15 18. Batch Acknowledgement and Gap Recovery . . . . . . . . . . . 15 19. Transport and Connectivity . . . . . . . . . . . . . . . . . 16 20. Security Considerations . . . . . . . . . . . . . . . . . . . 16 21. Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 17 22. Current Implementation . . . . . . . . . . . . . . . . . . . 17 23. Implementation Architecture . . . . . . . . . . . . . . . . . 18 24. Example Operational Scenario . . . . . . . . . . . . . . . . 19 25. Performance Characteristics . . . . . . . . . . . . . . . . . 22 Kolomytsev Expires 3 March 2027 [Page 2] Internet-Draft PSHMP Core August 2026 26. Potential Benefits . . . . . . . . . . . . . . . . . . . . . 22 26.1. Reduced Recovery Time . . . . . . . . . . . . . . . . . 22 26.2. Improved Network Resilience . . . . . . . . . . . . . . 22 26.3. Reduced Dependence on Individual Components . . . . . . 23 26.4. More Efficient Control Traffic . . . . . . . . . . . . . 23 26.5. Infrastructure Reuse . . . . . . . . . . . . . . . . . . 23 26.6. Adaptive Recovery . . . . . . . . . . . . . . . . . . . 23 27. Integration Model . . . . . . . . . . . . . . . . . . . . . . 23 28. Deployment Considerations . . . . . . . . . . . . . . . . . . 24 29. Monitoring and Observability . . . . . . . . . . . . . . . . 24 30. Interoperability . . . . . . . . . . . . . . . . . . . . . . 25 31. Design Principles . . . . . . . . . . . . . . . . . . . . . . 25 31.1. Decentralization . . . . . . . . . . . . . . . . . . . . 25 31.2. Proactive Recovery . . . . . . . . . . . . . . . . . . . 26 31.3. Dynamic Paths . . . . . . . . . . . . . . . . . . . . . 26 31.4. Diversity . . . . . . . . . . . . . . . . . . . . . . . 26 31.5. Layer Independence . . . . . . . . . . . . . . . . . . . 26 31.6. Graceful Degradation . . . . . . . . . . . . . . . . . . 26 32. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 26 33. Security and Trust Model . . . . . . . . . . . . . . . . . . 27 34. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 35. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 27 36. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 28 37. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29 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: * evaluating the condition of participating nodes and paths; * constructing dynamic multi-hop delivery chains; * monitoring changes in network conditions; Kolomytsev Expires 3 March 2027 [Page 3] Internet-Draft PSHMP Core August 2026 * 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. 2. 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. Kolomytsev Expires 3 March 2027 [Page 4] Internet-Draft PSHMP Core August 2026 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: * path selection; * relay selection; * delivery-chain construction; * node evaluation; * failure detection; * recovery; Kolomytsev Expires 3 March 2027 [Page 5] Internet-Draft PSHMP Core August 2026 * traffic adaptation. 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 Kolomytsev Expires 3 March 2027 [Page 6] Internet-Draft PSHMP Core August 2026 | 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: * 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. Kolomytsev Expires 3 March 2027 [Page 7] Internet-Draft PSHMP Core August 2026 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: * 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. 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 Kolomytsev Expires 3 March 2027 [Page 8] Internet-Draft PSHMP Core August 2026 | *-- 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: * 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. 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 Kolomytsev Expires 3 March 2027 [Page 9] Internet-Draft PSHMP Core August 2026 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 Kolomytsev Expires 3 March 2027 [Page 10] Internet-Draft PSHMP Core August 2026 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: * 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 | | | +---+---+ 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. Kolomytsev Expires 3 March 2027 [Page 11] Internet-Draft PSHMP Core August 2026 11. 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 \ | / \ | / \ | / 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: * identify repeatedly unstable nodes; * temporarily exclude problematic nodes; * prevent immediate reinsertion after failure; * gradually rehabilitate nodes after stable operation; * improve future path selection. Kolomytsev Expires 3 March 2027 [Page 12] Internet-Draft PSHMP Core August 2026 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. Kolomytsev Expires 3 March 2027 [Page 13] Internet-Draft PSHMP Core August 2026 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: * 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. 16. 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. Kolomytsev Expires 3 March 2027 [Page 14] Internet-Draft PSHMP Core August 2026 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: * normal operation; * degraded operation; * multi-node failure; * emergency recovery. 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 Kolomytsev Expires 3 March 2027 [Page 15] Internet-Draft PSHMP Core August 2026 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: * 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. 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: * rate limiting; * connection controls; * Proof-of-Work mechanisms; * authenticated and encrypted transport options; * failure tracking; * temporary node quarantine. Kolomytsev Expires 3 March 2027 [Page 16] Internet-Draft PSHMP Core August 2026 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: * 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. 22. 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; Kolomytsev Expires 3 March 2027 [Page 17] Internet-Draft PSHMP Core August 2026 * 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. 23. Implementation Architecture A simplified implementation view is: Kolomytsev Expires 3 March 2027 [Page 18] Internet-Draft PSHMP Core August 2026 +----------------------+ | 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 Kolomytsev Expires 3 March 2027 [Page 19] Internet-Draft PSHMP Core August 2026 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: * identify the degraded nodes; * activate local mesh recovery; * obtain alternative candidates through decentralized discovery; * exclude recently failed or quarantined candidates; Kolomytsev Expires 3 March 2027 [Page 20] Internet-Draft PSHMP Core August 2026 * apply diversity-aware selection; * construct a replacement chain; * validate the resulting chain; * replace the affected path. 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 Kolomytsev Expires 3 March 2027 [Page 21] Internet-Draft PSHMP Core August 2026 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. Kolomytsev Expires 3 March 2027 [Page 22] Internet-Draft PSHMP Core August 2026 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: * application logic; * user-facing services; * infrastructure; Kolomytsev Expires 3 March 2027 [Page 23] Internet-Draft PSHMP Core August 2026 * identity systems; * deployment model; * commercial product. PSHMP Core provides the underlying network resilience layer. 28. 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. 29. Monitoring and Observability The current implementation includes operational observability mechanisms. Relevant metrics can include: * node condition; * path condition; * recovery events; * chain reconstruction; Kolomytsev Expires 3 March 2027 [Page 24] Internet-Draft PSHMP Core August 2026 * 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. 30. 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. 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. Kolomytsev Expires 3 March 2027 [Page 25] Internet-Draft PSHMP Core August 2026 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: * topology; * available relay nodes; * network quality; * node distribution; * workload; * configuration; * implementation environment. Kolomytsev Expires 3 March 2027 [Page 26] Internet-Draft PSHMP Core August 2026 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: * 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. 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 Kolomytsev Expires 3 March 2027 [Page 27] Internet-Draft PSHMP Core August 2026 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: * 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. Kolomytsev Expires 3 March 2027 [Page 28] Internet-Draft PSHMP Core August 2026 37. References [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC768, August 1980, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . Author's Address Alexander Kolomytsev Independent Researcher Email: kolomytsev@example.com Kolomytsev Expires 3 March 2027 [Page 29]