Starlink offers TCP an ‘unusually hostile environment’

SpaceX’s Starlink satellite Internet service “represents an unusually hostile link environment” for the TCP protocol, said Geoff Huston, chief scientist at the Asia Pacific Network Information Center.

Huston’s assessment appeared late last week in a blog post detailing his analysis of Starlink’s performance.

The article begins by explaining that satellites in low Earth orbit zoom by so fast that they can go from horizon to horizon in less than five minutes. Therefore, to maintain a connection, terrestrial antennas must periodically connect to another satellite.

“A continuous LEO satellite service must hop over a continuous series of satellites as they pass overhead and switch the virtual circuit path to successive satellites as they come into view of both the end user and the user-designated ground station,” he wrote. Huston thinks this could happen as often as every 15 seconds.

Using PING, he found that the minimum latency regularly changes every 15 seconds and surmised that this change is related to the Starlink user’s terminal being assigned to a different satellite. This implies that the user equipment ‘tracks’ each satellite for 15 seconds. second interval, which corresponds to a tracking angle of 11 degrees of arc.”

During these transfers, Huston observed some packet loss – and a significant increase in latency. “The worst case in this data set is a shift from 30 ms to 80 ms,” he wrote. Furthermore: “Within each 15 second satellite tracking interval, the latency variation is relatively high. The average variation of jitter between consecutive RTT intervals is 6.7 ms. The transmission latency peaks impose an additional 30 ms to 50 ms, indicating the presence of deep buffers in the system to accommodate the transient problems associated with satellite transmission.”

Overall, Huston believes Starlink has “a very high jitter rate, a packet loss rate of about one to two percent that has nothing to do with network congestion, and a latency profile that regularly jumps every 15 seconds.”

That makes it “an unusually hostile link environment” for the Transport Control Protocol (TCP), and means that “older variants of TCP, such as Reno TCP, which respond quickly to packet loss and recover slowly, can perform very poorly when used over Starlink connections .

That’s obviously not good news if you’ve built an app to use a version of TCP that doesn’t like visiting space via Starlink.

Fortunately, Huston thinks he has a solution: tune TCP so it behaves better on Starlink. He even has three candidates he thinks are right for the job.

One of these is the Bottleneck Bandwidth and Round-trip propagation time (BBR) protocol – a TCP congestion control algorithm developed by Google. BBR attempts to predict the delays on a network path and adjusts transmission strategies accordingly.

The CUBIC TCP network congestion avoidance algorithm could also do a job, when combined with Selective Acknowledgment (SACK – also known as RFC 2883).

Huston also thinks Explicit Congestion Notification could help, as it can catch situations like latency spikes caused by satellite transfers.

While Starlink’s hostility toward TCP worries Huston and could get some apps into trouble, the service usually provides a decent amount of bandwidth: The lead scientist used Speedtest every four hours from August 2023 to March 2024 and found that the service “an average appears to have a value of around 120 Mbit/sec download capacity, with individual measurements up to 370 Mbit/sec and as low as 10 Mbit/sec, and 15 Mbit/sec upload capacity, with a variance between 5 Mbit/sec and 50 Mbit/sec. ” ®

Leave a Reply

Your email address will not be published. Required fields are marked *