How we test satellite links: GEO delay, LEO jumps and failover

A satellite terminal is sold with a plan, say 200 Mbps down and 20 up. At acceptance someone runs a speed test next to the dish, and it passes. A week later the remote site calls: the VPN to head office crawls, voice breaks up, the ERP login page takes seconds to open. The speed test ran many streams to a server next to the satellite gateway, outside the tunnel. The users work through one tunnel, one TCP session at a time and a voice call, over 600 ms of RTT on GEO or over a LEO path that changes satellite several times a minute. We put that path on the bench and measure the applications on it.

The bench

The remote-site router, firewall or SD-WAN edge and its head end go onto the CloudLAB bench or run as VMs. Between them WANemu applies the satellite profile per direction: about 300 ms each way on GEO; 25 to 40 ms on LEO, with a step in delay and a short loss burst each time the terminal moves to the next satellite; separate bandwidth caps down and up. The profile can also come from delay, jitter and loss logged on your own terminal. WANemu, in beta on 1G and 10G links, runs well above any terminal plan; the generator measures the applied values before each run.

Events sit on one timeline at a known second: a rain fade on GEO that cuts the rate and raises loss for minutes, an obstruction on LEO that drops the link for a few seconds, a terrestrial line failure. The generator plays the users at the site and the servers behind the head end: TCP downloads and uploads, web and SaaS-like sessions over TLS, voice calls scored every second, all of it inside the VPN tunnel when the design has one.

What we check

• TCP per session: one download against the plan rate at the satellite RTT, with your window and acceleration settings; the window and BDP method is the same as on a terrestrial circuit
• Application response: time to first byte and page load for web and SaaS-like sessions, where each extra round trip costs 600 ms on GEO
• Voice: MOS per call per second, through the delay steps and loss bursts of every LEO satellite change
• VPN over the link: tunnel throughput against clear text, MTU with tunnel headers, whether DPD and rekey survive a short LEO outage
• Asymmetry: an upload filling the narrow uplink, and what it does to downloads and calls in the other direction
• Failover: terrestrial line cut or degraded, time until traffic runs over the satellite, sessions and tunnels lost on the way
• Failback: the terrestrial line returns; when traffic moves back and whether it flaps between the two paths

What usually breaks

Acceleration that the tunnel switches off. GEO terminals often split TCP in a performance enhancing proxy, so one download fills the plan in spite of the RTT. An IPsec tunnel hides the TCP headers, the proxy sees only ESP and stands aside. In a typical project with the proxy in the path, the same file came down at close to 40 Mbps in clear text and at about 3 Mbps inside the tunnel. What goes into the tunnel and where it ends is a design decision, cheaper to make on the bench than at 40 sites.

Probes tuned for fibre. An SD-WAN policy with a 150 ms SLA threshold marks GEO as broken all day, so the backup never counts as healthy. On LEO the delay step at each satellite change looks like a brownout, and traffic moves away and back several times a minute. The timeline shows which events should trigger a move, and the thresholds follow from it.

Timers. A tunnel with aggressive DPD settings from a terrestrial design drops during a 3-second LEO outage and takes longer to rebuild than the outage lasted. Over GEO, MOS carries a fixed penalty for the delay that no QoS setting wins back, and people start talking over each other.

What is in the report

The profile per direction, as set and as measured, with the event timeline. TCP throughput per session and per direction, clear and inside the tunnel. Time to first byte and page load per application. MOS per call per second. Failover and failback times, tunnels and sessions lost at each event. The profile is saved with the report, so the next firmware, another terminal or a move from GEO to LEO runs against the same path.

Where to start

Send us the devices at the remote site and at the head end, the satellite plan and, if you have them, delay and loss logs from the terminal. We answer with a draft test plan: the items, the bench layout and the dates. The report is yours to keep and to show to the vendor. Write to us or look at what else the bench does.