PSHMP Core: A Hybrid L4 Overlay for Proactive Self-Healing and Resilient Multi-Hop Delivery

Introduction Distributed systems frequently depend on imperfect connectivity. Packet loss, jitter, overloaded links, node failures, and partial outages appear in cloud, edge, industrial, and telecommunications environments. Classic recovery approaches tend to restore service only after a hard failure is declared. By then applications have often already experienced disruption. PSHMP Core treats progressive degradation as a first-class signal. Nodes continuously evaluate stability using a composite quality metric (K-Factor) and, independently, a utilisation signal (Load). When quality on an active logical path falls below configurable thresholds, the system begins reconstructing that path—often while residual connectivity still exists. The intent is to reduce dependence on any single central controller and to keep multi-hop delivery usable for longer under stress. The overlay sits above existing IP. It does not replace routers or rewrite the Internet Protocol. It adds a logical layer that selects relays, builds multi-hop chains, detects trouble early, and rebuilds paths when necessary. Underlay routing remains responsible for IP reachability between peer addresses; PSHMP Core remains responsible for the membership and repair of logical delivery sequences among those peers.

Scope and Positioning PSHMP Core is intended as a technology foundation for integration, not as a finished consumer appliance with universal service-level claims. Organisations that already operate distributed platforms can evaluate it as an additional resilience layer. Representative environments include:

edge and multi-site computing;
telecommunications and backhaul overlays;
industrial and infrastructure networks;
telemetry-heavy or session-oriented systems;
geographically spread services that must tolerate partial outages;
architectures that need multi-hop delivery with recovery driven by continuous quality signals rather than solely by hard failover.

The design does not claim to eliminate every failure. When the underlying network is completely partitioned, or when too few healthy relays remain, no overlay can invent connectivity. What it can do is use available relays more deliberately and recover logical paths earlier in the degradation cycle.

Architectural Position PSHMP Core lives between the application and the ordinary IP network:

Placement above IP The IP layer continues to provide basic reachability. PSHMP Core uses that reachability as a substrate for logical multi-hop paths that it can rebuild on its own terms.

Architecture Layers and Components The experimental implementation organises functionality into logical layers. The following summary reflects the reference structure:

Logical component layers Control-plane decisions influence data-plane behaviour. Decentralized components supply candidates and peer state when a coordinator is absent. Chain management owns authoritative snapshots of primary and backup paths and the mesh posture used by recovery; the healing engine requests rebuilds through that authority rather than maintaining a contradictory second mesh state machine.

Hybrid Operating Model A distinctive trait of the design is the hybrid operating model. In normal conditions the system prefers linear relay chains: ordered sequences of relays that carry data from source toward destination. Chains are comparatively easy to reason about, have interpretable latency structure, and can be assisted by an optional coordinator when stronger consistency of membership views is desired. When several nodes on an active chain show clear degradation, the system can enter a local mesh-recovery posture for that chain. It does not tear down the entire overlay. It collects alternative candidates, applies progressive fallback and diversity rules, checks a quality gate, and replaces only the affected path. Former chain endpoints are not retained solely by historical role if their quality is inadequate. When conditions improve, operation can return to the linear style. This hybrid approach keeps the common case simple while providing an escape hatch when multiple relays degrade together. Default data-plane behaviour remains ordered forwarding on one logical path, not permanent simultaneous multipath transmission of the same application object.

Dynamic Chain Relay and Forwarding Invariants A relay chain is a sequence of participating nodes that forward data. Chains are rebuilt when a relay becomes unreachable; when loss, latency, or jitter rises beyond useful thresholds; when K-Factor falls; when load makes a relay unsuitable; when a local segment becomes unstable; or when several nodes on the same path degrade together. The experimental data plane observes the following forwarding invariants:

The source transmits each application fragment to the first relay of the chain only (first-hop send).
Each intermediate relay forwards the same fragment identity (session and sequence preserved) toward the next hop.
Relays do not re-segment application payload under a new session identity as part of ordinary forwarding.

The goal is not merely to add hops. The goal is to keep a usable logical path alive by substituting weak participants for healthier ones without requiring the underlying IP routing to change.

Node Quality Metric (K-Factor) PSHMP Core evaluates nodes with a composite metric called K-Factor. Rather than relying on a single instantaneous sample, K-Factor combines several signals into one stability score used both for selecting relays and for detecting degradation early.

Reference Formula In the experimental implementation the reference model is:

K-Factor reference formula where loss is a packet-loss ratio in [0, 1]; jitter and rtt are measured in milliseconds; and battery is an optional resource indicator in [0, 1] (often fixed at 1.0 for stationary hosts). Each normalised term is limited to [0, 1] so that extreme values cannot dominate the score. The weights (0.45 / 0.25 / 0.20 / 0.10) and normalisation constants are reference values. Integrators may change them; the architectural requirement is that a continuous stability estimate drives selection and recovery decisions. Absence of recent measurements is treated as unknown (K = 0 in the reference code), not as implicit health.

Status Bands The experimental implementation maps K to qualitative bands such as EXCELLENT, GOOD, ACCEPTABLE, DEGRADED, CRITICAL, and UNKNOWN. Exact cut- overs are configuration parameters. A node whose K remains above a hard- failure line but is sliding downward can be scheduled for replacement before it becomes unreachable.

Load Signal and Effective Ranking Channel quality alone is an incomplete predictor of relay suitability. A host may report favourable loss and delay yet be saturated by outstanding work. The reference design therefore maintains a separate Load signal, typically derived from the ratio of pending fragments to a configured in-flight budget, and mapped onto an ordered scale (for example 1 through 5). Ordinary candidate ordering combines the two signals:

Load factor and effective quality Candidates with lambda = 0 are skipped in ordinary selection. Under stress-oriented modes, additional minimum-K and diversity constraints apply. A mesh-oriented selector may also apply a multi-term utility (quality, latency, loss, freshness, domain diversity, and penalties). That utility must not be confused with effectiveK in analysis or documentation. Selection is heuristic ranking over a bounded local peer view. It is not an exact global combinatorial optimisation of routes.

Proactive Self-Healing Self-healing is organised around priorities. Complete failure is treated as critical. Progressive degradation is classified according to how far K-Factor has fallen, with scheduling delays and adaptive cooldown so that the system does not thrash when many nodes fluctuate near a threshold. A representative sequence is: observe degradation; prioritise; gather candidates; construct and diversity-check a replacement; validate through a quality gate; publish the new chain through chain management; retire the old path. Because the process can start from degradation rather than from total failure, the window of visible service impact may be shortened. Measured recovery times depend strongly on topology, load, and configuration; laboratory figures must not be read as portable field guarantees.

Local Mesh Recovery When multiple nodes on the same chain are degraded, the system can activate local mesh recovery for that chain: mark the affected path; collect candidates while excluding quarantined nodes; apply a multi-level fallback ladder that gradually relaxes average-quality and diversity requirements; run a quality gate; replace the chain under concurrency control. Early ladder levels insist on higher average K and stronger spread across failure domains. Later levels accept lower quality or relax diversity when the alternative is silence. The quality gate prevents installing a clearly inferior path merely because it is the only remaining construction.

Diversity-Aware Selection Failures are often correlated. Nodes that share a rack, site, provider, or segment tend to suffer together. Selecting the highest-scoring individuals without regard to shared risk can reproduce the same outage on the replacement path. PSHMP Core can group nodes by logical failure domain and, during recovery, prefer candidates from different groups. The preference is stronger under stress and may be relaxed when healthy diversity is unavailable.

Failure Tracking and Quarantine A node that has just failed is a poor candidate for immediate reuse. The design keeps a short failure history and may place unstable nodes into temporary quarantine. After sustained stable behaviour the node may return to the candidate pool. This reduces recovery loops driven by the same unreliable participants.

Decentralised Discovery and State Gossip disseminates node state, K-Factor and Load updates, and related control information. DHT-assisted indexing supplies candidate relays when a node needs fresh options, especially if a coordinator is unreachable. The DHT is treated primarily as a discovery and ranking aid for relay candidates rather than as a general-purpose application key-value store. An optional coordinator can provide registration, heartbeat, and admission services, and may itself use consensus machinery for durable control state. The architecture does not make continuous coordinator participation mandatory on the data-forwarding path once peers and chains are known.

Data Delivery Path and Acknowledgement Model Reliable multi-hop delivery is handled by a dedicated DataPath. Application data are segmented into chunks. Each chunk carries a session identifier and a monotone sequence number, together with an integrity check suitable for error detection (the reference implementation uses CRC32 as a checksum, not as a cryptographic authenticator). Path recovery and fragment recovery are separate concerns. Healing changes which relays participate. DataPath repairs missing sequence numbers on the session regardless of which physical path carried an individual attempt, subject to reachability and timeout policy.

Delivery Flow (Conceptual)

Chunk forwarding and batch acknowledgement Relay1 --> Relay2 --> ... --> Destination | v update contiguous prefix record Gaps | v Batch ACK { session, last_contiguous, max_observed, gaps[], MAC? } | v Source: retransmit outstanding missing sequences (timeout-based retry; optional in-flight limit) ]]> In the reference model, acknowledgements travel from destination toward source. Hop-by-hop acknowledgement along intermediate relays is not required. Optional backpressure refuses additional send work when outstanding fragments would exceed a configured budget.

Batch ACK and Gaps A batch acknowledgement reports at least a contiguous received prefix, a maximum observed sequence, and explicit gap ranges. Retransmission targets sequences that remain outstanding and are known missing or have exceeded a timeout, rather than treating every sequence beyond a hole as automatically lost in an unbounded tail expansion.

Control Traffic Considerations Batch acknowledgements and gap lists are intended to reduce unnecessary retransmission and acknowledgement chatter relative to naive per-fragment schemes under favourable conditions. Actual savings depend on loss patterns, batch size, and workload. Quantitative laboratory observations are not portable service-level claims.

Transport Abstraction The overlay is deliberately transport-agnostic at the edges. Implementations may run over UDP , DTLS , TLS-protected TCP , or other bidirectional transports. Higher-level recovery logic does not depend on a single carrier protocol.

Security Considerations Reference designs may combine optional channel protection (TLS/DTLS), shared-secret authentication of selected broadcast and candidate metadata, rate limiting, and admission control for optional registration services. A network-wide message-authentication secret is not equivalent to per-node public-key identity. Key rotation, revocation, multi-tenant isolation, and regulatory compliance are deployment responsibilities. Laboratory defaults may relax transport protection; production evaluations should treat trust configuration as mandatory design work. Overlays that recruit third-party relays inherit classical threats: gossip poisoning, Sybil membership, and malicious forwarding. Integrators must define policy for untrusted participants. An external per-node verifier model may be specified in future work; it is not assumed complete here.

Scalability Notes Candidate selection operates on local views and bounded pools. Gossip and DHT-assisted discovery trade freshness against overhead. Emulation at large process counts can demonstrate software feasibility; it does not by itself certify capacity for a particular production topology.

Experimental Implementation An experimental Go implementation exercises the architecture end-to-end: chain construction, hybrid candidate indexing, mesh recovery, session delivery, acknowledgements, and optional coordinator paths. Engineering documentation accompanying the codebase records tested behaviours, known laboratory limitations, and integrator responsibilities. Where this overview and implementation notes diverge on concurrency or security configuration, implementers should treat carefully documented engineering invariants as authoritative for that codebase and should update this overview when architectural invariants change.

Example Scenario Consider a six-relay chain carrying a session under rising loss on two intermediate hops. K-Factor on those hops declines into a degraded band while IP reachability remains. Healing prioritises the condition, mesh posture tightens diversity requirements, HybridDHT-assisted selection returns candidates outside the failing domain, and chain management publishes a replacement path that excludes the degraded relays. Concurrently, DataPath gap recovery retransmits any outstanding missing sequences without requiring the entire object to be resent as a single opaque unit.

Potential Benefits Potential operational benefits—subject to deployment measurement—include earlier reaction to degradation than hard-failure-only designs; logical resilience without mandatory underlay redesign; interpretable ordered forwarding in the common case; and more targeted retransmission via explicit gaps. None of these outcomes is guaranteed across arbitrary networks.

Integration Model Typical integration places PSHMP Core beneath application protocols and above IP, on gateway- or host-class nodes. Optional coordinator services may run centrally. Constrained devices may eventually host reduced decision logic; the full reference stack is not claimed for microcontroller-class targets in this document.

Deployment Considerations Operators should define trust policy, secret distribution, transport mode, and pilot success metrics before production exposure. Scoped pilots on the target topology remain the appropriate way to assess benefit against a local baseline.

Design Principles

Degradation is a first-class signal.
Keep the common case (ordered chains) simple.
Recover locally; avoid global teardown for a single path fault.
Separate path membership repair from fragment repair.
Rank relays by quality and load; prefer diversity under stress.
Remain above IP and flexible at the transport edge.
State limits explicitly.

Limitations PSHMP Core cannot create connectivity where none exists. Performance depends on the number and quality of available relays, the underlay, workload, and configuration. Figures from emulation or limited trials must be re-validated for each production environment. Reference formulas are part of the experimental model; production deployments may adjust weights and thresholds.

IANA Considerations This document has no IANA actions.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This informational document uses those terms sparingly; normative protocol requirements are out of scope.

PSHMP Core: The overlay architecture described in this document.
Relay: A participating node that forwards data for others.
Relay chain: An ordered sequence of relays forming a logical delivery path.
K-Factor: Composite stability metric for selection and early degradation detection.
Load: Utilisation signal distinct from channel quality.
Self-healing: Automatic reconstruction of degraded delivery paths.
Local mesh recovery: Path reconstruction for an affected chain using alternative candidates, fallback levels, and a quality gate.
Diversity: Preference for relays drawn from different failure domains.
Gap list: Explicit missing sequence ranges in a batch acknowledgement.
DataPath: Component responsible for chunking, chain transmission, acknowledgements, and retransmission of missing sequences.

Changes from draft-kolomytsev-pshmp-core-overview-00

Clarified transport-agnostic placement in the Abstract.
Refined introductory language around imperfect connectivity and recovery timing.
Documented first-hop forwarding and same-fragment relay invariants.
Added Load and effectiveK ranking; distinguished ordinary and mesh selectors.
Stated ChainManager authority for path/mesh state relative to healing.
Separated path recovery from fragment recovery more explicitly.
Expanded security limits (shared-secret MAC versus per-node PKI).
Softened portable recovery-time and control-overhead claims.
Removed coupling of the architectural discussion to a specific marketing product label.

Conclusion PSHMP Core offers a hybrid overlay for environments where connectivity is imperfect and multi-hop delivery must tolerate progressive degradation. Linear chains keep the common case intelligible; local mesh recovery, K-Factor and Load-driven decisions, diversity awareness, and gap-aware acknowledgements provide machinery when conditions worsen. The design stays above IP, remains transport-flexible at the edges, and can operate with or without a central coordinator on the forwarding path. Reference formulas and experimental structure are provided so that readers can examine a concrete model. Integrators remain free—and responsible—to tune parameters, define trust, and validate behaviour on their own networks. PSHMP Core is offered as a technology foundation for organisations prepared to evaluate and integrate resilient multi-hop delivery within their platforms.