Acceleration, and what it breaks

Satellite networks commonly include acceleration — a performance enhancing proxy that terminates TCP at each end and runs an optimised protocol across the space segment. It works: throughput improves substantially. It also changes the network in ways that matter when something goes wrong.

What it does

The proxy answers on behalf of the far end, acknowledging data locally so the sender’s window opens immediately instead of waiting a round trip. Across the satellite it uses a protocol designed for high latency. At the far end another proxy reconstructs the TCP session.

The end hosts believe they have a direct connection. They do not.

What it breaks

End-to-end encryption. The proxy cannot accelerate what it cannot read. IPsec or a TLS-wrapped tunnel passes through unaccelerated, and performance collapses to unaccelerated TCP. Organisations frequently deploy a VPN over an accelerated link and cannot understand why throughput is a fraction of what was demonstrated.

Diagnosis. A capture at one end does not show the other end’s behaviour. Round-trip times are locally spoofed. Retransmissions are hidden. Sequence numbers do not correspond across the link. Standard TCP analysis produces conclusions that are simply wrong.

Failure modes. When the proxy is under pressure, sessions fail in ways that look like network faults but are not.

Working with it

Know whether acceleration is present before diagnosing anything. Capture at both ends and compare rather than reasoning from one side. When testing raw link performance, test something the accelerator cannot touch — UDP, or encrypted traffic — to see what the space segment really delivers.

iperf3 -c far-end -u -b 10M       # UDP: bypasses TCP acceleration
iperf3 -c far-end                  # TCP: shows the accelerated result

The gap between those two numbers is the accelerator’s contribution, and knowing it tells you how much of your performance depends on a device that can fail independently of the link.