]> Independent Researcher

giro.pandemik@gmail.com

Internet self-healing overlay mesh decentralized transport 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.

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. 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.

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

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

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.

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.

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.

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.

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.

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.

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
• admission control

This document does not mandate a specific security framework.

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.

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.

IANA Considerations This document has no IANA actions.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Informative References This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.

Acknowledgments The author would like to thank all reviewers and practitioners working on resilient and decentralized networking architectures.