TCP trapped in Starlink: What hinders the protocol's stable operation

Father

Professional
Messages
2,604
Reputation
4
Reaction score
624
Points
113
Jeff Houston explains what's wrong with a popular satellite Internet provider.

SpaceX's Starlink satellite Internet service represents an "extremely unfavorable environment" for the widely used TCP protocol. This assessment was given by Jeff Houston, chief researcher at the Asia-Pacific Center for Information Networks, who posted an analysis of Starlink performance on his blog.

TCP (Transmission Control Protocol) is one of the main network protocols that provides reliable data transmission on the Internet and other TCP/IP networks. It ensures that data packets are delivered in the correct order and lossless by controlling the transfer rate, determining the route, and requesting that lost packets be re-sent. Most popular Internet applications and services rely on TCP for information exchange.

Houston explains that satellites in low-Earth orbit fly so fast above the surface of our planet that they can cross the sky from horizon to horizon in less than five minutes. To maintain the connection, ground antennas are forced to periodically switch to another device in the network.

Using the PING command, the scientist found that the minimum delay changes every 15 seconds. This allowed us to assume that user terminals are continuously switching to new satellites. Houston estimates that Starlink equipment tracks each satellite within a 15-second interval, which corresponds to an observation angle of 11 degrees.

While switching between satellites, Houston recorded packet loss and significant latency spikes. In the worst case, the delay increased from 30 to 80 milliseconds. Moreover, within each 15-second tracking interval, the delay variation was relatively high — on average, the jitter between consecutive RTT intervals was 6.7 ms. Bursts of delay during switching reached 30-50 ms. This means that the Starlink system uses large buffers to smooth out short-term problems that occur when transmitting a connection from one satellite to another. The presence of such buffers helps to overcome temporary failures caused by frequent changes of satellites during a communication session.

In general, according to Houston, Starlink is characterized by "a very high level of jitter, a percentage of lost packets of the order of 1-2%, not related to network congestion, and a delay that regularly jumps every 15 seconds."

Such conditions create an "extremely unfavorable environment for data transmission" over the TCP protocol. This means that older versions, such as Reno TCP, which respond quickly to packet loss and recover slowly, will perform poorly when using the Starlink network.

However, the researcher believes that this problem can be solved by slightly optimizing the protocol for working with Starlink. He suggests three potential candidates who can handle this task...

One possible solution is the BBR (Bottleneck Bandwidth and Round-trip propagation time) protocol — a TCP congestion control algorithm developed by Google. BBR tries to predict network path delays and adjusts its data sending strategies accordingly.

The CUBIC TCP congestion prevention algorithm paired with selective acknowledgments (SACK-RFC 2883)can also do a good job.

Houston believes that Explicit Congestion Notification can also help, since it is able to handle situations with spikes in latency caused by switching between satellites.

Despite the difficulties with TCP, speed tests conducted by Houston every 4 hours from August 2023 to March 2024 showed that, overall, Starlink provides good throughput. The median value was about 120 Mbit/s for download with peaks of up to 370 Mbit/s and lows of 10 Mbit/s, as well as 15 Mbit/s for returns with variations from 5 to 50 Mbit/s.
 
Top