LeoTCP: LEO Satellite Congestion Protocol

• LeoTCP is a specialized TCP-based protocol for LEO satellite networks that uses per-hop in-network telemetry to maintain low latency and high throughput.
• It integrates explicit telemetry feedback with AIMD-based congestion control to dynamically adjust to rapid RTT changes and transient network hotspots.
• Evaluation reveals that LeoTCP achieves near-optimal performance and fairness, minimizing delay inflation while maintaining approximately 95% link utilization.

LeoTCP is a congestion-control and transport protocol built on TCP specifically for Low-Earth Orbit (LEO) satellite networks. It uses per-hop in-network telemetry (INT) to keep queues almost empty, maintain low latency, and still achieve high throughput under fast-changing round-trip times (RTTs), transient hotspots, and frequent handovers. Built on TCP with SACK, timestamps, and RACK loss detection, it replaces loss-triggered congestion control with INT-driven control and explicitly targets a link utilisation of approximately $95\%$ (Valentine et al., 26 Aug 2025).

1. Problem domain and design rationale

LEO constellations such as Starlink, Kuiper, and OneWeb consist of thousands of fast-moving satellites, approximately $7.5\ \text{km/s}$ at approximately $550\ \text{km}$, forming a dynamic mesh. In that environment, propagation delay varies rapidly, routing and handovers are frequent, transient hotspots arise on popular routes, and non-congestive latency variation and loss occur because of weather effects, beam switching, link-level rate adaptation, and path reconfiguration. These properties differ materially from terrestrial networks, where RTTs and bottlenecks are comparatively stable, and from GEO systems, where RTT is high but relatively stationary (Valentine et al., 26 Aug 2025).

Traditional TCP variants and modern congestion-control schemes are described as poorly matched to these dynamics. Loss-based protocols such as Cubic fill queues to detect loss and treat non-congestive loss as congestion; delay- and model-based protocols such as BBRv1 and BBRv3 depend on RTT and bandwidth estimates updated via periodic probing, adapt too slowly to abrupt path changes, and exhibit RTT unfairness. LeoTCP is therefore designed around explicit congestion visibility from the network rather than inference from loss or end-host RTT alone (Valentine et al., 26 Aug 2025).

A broader emulation-driven study of congestion control in LEO constellations reinforces that design premise. It reports that handover-aware loss-based schemes can reclaim bandwidth but at the cost of increased latency, that BBRv3 sustains high throughput with modest delay penalties yet reacts slowly to abrupt RTT changes, and that reinforcement-learning-based schemes are notably resistant to non-congestive loss but severely underperform under dynamic conditions. This wider context suggests that LEO transport requires mechanisms that separate congestion from orbital and handover dynamics rather than treating all RTT change or loss as queue growth (Mazilu et al., 29 Oct 2025).

2. Protocol architecture and telemetry model

LeoTCP has three principal components: a sender that maintains the congestion window $cwnd$ and injects INT headers into every outgoing TCP packet; a receiver that extracts INT information and echoes key fields in ACKs; and switches or routers, including satellites and ground stations, that append per-hop telemetry into INT headers (Valentine et al., 26 Aug 2025).

The sender inserts three fields into the INT header: $pathID$, $baseRTT$, and $cwnd$. The switches append per-hop state including departure timestamp $ts$, outgoing-link bandwidth $bw$, queue length at departure $qLen$, queue length at arrival $7.5\ \text{km/s}$0, cumulative transmitted bytes $7.5\ \text{km/s}$1, per-hop average RTT $7.5\ \text{km/s}$2, and estimated number of active LeoTCP flows $7.5\ \text{km/s}$3. The receiver can optionally echo back only the bottleneck hop’s telemetry, defined as the hop with the highest estimated utilisation, to reduce feedback size (Valentine et al., 26 Aug 2025).

Two switch-side quantities are central. The first is $7.5\ \text{km/s}$4, the average RTT of flows traversing an output interface. Switches derive it from sender-supplied $7.5\ \text{km/s}$5 and $7.5\ \text{km/s}$6 using weighted aggregates of $7.5\ \text{km/s}$7 and $7.5\ \text{km/s}$8, recomputed periodically by a timer approximately equal to the latest $7.5\ \text{km/s}$9. The second is $550\ \text{km}$0, the number of active flows sharing an interface, tracked using the TCP four-tuple. The paper describes this design as stateless per flow and implementable in P4 (Valentine et al., 26 Aug 2025).

Path-change detection is embedded directly into the telemetry path. At each hop, the switch updates the path identifier as

$550\ \text{km}$1

so the final value encodes the exact route taken. This enables the sender to distinguish telemetry from a new path from stale telemetry associated with a previous route (Valentine et al., 26 Aug 2025).

3. Congestion-control law

LeoTCP uses AIMD with per-RTT window referencing and per-ACK congestion reaction. At the start of each smoothed RTT $550\ \text{km}$2, the sender stores a reference window $550\ \text{km}$3. Additive increase is applied once per $550\ \text{km}$4, while multiplicative decrease can be triggered on every ACK when utilisation indicates overuse. Packet pacing is explicit: $550\ \text{km}$5 The protocol therefore combines a window-based controller with paced transmission (Valentine et al., 26 Aug 2025).

Per-hop utilisation is computed from INT feedback. For hop $550\ \text{km}$6,

$550\ \text{km}$7

with

$550\ \text{km}$8

The sender selects the hop with maximum $550\ \text{km}$9 as the bottleneck and maintains an EWMA of that bottleneck utilisation $cwnd$0. In this formulation, $cwnd$1 denotes a fully utilized link with stable queues, $cwnd$2 denotes overutilization and queue growth, and $cwnd$3 denotes underutilization and queue drain (Valentine et al., 26 Aug 2025).

A distinctive part of LeoTCP is its decoupling of propagation delay from queueing delay. For each hop,

$cwnd$4

and over the path,

$cwnd$5

The sender then estimates

$cwnd$6

smooths that estimate with EWMA, and reinserts it into outgoing INT headers. Switches use $cwnd$7, not full RTT, to compute $cwnd$8. This prevents queue-induced RTT inflation from feeding back into BDP estimation and further inflating $cwnd$9 (Valentine et al., 26 Aug 2025).

The additive-increase term targets $pathID$0: $pathID$1 Here, $pathID$2 approximates the per-flow BDP if the flow owned the full bottleneck, division by $pathID$3 yields the per-flow share, and multiplication by $pathID$4 increases the window by $pathID$5 of that share per RTT. Window update is then

$pathID$6

Thus, under target utilisation the window grows gradually; above target utilisation it is scaled down by $pathID$7 and then incremented by $pathID$8 (Valentine et al., 26 Aug 2025).

LeoTCP also defines an initial phase for new flows. After transmitting a small number of packets to gather INT, the sender waits for one $pathID$9 before changing $baseRTT$0, allowing switch-side $baseRTT$1 to stabilize. During this initial phase only, $baseRTT$2 is set to approximately $baseRTT$3 of bottleneck BDP divided by $baseRTT$4, rather than $baseRTT$5, enabling rapid convergence to fair share with only modest extra queueing (Valentine et al., 26 Aug 2025).

4. Handling loss, hotspots, path changes, and handovers

LeoTCP is explicitly designed not to treat loss as a congestion signal. Loss recovery remains in TCP via SACK and RACK, but congestion decisions are driven solely by INT-derived queue lengths, transmission rates, utilisation, and path information. This is meant to prevent unnecessary multiplicative decrease under rain fade, link adaptation, beam switching, and handover-induced loss, all of which can occur even when buffers are not building (Valentine et al., 26 Aug 2025).

Transient hotspots are handled through immediate visibility into the bottleneck interface. Because INT supplies $baseRTT$6, $baseRTT$7, $baseRTT$8, and $baseRTT$9, the sender can estimate overutilization as soon as queues begin to grow and cut $cwnd$0 proportionally to $cwnd$1. The use of a $cwnd$2 target means LeoTCP operates below full saturation by design, minimizing standing queues while preserving high utilisation (Valentine et al., 26 Aug 2025).

Path changes are identified through $cwnd$3 mismatches. To avoid false reactions to reordering, LeoTCP reacts to such mismatches only once per $cwnd$4. INT timestamps allow the sender to discard stale telemetry from packets that traversed an old path, prioritize ACKs from the new path, and recompute control decisions from the new bottleneck’s $cwnd$5, $cwnd$6, and $cwnd$7. The protocol therefore treats route changes as direct changes in congestion state rather than as ambiguous variations in end-host RTT (Valentine et al., 26 Aug 2025).

The same machinery governs soft and hard handovers. Soft handovers may produce path changes and packet reordering without necessarily causing loss; hard handovers cause temporary disconnection, on the order of $cwnd$8–$cwnd$9, and loss of in-flight packets. LeoTCP does not shrink $ts$0 in response to loss itself. Once connectivity resumes, it continues sending at the pre-handover rate and then adapts $ts$1 using INT from the new path, while RACK and SACK recover the missing data (Valentine et al., 26 Aug 2025).

5. Evaluation methodology and observed behavior

LeoTCP is evaluated in OMNeT++ with the INET framework using a Starlink first-shell simulation model integrated with inter-satellite links and bent-pipe links. Paths are updated every $ts$2 to emulate dynamic connectivity and RTT changes, the model contains $ts$3 ground-station locations, and baseline experiments use $ts$4 links. Buffers are typically set to $ts$5 BDP of the longest-RTT path in the experiment, with some tests varying the buffer to $ts$6, $ts$7, and $ts$8 BDP. Targeted micro-benchmarks isolate non-congestive latency variation and loss, path changes, congestion hotspots, parking-lot multi-bottleneck effects, inter-RTT and intra-RTT fairness, and soft and hard handovers (Valentine et al., 26 Aug 2025).

In the responsiveness experiment, where bottleneck bandwidth and base RTT change every $ts$9 with bandwidth in $bw$0 and RTT in $bw$1, LeoTCP achieves goodput close to the “optimal achievable throughput” line and keeps RTT close to base RTT with almost no inflation. It also maintains this behavior under non-congestive loss. By contrast, Cubic attains high throughput without loss but inflates RTT significantly because buffers fill; under random non-congestive loss, its goodput collapses. BBRv1 underutilizes bandwidth because it adapts too slowly, while BBRv3 performs better than BBRv1 but still loses goodput under non-congestive loss (Valentine et al., 26 Aug 2025).

Fairness results are similarly central. For two flows sharing the same dynamic LEO path, LeoTCP attains an excellent goodput ratio of approximately $bw$2 or more with minimal delay inflation of approximately $bw$3. Inter-RTT experiments show that LeoTCP’s goodput ratio remains approximately $bw$4 across RTT differences, whereas Cubic exhibits strong low-RTT bias and BBR variants favor larger RTTs through larger in-flight volumes. In parking-lot topologies, LeoTCP approximates max-min fairness rather than the proportional-fairness tendency reported for Cubic and BBR variants (Valentine et al., 26 Aug 2025).

Under soft handovers, LeoTCP keeps RTTs very close to path base RTTs: $bw$5 on a $bw$6 path and $bw$7 on a $bw$8 path. Under hard handovers with disruption durations between $bw$9 and $qLen$0, it quickly resumes the pre-disruption sending rate and maintains high goodput, whereas Cubic’s repeated multiplicative decreases and BBR’s probe-cycle interactions reduce delivered throughput (Valentine et al., 26 Aug 2025).

Two internal design choices are evaluated directly. Without the $qLen$1 mechanism, LeoTCP shows significant inter-RTT unfairness; with $qLen$2, goodput ratios approach $qLen$3 regardless of differing RTTs. Without the initial phase, late-starting flows require many RTTs to reach fair share. With the initial phase, convergence is much faster, while extra queueing remains modest: the initial $qLen$4 flows’ RTT rises from approximately $qLen$5 to approximately $qLen$6 early on, and the later $qLen$7 flows’ arrival increases existing flows’ RTT only slightly, from approximately $qLen$8 to approximately $qLen$9 (Valentine et al., 26 Aug 2025).

6. Relationship to adjacent work, assumptions, and limitations

LeoTCP differs from Cubic, BBR, SaTCP, and StarQUIC at the level of congestion signaling rather than only at the level of handover heuristics. Cubic is loss-based and queue-filling; BBR is model-based and probe-driven; SaTCP and StarQUIC mainly add handover-aware behavior while retaining the underlying Cubic or BBR dynamics. LeoTCP instead uses explicit per-hop telemetry, per-bottleneck $7.5\ \text{km/s}$00, per-interface $7.5\ \text{km/s}$01, and path-aware INT feedback to drive AIMD directly (Valentine et al., 26 Aug 2025).

The larger LEO congestion-control literature makes the contrast sharper. An emulation-driven evaluation across loss-based, model-based, and learning-based schemes reports that fairness degrades significantly with RTT asymmetry and multiple bottlenecks, especially in human-designed congestion control schemes, while AQM at bottlenecks can restore fairness and boost efficiency. It also finds that learning-based schemes are resistant to non-congestive loss but perform poorly under dynamic LEO conditions because they mis-handle non-stationary RTT and capacity dynamics. These findings clarify the problem class LeoTCP addresses: not merely bandwidth estimation, but the separation of congestion from orbital and handover dynamics (Mazilu et al., 29 Oct 2025).

LeoTCP’s assumptions are non-trivial. It requires INT-capable satellites and ground-station switches, for example via P4-programmable data planes; per-packet telemetry introduces header overhead and processing cost; the evaluation focuses on Starlink-like constellations, $7.5\ \text{km/s}$02 links, and specific buffer-sizing heuristics; the current receiver design assumes INT is echoed back as-is; and the paper does not deeply discuss telemetry authentication, spoofing resistance, or privacy implications. The paper also identifies scalability, telemetry compression or sampling, extension beyond LEO to MEO, GEO, mobile terrestrial wireless, or WAN settings, and tighter coordination with LEO routing and scheduling as open directions (Valentine et al., 26 Aug 2025).

A potential naming ambiguity is that LeoTCP is unrelated to “Leo: Lagrange Elementary Optimization,” a GA-style, bio-inspired metaheuristic for single-objective continuous global optimization. The shared prefix “Leo” refers to distinct works in unrelated domains: satellite transport in one case, evolutionary optimization in the other (Aladdin et al., 2023).