TSVWG F. Yang Internet-Draft X. Zhang Intended status: Standards Track China Mobile Expires: 25 April 2027 22 October 2026 TCP Connectivity Probing Extension for Highly-Dynamic Networks draft-yang-tsvwg-tcp-oam-probing-00 Abstract This document defines TCP OAM-ACK, a TCP extension for fast transport-layer connectivity detection in highly-dynamic networks such as LEO satellite constellations, high-speed rail, and ad-hoc intelligent agent networks. Traditional TCP keep-alive uses fixed long probe intervals and cannot rapidly differentiate genuine link outages from congestion-induced packet loss. TCP OAM-ACK negotiates capability via TCP SYN/SYN-ACK handshake using shared experimental TCP option [RFC6994]. A sender adaptively shortens probing interval upon consecutive probe ACK losses, triggers path-switching notifications to external path-control entities instead of mis-invoking TCP congestion window reduction. This mechanism acts like transport-layer BFD for TCP connections. This document describes option formats, sender/receiver behavior, fallback strategies, RTT-assisted early triggering, and interaction with path management modules. 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 25 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Yang & Zhang Expires 25 April 2027 [Page 1] Internet-Draft TCP, ACK，Highly-Dynamic October 2026 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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 3. TCP OAM-ACK Overview . . . . . . . . . . . . . . . . . . . . 4 4. TCP OAM-ACK Option Formats . . . . . . . . . . . . . . . . . 5 4.1. Capability-Announcement Format (SYN/SYN-ACK segments) . . 5 4.2. OAM-ACK Probe Data Format . . . . . . . . . . . . . . . . 6 5. Protocol Behaviors . . . . . . . . . . . . . . . . . . . . . 6 5.1. Handshake Capability Negotiation . . . . . . . . . . . . 6 5.2. Fallback and Re-negotiation Rules . . . . . . . . . . . . 7 5.3. Sender Behavior . . . . . . . . . . . . . . . . . . . . . 7 5.4. Receiver Behavior . . . . . . . . . . . . . . . . . . . . 8 5.5. Multi-dimensional Connectivity Judgement . . . . . . . . 8 5.6. Interaction with Path-switching Control Entity . . . . . 9 5.7. Event-triggered Probing Activation . . . . . . . . . . . 9 6. IP Precedence Treatment for OAM-ACK Probes . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Highly-dynamic networks such as LEO satellite constellations, high-speed-rail mobile scenarios, and UAV ad-hoc networks exhibit frequent topology changes and link handovers. When link handover happens, transient packet loss occurs. Standard TCP misinterprets this non-congestion loss as network congestion and unnecessarily shrinks congestion window (cwnd), leading to degraded throughput. Traditional TCP keep-alive [RFC9293] uses fixed, long probe intervals(order of minutes by default). It cannot achieve fast connectivity detection comparable to BFD [RFC5880] at transport layer. Yang & Zhang Expires 25 April 2027 [Page 2] Internet-Draft TCP, ACK，Highly-Dynamic October 2026 This document specifies TCP OAM-ACK: a lightweight TCP OAM probing extension. The key innovation is adaptive probe-interval adjustment: when consecutive probe acknowledgements are missing, the sender reduces its own probing interval to accelerate link-failure discovery. Upon detecting link outage, the sender notifies an external path-switching control entity rather than invoking TCP congestion control. TCP OAM-ACK uses shared experimental TCP option format defined in [RFC6994], negotiates capability during three-way handshake. If negotiation fails, endpoints fall back to legacy TCP behaviors. Re-negotiation is supported after link handover events. TCP OAM-ACK is complementary, not competitive, to other TCP extensions. For example, it can coexist with TARR [I-D.ietf-tcpm-ack-rate-request-12], which controls receiver-side ACK generation frequency for data-flow optimization, while OAM-ACK focuses on independent connectivity probing. This document is informational; it does not define any standards-track normative requirements for general Internet deployment. It targets specialized highly-dynamic network environments. 1.1. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Terminology * OAM-ACK: TCP OAM-ACK extension defined by this document. * Probe Segment: Zero-payload TCP segment carrying OAM-ACK probe option, used for connectivity measurement. * Probe ACK: Acknowledgement returned by receiver for received OAM-ACK probe. * Control Entity: External path-management component (e.g. route reflector, satellite ground control path module) responsible for candidate-path switching. * Handover: Link/path change event in highly-dynamic networks. Yang & Zhang Expires 25 April 2027 [Page 3] Internet-Draft TCP, ACK，Highly-Dynamic October 2026 * T_init: Initial probe interval for OAM-ACK probing. * T_min: Hard minimum probing interval threshold. 2. Problem Statement In highly-dynamic satellite and mobile networks: 1. Link handover produces packet loss that is not caused by congestion. Standard TCP treats all loss as congestion loss and reduces cwnd, which hurts performance. 2. Legacy TCP keep-alive uses static long intervals, cannot detect link outage rapidly. There lacks a transport-layer mechanism similar to BFD for fast connectivity verification. 3. Existing TCP extensions such as TARR focus on optimizing ACK generation for user data traffic, they do NOT provide independent OAM connectivity-probing function. 4. After path handover, existing TCP has no built-in signal to trigger re-negotiation of transport-extension capabilities. Current mechanisms cannot differentiate "congestion loss" vs "genuine link outage" fast enough for high-dynamic use-cases. This document addresses those gaps. 3. TCP OAM-ACK Overview TCP OAM-ACK operates as follows: 1. During TCP three-way handshake: SYN/SYN-ACK segments carry OAM-ACK capability-announcement experimental TCP option. Both endpoints declare support. If peer does not reply with corresponding option, OAM-ACK negotiation fails and endpoints fall-back to legacy TCP. 2. After successful negotiation, sender sends zero-payload OAM-ACK probe segments with an initial interval T_init. Probe segments carry timestamp information for RTT calculation. 3. Upon consecutive missing probe-ACK responses (N consecutive losses), sender adaptively SHORTENS its own probe sending interval. Example heuristic: T_init=200ms; after N losses → T = T_init/2; after further M losses → T = T_init/4, bounded by T_min (e.g. 20 ms). Yang & Zhang Expires 25 April 2027 [Page 4] Internet-Draft TCP, ACK，Highly-Dynamic October 2026 4. Multi-dimensional judgement: When cumulative missing-probe counter reaches threshold AND probe interval already hits T_min, sender determines non-congestion-induced link outage. 5. On link-outage judgement: sender sends notification to external path-control entity to trigger candidate-path switch, rather than triggering TCP congestion-window reduction. If zero candidate-path remains, sender sends RST and notifies application layer. 6. After path handover event, sender MAY perform OAM-ACK re-negotiation using data-carrying TCP segments. 7. Optional trigger: probing MAY be activated conditionally when TCP/IP layer observes packet-loss exceeding configured threshold to save bandwidth resource. 8. Receiver behavior: upon receiving valid OAM-ACK probe, receiver MUST reply corresponding ACK with timestamp echo; receiver does NOT modify its native TCP delayed-ACK policy. 4. TCP OAM-ACK Option Formats OAM-ACK uses shared experimental TCP option format defined in [RFC6994], Kind = TBD, ExID = TBD (to be assigned by IANA experimental-option registry). Two distinct formats are differentiated by Length field. 4.1. Capability-Announcement Format (SYN/SYN-ACK segments) Used in SYN and SYN-ACK to advertise OAM-ACK capability. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kind=254 | Length=4 | ExID (2 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: OAM-ACK Capability Announcement * Kind: 1 octet, value 254 (shared experimental option [RFC6994]) * Length: 1 octet, value = 4 * ExID: 2 octets network byte-order experimental identifier, TBD. When sending SYN, sender includes this option to advertise OAM-ACK support. If receiver supports OAM-ACK, it MUST include exactly same capability-announcement option inside its SYN-ACK response. Absence means peer does NOT support OAM-ACK extension. Yang & Zhang Expires 25 April 2027 [Page 5] Internet-Draft TCP, ACK，Highly-Dynamic October 2026 4.2. OAM-ACK Probe Data Format Carried inside probe segments (zero-payload data-phase segments). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kind=254 | Length=12 | ExID (2 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TimeInt (Probe Interval) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSval (Sender Timestamp) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSecr (Echo Timestamp) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: OAM-ACK Probe-Data Option * Kind: 1 octet, value 254 * Length: 1 octet, value = 12 * ExID: 2 octets, network byte-order, assigned experimental ID (TBD) * TimeInt (4 octets): Current probe interval used by sender (unit: millisecond) * TSval (4 octets): Sender timestamp when this probe segment is transmitted. * TSecr (4 octets): Echo of timestamp value received from peer's last valid probe-ACK. Receiver returns ACK segment, also carrying OAM-ACK probe-data option: TSval is receiver's current timestamp; TSecr echoes TSval extracted from incoming OAM-ACK probe segment. 5. Protocol Behaviors 5.1. Handshake Capability Negotiation Client: - When transmitting SYN segment, client MAY include OAM-ACK capability-announcement option (Length=4). Server: - If server supports OAM-ACK, server MUST embed capability-announcement option inside SYN-ACK reply. - If server does NOT support OAM-ACK, SYN-ACK MUST NOT carry this option. Client receiving SYN-ACK: 1. If SYN-ACK contains matching OAM-ACK capability-announcement option: OAM-ACK negotiation succeeds; OAM-ACK probing MAY be activated in data phase. 2. If SYN-ACK lacks OAM-ACK capability-announcement option: negotiation fails, client MUST disable OAM-ACK probing and fall-back to legacy TCP. After three-way handshake completes, both sides know whether OAM-ACK is enabled for this TCP connection. Yang & Zhang Expires 25 April 2027 [Page 6] Internet-Draft TCP, ACK，Highly-Dynamic October 2026 5.2. Fallback and Re-negotiation Rules Negotiation-failure fallback: When OAM-ACK capability negotiation fails during handshake: 1) Sender MUST NOT send any OAM-ACK probe segments. 2) Connection uses legacy TCP ACK and legacy TCP keep-alive mechanisms. 3) Sender MAY attempt re-negotiation periodically (e.g. every 30 seconds) in data-phase TCP segments, until negotiation succeeds or connection closes. Re-negotiation after link-handover event: After detecting link-path handover event (e.g. satellite beam switching), sender MAY initiate OAM-ACK re-negotiation by embedding OAM-ACK probe-data option in ordinary data-carrying TCP segment. - If receiver supports OAM-ACK, receiver replies ACK carrying valid OAM-ACK option; re-negotiation succeeds. - If receiver does not reply valid OAM-ACK option, re-negotiation fails, fall-back to legacy TCP behavior. 5.3. Sender Behavior When OAM-ACK negotiation succeeds: 1. Sender maintains state variables: * ProbeInterval: current probe sending interval (initialized to T_init). * MissCounter: count of consecutive probes without receiving probe-ACK. * T_min: minimum allowed probe interval (implementation configurable). * rtt_sample: RTT value computed from probe-ACK replies. 2. Sender transmits zero-payload TCP probe segments every ProbeInterval. Each probe segment includes OAM-ACK probe-data option described in 5.2. 3. For each transmitted probe: a) If corresponding probe-ACK arrives before timeout: * Compute RTT = current_system_time − TSval echoed inside TSecr field. * Reset MissCounter to zero. ProbeInterval remains unchanged. b) If timeout occurs without receiving probe-ACK: * Increment MissCounter by one. Yang & Zhang Expires 25 April 2027 [Page 7] Internet-Draft TCP, ACK，Highly-Dynamic October 2026 * When MissCounter reaches configured threshold N: - Reduce ProbeInterval (example heuristic: halve interval). - Reset MissCounter to zero. - ProbeInterval MUST NOT drop below T_min. 4. RTT-ahead early-trigger rule (OPTIONAL): When multiple successive RTT samples show RTT growth exceeding configured threshold AND no probe-ACK returns, sender MAY skip one-step interval-reduction and directly set ProbeInterval to T_min to accelerate outage detection. 5. Duplicate-ACK exclusion rule: If sender receives duplicate-ACK (Dup-ACK) from receiver, this indicates partial reachability. Sender MUST NOT increase MissCounter and MUST NOT trigger probe-interval shortening. Only complete absence of any ACK reply triggers miss-count accumulation. 5.4. Receiver Behavior Receiver that supports OAM-ACK: 1. Upon receiving TCP segment carrying valid OAM-ACK probe-data option: a) Receiver MUST generate ACK response for this segment. b) ACK segment includes OAM-ACK probe-data option: TSval filled with receiver-local timestamp; TSecr echoes TSval value taken from incoming probe segment. 2. Receiver does NOT modify native TCP delayed-ACK, SACK or other standard TCP ACK generation logics. OAM-ACK only adds reply action for incoming OAM-ACK probe segments; receiver will NOT change ACK-generation strategy for regular user-data segments. 3. If OAM-ACK option is received but OAM-ACK capability was never negotiated for this connection, receiver MUST silently ignore OAM-ACK option and process rest of TCP segment normally. 5.5. Multi-dimensional Connectivity Judgement Sender judges link outage condition when BOTH two conditions hold: 1) Cumulative miss counter reaches pre-configured outage threshold; 2) Current ProbeInterval has already decreased down to T_min. When judged as genuine non-congestion link outage: - Sender MUST NOT trigger standard TCP congestion-control cwnd reduction. Yang & Zhang Expires 25 April 2027 [Page 8] Internet-Draft TCP, ACK，Highly-Dynamic October 2026 This differentiation is critical for high-dynamic satellite/mobile scenarios: transient handover loss should not be treated as congestion. 5.6. Interaction with Path-switching Control Entity Once sender determines link outage: 1. Sender sends notification message to external path-switching control entity. Notification information MAY contain: path identifier, outage timestamp, history RTT samples. 2. Control entity performs candidate-path selection and triggers new-path setup. After new-path ready, control entity informs TCP sender. Sender restores ProbeInterval back to initial value T_init and resumes OAM-ACK probing on new path. Re-negotiation MAY be performed on new path. 3. If NO usable candidate-path exists: Sender sends TCP RST segment to terminate connection and delivers network-unreachable indication to upper application layer. 5.7. Event-triggered Probing Activation As an optimization to conserve network bandwidth resource: OAM-ACK probing does NOT need to run perpetually. Sender MAY activate OAM-ACK probing only when TCP/IP layer detects packet-loss ratio exceeding configurable threshold. After connectivity recovers, sender MAY suspend OAM-ACK probing. 6. IP Precedence Treatment for OAM-ACK Probes OAM-ACK probe segments MAY be marked with high-priority value inside IP precedence/DSCP field. User-data segments use ordinary or lower priority. This improves probe survival probability on lossy dynamic links. Implementation note: network-middleboxes SHOULD respect marking for OAM-ACK probes. This is a RECOMMENDED but not mandatory behaviour. 7. Security Considerations TBD Yang & Zhang Expires 25 April 2027 [Page 9] Internet-Draft TCP, ACK，Highly-Dynamic October 2026 8. IANA Considerations This document defines new TCP experimental option using shared experimental option format from [RFC6994]. Request IANA assign an ExID value from the TCP Experimental Option Experiment-ID registry for OAM-ACK. No other registry actions required at this moment. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC6994] Touch, J., "Shared Use of Experimental TCP Options", RFC 6994, DOI 10.17487/RFC6994, August 2013, . [RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022, . 9.2. Informative References [I-D.draft_ietf_tcpm_ack_rate_request_12] "*** BROKEN REFERENCE ***". Authors' Addresses Feng Yang China Mobile China Email: yangfeng@chinamobile.com Xiaoqiu Zhang China Mobile China Email: zhangxiaoqiu@chinamobile.com Yang & Zhang Expires 25 April 2027 [Page 10]