Proactive Self-Healing Mesh Protocol (PSHMP)

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

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

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

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¶

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

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¶

• 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

Appendix A. Acknowledgments

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

Author's Address