Network Working Group A. Kolomytsev Internet-Draft Independent Researcher Intended status: Informational August 2026 Expires: 7 February 2027 Proactive Self-Healing Mesh Protocol (PSHMP) draft-kolomytsev-pshmp-overview-00 Abstract This document describes the Proactive Self-Healing Mesh Protocol (PSHMP), a decentralized overlay transport architecture designed to improve resilience and availability in distributed IP networks. PSHMP operates as an L4-oriented overlay above existing IP infrastructure. It continuously evaluates path quality and proactively reconstructs routes before degradation becomes service- impacting. The architecture combines decentralized topology discovery, adaptive path selection, batch acknowledgements, and transport abstraction to provide reliable communication under unstable network conditions without requiring modifications to underlying IP routing. This document presents the protocol architecture, design principles, and an overview of an experimental implementation. It does not specify an Internet Standard. 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 2 February 2027. Kolomytsev Expires 7 February 2027 [Page 1] Internet-Draft PSHMP August 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 3 4. Overlay Operation . . . . . . . . . . . . . . . . . . . . . . 4 5. Path Quality Evaluation (K-Factor) . . . . . . . . . . . . . 4 6. Proactive Recovery . . . . . . . . . . . . . . . . . . . . . 4 7. Decentralized Coordination . . . . . . . . . . . . . . . . . 5 8. Control Traffic Optimization . . . . . . . . . . . . . . . . 5 9. Transport Abstraction . . . . . . . . . . . . . . . . . . . . 5 10. Security Considerations . . . . . . . . . . . . . . . . . . . 5 11. Scalability Considerations . . . . . . . . . . . . . . . . . 6 12. Implementation Status and Structure . . . . . . . . . . . . . 6 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 14.1. Normative References . . . . . . . . . . . . . . . . . . 6 14.2. Informative References . . . . . . . . . . . . . . . . . 7 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Distributed systems increasingly operate across heterogeneous, partially unreliable, and dynamically changing network environments. Traditional recovery mechanisms typically react only after packet loss or path failure has already occurred. As a result, recovery latency is often measured in seconds and depends on routing convergence or application-level timeouts. PSHMP proposes a different approach. Participating nodes continuously evaluate the quality of available paths and proactively rebuild overlay routes when degradation is detected, aiming to restore connectivity before complete failure occurs. Kolomytsev Expires 7 February 2027 [Page 2] Internet-Draft PSHMP August 2026 The protocol is designed as a decentralized L4-oriented overlay. It does not replace or modify IP routing (L3). Instead, it constructs and maintains an adaptive mesh of transport-level paths above the existing network. 2. Design Goals The primary design goals of PSHMP are: * Proactive route recovery based on continuous quality estimation * Fully decentralized operation without mandatory central control * Independence from specific underlying transport protocols * Efficient control-plane traffic * Compatibility with existing IP infrastructure * Scalability to large numbers of participating nodes * Minimal deployment requirements 3. Architectural Overview PSHMP is implemented as an overlay transport layer. Nodes form a dynamic mesh and exchange topology and quality information. The architecture consists of the following logical components: * Node Manager * Path Quality Evaluation (K-Factor) * Path Selection and Chain Relay * Self-Healing Engine * Gossip-based Synchronization * DHT-based Fallback Discovery * Batch Acknowledgement Subsystem * Adaptive Transport Abstraction Kolomytsev Expires 7 February 2027 [Page 3] Internet-Draft PSHMP August 2026 4. Overlay Operation Each node periodically exchanges topology and quality information with a subset of peers. Multiple candidate paths are maintained concurrently. When the quality of an active path falls below a configurable threshold, traffic is redirected to an alternative path that has already been evaluated. This approach reduces recovery latency compared with purely reactive failover mechanisms. 5. Path Quality Evaluation (K-Factor) PSHMP uses a composite metric called K-Factor to estimate path and node stability. The metric may incorporate: * packet loss * round-trip time * jitter * optional node health indicators The resulting value is intended to reflect the likelihood of future degradation rather than instantaneous connectivity alone. Implementations may use different weighting functions according to deployment requirements. 6. Proactive Recovery Recovery is organized into logical phases: 1. Degradation detection 2. Alternative path selection 3. Route activation 4. Retirement of the degraded path Prototype measurements have shown average recovery times on the order of several hundred milliseconds under the evaluated conditions. Actual performance depends on network topology and configuration. Kolomytsev Expires 7 February 2027 [Page 4] Internet-Draft PSHMP August 2026 7. Decentralized Coordination PSHMP does not require a permanently available central controller. Topology and quality information are disseminated using gossip-style synchronization. When coordinators are unavailable, DHT-based mechanisms allow peer discovery and basic operation to continue. Optional consensus mechanisms (for example Raft) may be used in deployments that require stronger consistency for control-plane state. 8. Control Traffic Optimization To reduce overhead, PSHMP aggregates acknowledgements. Receivers transmit cumulative acknowledgements together with lists of missing fragments (Gap List) instead of acknowledging every packet individually. Prototype evaluations indicate that this approach can substantially reduce control traffic compared with traditional per-packet acknowledgement strategies. 9. Transport Abstraction PSHMP is intentionally transport-independent. Implementations may operate over: * UDP * DTLS * WebRTC Data Channels * other suitable bidirectional transports The choice of underlying transport is considered an implementation detail. 10. Security Considerations Security mechanisms are considered orthogonal to the core routing and recovery architecture. Possible approaches include: * DTLS / TLS * message authentication (e.g., HMAC) * rate limiting Kolomytsev Expires 7 February 2027 [Page 5] Internet-Draft PSHMP August 2026 * admission control This document does not mandate a specific security framework. 11. Scalability Considerations The architecture is intended to support deployments ranging from small groups of nodes to several thousand participants. Prototype testing has demonstrated operation with more than five thousand simulated nodes. No hard architectural limit is defined. 12. Implementation Status and Structure An experimental implementation of PSHMP exists in the Go programming language. The implementation validates the architectural concepts described in this document and currently exceeds 13,000 lines of code. The codebase is organized into the following primary packages: * pkg/node — Node lifecycle and management * pkg/probing — K-Factor calculation and active probing * pkg/chain — Chain Relay and path construction * pkg/healing — Self-Healing Engine * pkg/gossip — Decentralized state dissemination * pkg/dht — DHT-based fallback discovery * pkg/ack — Batch ACK and Gap List handling * pkg/coordinator — Optional coordination, sharding and Raft support * pkg/transport — Transport abstraction (UDP, WebRTC, DTLS) The implementation has been used for both emulation-based testing (up to 5,000 nodes) and limited real-network experiments. 13. IANA Considerations This document has no IANA actions. 14. References 14.1. Normative References Kolomytsev Expires 7 February 2027 [Page 6] Internet-Draft PSHMP August 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 14.2. Informative References [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC768, August 1980, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . Appendix A. Acknowledgments The author would like to thank all reviewers and practitioners working on resilient and decentralized networking architectures. Author's Address Alexander Kolomytsev Independent Researcher Email: giro.pandemik@gmail.com Kolomytsev Expires 7 February 2027 [Page 7]