Network Working Group A. Kolomytsev Internet-Draft Independent Researcher Intended status: Informational 3 September 2026 Expires: 7 March 2027 PSHMP Core: A Hybrid L4 Overlay for Proactive Self-Healing and Resilient Multi-Hop Delivery draft-kolomytsev-pshmp-core-overview-00 Abstract PSHMP Core is a hybrid L4-oriented overlay designed to keep multi-hop data delivery working when individual nodes, links, or network segments become unstable. It runs above ordinary IP infrastructure and does not require changes to Layer 3 routing. Under stable conditions the system builds linear relay chains. When several nodes on a path show degradation, it can switch locally into a mesh-style recovery mode: collect alternative candidates, apply progressive fallback rules, enforce a quality gate, and replace the affected path. Continuous node assessment (K-Factor), diversity- aware selection, failure tracking, gossip and DHT discovery, and batch acknowledgements with gap recovery form the supporting mechanisms. This document describes the architecture (including component layers), operating principles, key evaluation and delivery formulas, and the relationship to an experimental implementation (PSHMP Core v3.1). Implementation-specific scoring weights, exact thresholds, and proprietary optimisations may be refined by integrators; the formulas given here represent the reference model used in the current experimental codebase. 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." Kolomytsev Expires 7 March 2027 [Page 1] Internet-Draft PSHMP Core September 2026 This Internet-Draft will expire on 7 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 and Positioning . . . . . . . . . . . . . . . . . . . . 3 3. Architectural Position . . . . . . . . . . . . . . . . . . . 4 4. Architecture Layers and Components . . . . . . . . . . . . . 4 5. Hybrid Operating Model . . . . . . . . . . . . . . . . . . . 5 6. Dynamic Chain Relay . . . . . . . . . . . . . . . . . . . . . 6 7. Node Quality Metric (K-Factor) . . . . . . . . . . . . . . . 6 7.1. Reference Formula . . . . . . . . . . . . . . . . . . . . 6 7.2. Status Bands . . . . . . . . . . . . . . . . . . . . . . 7 7.3. Path / Candidate Scoring . . . . . . . . . . . . . . . . 7 8. Proactive Self-Healing . . . . . . . . . . . . . . . . . . . 8 9. Local Mesh Recovery . . . . . . . . . . . . . . . . . . . . . 9 9.1. Fallback Ladder . . . . . . . . . . . . . . . . . . . . . 9 10. Diversity-Aware Selection . . . . . . . . . . . . . . . . . . 9 11. Failure Tracking and Quarantine . . . . . . . . . . . . . . . 10 12. Decentralised Discovery and State . . . . . . . . . . . . . . 10 13. Data Delivery Path and Acknowledgement Model . . . . . . . . 10 13.1. Delivery Flow (Conceptual) . . . . . . . . . . . . . . . 11 13.2. Batch ACK Structure . . . . . . . . . . . . . . . . . . 11 13.3. Control Traffic Reduction . . . . . . . . . . . . . . . 12 14. Transport Abstraction . . . . . . . . . . . . . . . . . . . . 12 15. Security Considerations . . . . . . . . . . . . . . . . . . . 12 16. Scalability Notes . . . . . . . . . . . . . . . . . . . . . . 12 17. Experimental Implementation . . . . . . . . . . . . . . . . . 13 18. Example Scenario . . . . . . . . . . . . . . . . . . . . . . 13 19. Potential Benefits . . . . . . . . . . . . . . . . . . . . . 14 20. Integration Model . . . . . . . . . . . . . . . . . . . . . . 14 21. Deployment Considerations . . . . . . . . . . . . . . . . . . 14 22. Design Principles . . . . . . . . . . . . . . . . . . . . . . 14 23. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 15 Kolomytsev Expires 7 March 2027 [Page 2] Internet-Draft PSHMP Core September 2026 24. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 25. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 15 26. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 16 27. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction Distributed systems rarely enjoy perfect connectivity. Packet loss, jitter, overloaded links, node failures, and partial outages appear in cloud, edge, industrial, and telecommunications environments alike. Classic recovery usually waits for a hard failure and then reacts. By the time a path is declared dead, applications have already felt the impact. PSHMP Core takes a different stance. It treats progressive degradation as a first-class signal. Nodes continuously evaluate their own and their neighbours' stability using a composite metric (K-Factor). When quality falls below configurable thresholds, the system starts reconstructing the affected delivery path—often before the path is completely unusable. The result is an overlay that tries to keep traffic moving with less disruption and with less dependence on any single central controller. The overlay sits above existing IP. It does not replace routers or rewrite the Internet Protocol. It adds a logical layer that can select relays, build multi-hop chains, detect trouble early, and rebuild paths when necessary. 2. Scope and Positioning PSHMP Core is intended as a technology foundation, not a finished consumer product. Organisations that already operate distributed platforms can integrate it to gain an additional resilience layer. Typical target environments include: * edge and multi-site computing; * telecommunications and backhaul overlays; * industrial and infrastructure networks; * real-time or telemetry-heavy systems; * geographically spread services that must tolerate partial outages; * any architecture that needs multi-hop delivery with faster recovery than pure reactive failover. Kolomytsev Expires 7 March 2027 [Page 3] Internet-Draft PSHMP Core September 2026 The protocol 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 the available relays more intelligently and recover more quickly from the failures that do occur. 3. Architectural Position PSHMP Core lives between the application and the ordinary IP network: +------------------------------------------------------+ | Distributed Application | +------------------------------------------------------+ | PSHMP Core | | Chain Relay | K-Factor | Self-Healing | Mesh | | Discovery | Batch ACK | Diversity | Transport | +------------------------------------------------------+ | Existing IP Network | +------------------------------------------------------+ | Physical / Virtual Infrastructure | +------------------------------------------------------+ Figure 1 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. 4. Architecture Layers and Components The experimental implementation organises functionality into logical layers. The following table summarises the main components: Kolomytsev Expires 7 March 2027 [Page 4] Internet-Draft PSHMP Core September 2026 +------------------+-----------------------------------------------+ | Layer | Components | +------------------+-----------------------------------------------+ | Control Plane | Coordinator (optional), Raft cluster, | | | Sharding, K-Factor Engine, Self-Healing | | | Engine, Mesh State Machine | +------------------+-----------------------------------------------+ | Data Plane | Chain Relay, PathFinder, Local Mesh Recovery, | | | DataPath, Batch ACK + Gap List, | | | Retransmit Cache | +------------------+-----------------------------------------------+ | Decentralization | DHT (Kademlia-style), Gossip (push + | | | anti-entropy), Discovery facade, Membership | +------------------+-----------------------------------------------+ | Security & | TLS/DTLS, HMAC, Rate Limiting, optional PoW, | | Transport | Transport abstraction (UDP/TCP/WebRTC) | +------------------+-----------------------------------------------+ | Infrastructure | Persistence (e.g. BoltDB), Config, Metrics | | | (Prometheus), Logging | +------------------+-----------------------------------------------+ Figure 2 Control Plane decisions (path construction, healing priorities) influence Data Plane behaviour. Decentralization components supply candidates and state when a central coordinator is unavailable. Security and transport mechanisms protect and carry the traffic without changing the higher-level recovery logic. 5. Hybrid Operating Model One of the distinctive traits of the current design is the hybrid operating model. In normal conditions the system prefers linear relay chains. A chain is a simple ordered sequence of relays that carries data from source toward destination. Chains are easy to reason about, have predictable latency characteristics, and can be constructed with the help of an optional coordinator when stronger consistency is desired. When several nodes on an active chain show clear degradation (typically three or more), the system can switch into a local mesh- recovery mode for that chain. It does not tear down the entire network. It collects alternative candidates (via DHT and gossip), applies progressive fallback rules, checks a quality gate, and replaces only the affected path. Once conditions improve, operation can return to the linear style. Kolomytsev Expires 7 March 2027 [Page 5] Internet-Draft PSHMP Core September 2026 This hybrid approach keeps the common case simple while still providing a robust escape hatch when multiple relays fail at once. 6. Dynamic Chain Relay A relay chain is a sequence of participating nodes that forward data. Chains are rebuilt when: * a relay becomes unreachable; * packet loss, latency, or jitter rises beyond useful thresholds; * node quality (K-Factor) falls; * a local network segment becomes unstable; * several nodes on the same path degrade together. The goal is not merely to add hops. The goal is to keep a usable path alive by swapping out weak participants for healthier ones, without asking the underlying IP routing to change. 7. Node Quality Metric (K-Factor) PSHMP Core evaluates nodes with a composite metric called K-Factor. Rather than looking at a single instantaneous measurement, K-Factor combines several signals into one stability score that is used both for selecting relays and for detecting degradation early. 7.1. Reference Formula In the experimental implementation the reference formula is: K = 0.45 * (1 - loss / 0.35) + 0.25 * (1 - jitter / 800) + 0.20 * (1 - rtt / 1200) + 0.10 * battery Figure 3 where: * loss is packet loss ratio in the range 0.0 .. 1.0 (clamped); * jitter is measured in milliseconds (clamped at the normalisation constant); * rtt is round-trip time in milliseconds (clamped); Kolomytsev Expires 7 March 2027 [Page 6] Internet-Draft PSHMP Core September 2026 * battery is an optional node-health indicator normalised to 0.0 .. 1.0 (for stationary nodes this term may be fixed at 1.0). Each term is clamped to the interval [0, 1] before weighting so that extreme values cannot dominate the score. The resulting K lies in approximately [0, 1]. The weights (0.45 / 0.25 / 0.20 / 0.10) and the normalisation constants (0.35, 800, 1200) are the reference values used in the current codebase. Integrators may change them to match their traffic patterns and topology; the architectural requirement is only that a continuous stability estimate drives selection and recovery decisions. 7.2. Status Bands The experimental implementation maps K to qualitative status bands: K >= 0.85 EXCELLENT – preferred for new chains 0.70 <= K < 0.85 GOOD – usable 0.55 <= K < 0.70 ACCEPTABLE – increased monitoring 0.40 <= K < 0.55 DEGRADED – prepare replacement K < 0.40 CRITICAL – exclude from new paths no recent data UNKNOWN – do not use Figure 4 These thresholds are configuration parameters, not protocol constants. A node whose K is still above the hard-failure line but is sliding downward can be scheduled for replacement before it becomes a hard failure. 7.3. Path / Candidate Scoring When ranking candidate relays for a new or replacement chain the implementation uses a weighted score of the form: Score = 0.50 * KScore + 0.25 * LatencyScore + 0.15 * LossScore + 0.10 * GeoScore Figure 5 Kolomytsev Expires 7 March 2027 [Page 7] Internet-Draft PSHMP Core September 2026 where each component is normalised to [0, 1]. KScore reflects closeness of the node’s K-Factor to the desired operating region; LatencyScore and LossScore penalise high delay and loss; GeoScore (or more generally a failure-domain diversity bonus) favours candidates that improve topological spread. Exact normalisation functions are implementation-defined. 8. Proactive Self-Healing Self-healing is organised around priorities. A complete node failure is treated as critical and handled immediately. Progressive degradation is classified according to how far the K-Factor has fallen: CRITICAL full failure – immediate HIGH K < 0.40 – ~5 s delay MEDIUM K < 0.55 – ~15 s delay LOW K < 0.68 – ~30 s delay Figure 6 Each class carries its own scheduling delay and an adaptive cooldown so that the system does not thrash when many nodes fluctuate near a threshold. The typical sequence is: 1. degradation is observed (K-Factor or reachability); 2. the condition is evaluated and prioritised; 3. alternative candidates are gathered from DHT and gossip; 4. a replacement path is constructed, diversity-checked, and validated; 5. traffic is moved onto the new path; 6. the old path is retired. Because the process starts from degradation rather than from total failure, the window of visible service impact can be shortened. Prototype measurements under simulated conditions have shown recovery behaviour on the order of hundreds of milliseconds; real-world figures depend on topology, load, and configuration. Kolomytsev Expires 7 March 2027 [Page 8] Internet-Draft PSHMP Core September 2026 9. Local Mesh Recovery When three or more nodes on the same chain are degraded, the system can activate local mesh recovery for that chain. The procedure roughly follows these steps: * mark the affected chain; * collect candidate relays from DHT and gossip, excluding recently failed or quarantined nodes; * apply a multi-level fallback ladder that gradually relaxes quality and diversity requirements; * run a quality gate before accepting the new path; * replace the old chain atomically. 9.1. Fallback Ladder The reference fallback levels used in the experimental implementation are: Level 0: MinAvgK >= 0.70, diversity required Level 1: MinAvgK >= 0.65, diversity required Level 2: MinAvgK >= 0.60, diversity required Level 3: MinAvgK >= 0.52, diversity required Level 4: MinAvgK >= 0.42, diversity optional Figure 7 Early levels insist on high average K-Factor and good spread across failure domains. Later levels accept lower quality or drop the diversity constraint, still preferring any working path over silence. The quality gate that follows construction prevents a clearly worse path from being installed simply because it is the only remaining option. 10. Diversity-Aware Selection Failures are often correlated. Nodes that share a rack, a site, a provider, or a network segment tend to suffer together. Selecting the highest-scoring individual nodes without regard to shared risk can therefore produce a new path that fails in the same way as the old one. Kolomytsev Expires 7 March 2027 [Page 9] Internet-Draft PSHMP Core September 2026 PSHMP Core can group nodes by logical failure domain (subnet, region, provider, availability zone, or any deployment-defined label). During recovery the selection logic prefers candidates from different groups. The preference is stronger when the network is already under stress and can be relaxed when healthy diversity is simply unavailable. 11. Failure Tracking and Quarantine A node that has just failed is a poor candidate for immediate re-use. PSHMP Core keeps a short history of failures and can place unstable nodes into a temporary quarantine. After a period of stable behaviour the node may be rehabilitated and allowed back into the candidate pool. This simple mechanism reduces the chance of repeated recovery loops caused by the same unreliable participants. 12. Decentralised Discovery and State Two complementary mechanisms keep the network informed. Gossip spreads node state, K-Factor updates, and chain proposals. It supports both push dissemination and anti-entropy pull synchronisation so that information continues to flow even when some links are lossy. Message types include node-state announcements, K-Factor updates, chain proposals, and explicit pull request/response pairs. A Kademlia-style DHT supplies candidate relays when a node needs fresh options, especially useful when a coordinator is unreachable. The DHT is treated as a discovery aid rather than a generic key-value store; the values that matter are node identity, reachability, and quality hints. Typical parameters in the experimental code are 160 buckets, bucket size k = 20, and concurrency parameter alpha = 3. An optional coordinator (which may itself run as a small Raft cluster) can provide stronger consistency for initial chain construction and global views. The architecture does not make the coordinator mandatory; local mesh recovery and DHT/gossip remain available when the coordinator is absent. 13. Data Delivery Path and Acknowledgement Model Reliable multi-hop delivery is handled by a dedicated DataPath component. Application data is segmented into chunks. Each chunk carries a sequence number. The sender transmits batches of chunks over the current relay chain. The receiver reports progress using batch acknowledgements that include an explicit gap list. Kolomytsev Expires 7 March 2027 [Page 10] Internet-Draft PSHMP Core September 2026 13.1. Delivery Flow (Conceptual) Application data | v Segment into chunks (sequence 1..N) | v Send batch over current relay chain | +-----> Relay 1 -----> Relay 2 -----> ... -----> Destination | v Receiver: update highest contiguous sequence record missing ranges as Gaps | v Batch ACK = { session, last_contiguous, gaps[], timestamp, MAC } | v Sender: retransmit only the missing sequences (from Retransmit Cache) Figure 8 13.2. Batch ACK Structure A Batch ACK carries: * session identifier; * highest contiguous sequence number received (LastReceived); * a list of missing ranges (Gaps), each described by a start and end sequence number; * timestamp and optional integrity protection (e.g., HMAC). Conceptually the set of sequences that still need retransmission is: Missing = (all sequences <= LastReceived that fall inside any Gap) union (sequences > LastReceived that were sent but not yet ACKed) Figure 9 Kolomytsev Expires 7 March 2027 [Page 11] Internet-Draft PSHMP Core September 2026 In practice the sender uses the gap list together with its outstanding-send window to decide exactly which chunks to retransmit. A short linger window (on the order of several hundred milliseconds in the reference implementation) allows late packets to arrive before gaps are declared, reducing unnecessary retransmissions. 13.3. Control Traffic Reduction Under the traffic patterns examined in internal tests, batch acknowledgements with gap lists have reduced control-plane overhead substantially (in favourable cases approaching the order of 75 % compared with per-packet ACKs). Actual savings depend on loss rate, batch size, and message size. The architectural gain is that the control channel stays light even when data volume is high. 14. Transport Abstraction The overlay is deliberately transport-agnostic. Implementations may run over UDP, DTLS, TLS-protected TCP, WebRTC DataChannels, or other bidirectional transports. TURN assistance can be used where NAT traversal is required. The choice of transport is an engineering decision for each deployment; the path-selection and recovery logic stays the same. 15. Security Considerations A decentralised relay system must assume that some participants may be malicious, misconfigured, or simply overloaded. The current design includes rate limiting, optional proof-of-work admission, authenticated and encrypted transport options (TLS/DTLS), HMAC- protected control messages, failure tracking, and temporary quarantine. These mechanisms are necessary but not sufficient. Deployments still need proper node identity, key management, authorisation policy, and operational monitoring. PSHMP Core is a resilience layer, not a complete security architecture. 16. Scalability Notes The architecture is intended to scale from small groups of nodes to several thousand participants. Distributed state (gossip), DHT-based discovery, optional sharding, and the ability to operate without a permanent central controller are the main tools. Large-scale network emulation with more than five thousand nodes has been used to exercise the implementation; those figures are experimental observations, not protocol guarantees. Real performance depends on topology, churn, and configuration. Kolomytsev Expires 7 March 2027 [Page 12] Internet-Draft PSHMP Core September 2026 17. Experimental Implementation An experimental implementation, PSHMP Core v3.1, has been written in Go. It contains the principal components described in this document: * Chain Relay and PathFinder; * K-Factor evaluation and adaptive probing; * Self-Healing Engine with priority scheduling and mesh state machine; * local mesh recovery with multi-level fallback and quality gate; * diversity-aware candidate selection; * Gossip (push and anti-entropy) and Kademlia-style DHT; * DataPath with batch acknowledgements and gap recovery; * optional Raft-based coordinator and sharding; * transport support including UDP, DTLS, and WebRTC; * Prometheus metrics and structured logging. The implementation has been exercised primarily through large-scale emulation and limited real-network experiments. It is positioned as a pilot-ready technology foundation rather than a finished mass- market product. Scoring weights, exact thresholds, and certain optimisations remain tunable by integrators. 18. Example Scenario Consider a six-relay chain: Source → A → B → C → D → E → Destination Figure 10 Relays B, C and D begin to show rising loss and falling K-Factor. The Self-Healing Engine marks the degradation, raises the priority, and triggers local mesh recovery for this chain. Candidates are gathered from DHT and gossip; recently failed nodes are excluded; diversity constraints prefer relays from different failure domains. A new sequence is assembled, passed through the quality gate, and installed: Kolomytsev Expires 7 March 2027 [Page 13] Internet-Draft PSHMP Core September 2026 Source → A → F → G → H → E → Destination Figure 11 The underlying IP routes are untouched. Only the logical overlay path has changed. Traffic continues with a shorter disruption window than a pure reactive failover would typically allow. 19. Potential Benefits When integrated into a larger platform, PSHMP Core can offer: * shorter recovery windows through proactive reconstruction; * continued delivery when individual relays or segments fail; * reduced dependence on any single path or controller; * lower control-plane overhead via batch acknowledgements; * reuse of existing IP infrastructure; * adaptive behaviour that tightens or relaxes constraints according to the severity of the failure. 20. Integration Model The expected use is as an embedded resilience layer inside an existing distributed system. The integrating organisation keeps ownership of application logic, identity, infrastructure, and commercial packaging. PSHMP Core supplies the adaptive multi-hop delivery and recovery machinery underneath. 21. Deployment Considerations Before wide deployment an organisation should examine topology density, expected loss and latency, failure-domain layout, security and identity requirements, monitoring, and capacity. Controlled pilot deployments remain the practical way to validate behaviour under real traffic. The formulas and thresholds given in this document are a starting point; they should be calibrated against the target network. 22. Design Principles * Decentralisation — discovery and recovery must continue when a central component is unavailable. Kolomytsev Expires 7 March 2027 [Page 14] Internet-Draft PSHMP Core September 2026 * Proactive recovery — degradation is a signal, not merely a post- mortem. * Dynamic paths — delivery routes adapt to changing conditions. * Diversity — correlated failures are treated as a first-class risk. * Layer independence — the overlay does not require changes to L3 routing. * Graceful degradation — when ideal candidates are scarce, constraints are relaxed progressively rather than failing abruptly. 23. Limitations PSHMP Core cannot create connectivity where none exists. Performance depends on the number and quality of available relays, the underlying network, workload, and configuration. Figures obtained from emulation or limited trials must be re-validated for each production environment. The reference formulas are part of the experimental model; production deployments may adjust weights and thresholds. 24. IANA Considerations This document has no IANA actions. 25. Terminology 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: a composite stability metric used for selection and early degradation detection. Self-healing: automatic reconstruction of degraded delivery paths. Local mesh recovery: path reconstruction performed for an affected chain using alternative candidates, fallback levels, and a quality gate. Diversity: preference for relays drawn from different failure domains. Kolomytsev Expires 7 March 2027 [Page 15] Internet-Draft PSHMP Core September 2026 Gossip: decentralised dissemination of node and path state. DHT: distributed mechanism used primarily for candidate discovery. Gap list: explicit list of missing sequence ranges reported in a batch acknowledgement. DataPath: component responsible for chunking, transmission over a relay chain, batch acknowledgements, and retransmission of missing sequences. 26. Conclusion PSHMP Core offers a practical hybrid overlay for environments where connectivity is imperfect and recovery time matters. Linear chains keep the common case simple; local mesh recovery, K-Factor-driven decisions, diversity awareness, and efficient acknowledgements provide the machinery needed when conditions worsen. The design deliberately stays above IP, remains transport-flexible, and can operate with or without a central coordinator. An experimental Go implementation (v3.1) demonstrates that the architecture is realisable and has been exercised at significant scale in emulation. Reference formulas for K-Factor, candidate scoring, the recovery fallback ladder, and the batch-acknowledgement delivery model are provided so that readers can understand the concrete model; integrators remain free to tune weights and thresholds to their own networks. PSHMP Core is offered as a technology foundation for organisations that need resilient multi-hop delivery and are prepared to evaluate, tune, and integrate it within their own platforms. 27. 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, . Kolomytsev Expires 7 March 2027 [Page 16] Internet-Draft PSHMP Core September 2026 Author's Address Alexander Kolomytsev Independent Researcher Email: giro.pandemik@gmail.com Kolomytsev Expires 7 March 2027 [Page 17]