TCP Connectivity Probing Extension for Highly‑Dynamic Networks

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 uses fixed, long probe intervals(order of minutes by default). It cannot achieve fast connectivity detection comparable to BFD [RFC5880] at transport layer. 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 , 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.

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 when, and only when, they appear in all capitals, as shown here.

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.
T_init: Initial probe interval for OAM‑ACK probing.
T_min: Hard minimum probing interval threshold.

Problem Statement In highly‑dynamic satellite and mobile networks:

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.
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.
Existing TCP extensions such as TARR focus on optimizing ACK generation for user data traffic, they do NOT provide independent OAM connectivity‑probing function.
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.

TCP OAM‑ACK Overview TCP OAM‑ACK operates as follows:

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.
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.
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).
Multi‑dimensional judgement: When cumulative missing‑probe counter reaches threshold AND probe interval already hits T_min, sender determines non‑congestion‑induced link outage.
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.
After path handover event, sender MAY perform OAM‑ACK re‑negotiation using data‑carrying TCP segments.
Optional trigger: probing MAY be activated conditionally when TCP/IP layer observes packet‑loss exceeding configured threshold to save bandwidth resource.
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.

TCP OAM‑ACK Option Formats OAM‑ACK uses shared experimental TCP option format defined in , Kind = TBD, ExID = TBD (to be assigned by IANA experimental‑option registry). Two distinct formats are differentiated by Length field.

Capability‑Announcement Format (SYN/SYN‑ACK segments) Used in SYN and SYN‑ACK to advertise OAM‑ACK capability.

Kind: 1 octet, value 254 (shared experimental option )
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.

OAM‑ACK Probe Data Format Carried inside probe segments (zero‑payload data‑phase segments).

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.

Protocol Behaviors

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.

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.

Sender Behavior When OAM‑ACK negotiation succeeds:

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.
Sender transmits zero‑payload TCP probe segments every ProbeInterval. Each probe segment includes OAM‑ACK probe‑data option described in 5.2.
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.
- When MissCounter reaches configured threshold N:
  - Reduce ProbeInterval (example heuristic: halve interval).
  - Reset MissCounter to zero.
  - ProbeInterval MUST NOT drop below T_min.
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.
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.

Receiver Behavior Receiver that supports OAM‑ACK:

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

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. This differentiation is critical for high‑dynamic satellite/mobile scenarios: transient handover loss should not be treated as congestion.

Interaction with Path‑switching Control Entity Once sender determines link outage:

Sender sends notification message to external path‑switching control entity. Notification information MAY contain: path identifier, outage timestamp, history RTT samples.
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.
If NO usable candidate‑path exists: Sender sends TCP RST segment to terminate connection and delivers network‑unreachable indication to upper application layer.

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.

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.

Security Considerations TBD

IANA Considerations This document defines new TCP experimental option using shared experimental option format from . 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.