[Bloat] A Transport Protocol's View of Starlink

[Bloat] A Transport Protocol's View of Starlink

[Kenneth Porter]

This technical paper on Starlink by the chief scientist at APNIC crossed my 
feed this week. [I thought I'd share it to the Starlink list here but my 
application to join that list seems to have gotten stuck so I'll share it 
here for now.]

<https://www.potaroo.net/ispcol/2024-05/starlink-tcp.html>

From the end of the paper:

> While earlier TCP control protocols, such as Reno, have been observed to
> perform poorly on Starlink connections, more recent TCP counterparts,
> such as CUBIC, perform more efficiently. The major TCP feature that makes
> these protocols viable in Starlink contexts is the use of Selective
> Acknowledgement [11], that allows the TCP control algorithm to
> distinguish between isolated packet loss and loss-inducing levels of
> network congestion.
>
> TCP control protocols that attempt to detect the onset of network queue
> formation can do so using end-to-end techniques by detecting changes in
> end-to-end latency during intermittent periods of burst, such as BBR.
> These protocols need to operate with a careful implementation of their
> sensitivity to latency, as the highly unstable short-term latency seen on
> Starlink connections, coupled with the 15-second coarse level latency
> shifts have the potential to confuse the queue onset detection algorithm.
>
> It would be interesting to observe the behaviour of an ECN-aware TCP
> protocol behaviour if ECN were to enabled on Starlink routing devices.
> ECN has the potential to provide a clear signal to the endpoints about
> the onset of network-level queue formation, as distinct from latency
> variation.

Re: [Bloat] A Transport Protocol's View of Starlink

[Stephen Hemminger]

On Wed, 22 May 2024 06:16:17 -0700
Kenneth Porter via Bloat <bloat@lists.bufferbloat.net> wrote:

> This technical paper on Starlink by the chief scientist at APNIC crossed my 
> feed this week. [I thought I'd share it to the Starlink list here but my 
> application to join that list seems to have gotten stuck so I'll share it 
> here for now.]
> 
> <https://www.potaroo.net/ispcol/2024-05/starlink-tcp.html>
> 
> >From the end of the paper:  
> 
> > While earlier TCP control protocols, such as Reno, have been observed to
> > perform poorly on Starlink connections, more recent TCP counterparts,
> > such as CUBIC, perform more efficiently. The major TCP feature that makes
> > these protocols viable in Starlink contexts is the use of Selective
> > Acknowledgement [11], that allows the TCP control algorithm to
> > distinguish between isolated packet loss and loss-inducing levels of
> > network congestion.
> >
> > TCP control protocols that attempt to detect the onset of network queue
> > formation can do so using end-to-end techniques by detecting changes in
> > end-to-end latency during intermittent periods of burst, such as BBR.
> > These protocols need to operate with a careful implementation of their
> > sensitivity to latency, as the highly unstable short-term latency seen on
> > Starlink connections, coupled with the 15-second coarse level latency
> > shifts have the potential to confuse the queue onset detection algorithm.
> >
> > It would be interesting to observe the behaviour of an ECN-aware TCP
> > protocol behaviour if ECN were to enabled on Starlink routing devices.
> > ECN has the potential to provide a clear signal to the endpoints about
> > the onset of network-level queue formation, as distinct from latency
> > variation.  

It frustrates me that all research still looks primarily at Reno, rather
than the congestion controls that are actually implemented in Linux and Windows
which are used predominately on the Internet.

Re: [Bloat] A Transport Protocol's View of Starlink

[Sebastian Moeller]

> On 22. May 2024, at 17:59, Stephen Hemminger via Bloat <bloat@lists.bufferbloat.net> wrote:
> 
> On Wed, 22 May 2024 06:16:17 -0700
> Kenneth Porter via Bloat <bloat@lists.bufferbloat.net> wrote:
> 
>> This technical paper on Starlink by the chief scientist at APNIC crossed my 
>> feed this week. [I thought I'd share it to the Starlink list here but my 
>> application to join that list seems to have gotten stuck so I'll share it 
>> here for now.]
>> 
>> <https://www.potaroo.net/ispcol/2024-05/starlink-tcp.html>
>> 
>>> From the end of the paper:  
>> 
>>> While earlier TCP control protocols, such as Reno, have been observed to
>>> perform poorly on Starlink connections, more recent TCP counterparts,
>>> such as CUBIC, perform more efficiently. The major TCP feature that makes
>>> these protocols viable in Starlink contexts is the use of Selective
>>> Acknowledgement [11], that allows the TCP control algorithm to
>>> distinguish between isolated packet loss and loss-inducing levels of
>>> network congestion.
>>> 
>>> TCP control protocols that attempt to detect the onset of network queue
>>> formation can do so using end-to-end techniques by detecting changes in
>>> end-to-end latency during intermittent periods of burst, such as BBR.

[SM] Is that actually what BBR does? I believe BBR cyclically reduces its sending rate to measure the minRTT but during its bandwidth probes (or intermittent periods of bursts), it actually measures the rate via the ACK feedback and not the increased queueing delay?


>>> These protocols need to operate with a careful implementation of their
>>> sensitivity to latency, as the highly unstable short-term latency seen on
>>> Starlink connections, coupled with the 15-second coarse level latency
>>> shifts have the potential to confuse the queue onset detection algorithm.
>>> 
>>> It would be interesting to observe the behaviour of an ECN-aware TCP
>>> protocol behaviour if ECN were to enabled on Starlink routing devices.
>>> ECN has the potential to provide a clear signal to the endpoints about
>>> the onset of network-level queue formation, as distinct from latency
>>> variation.  
> 
> It frustrates me that all research still looks primarily at Reno, rather
> than the congestion controls that are actually implemented in Linux and Windows
> which are used predominately on the Internet.
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] A Transport Protocol's View of Starlink

[Kenneth Porter]

The Register came out with this summary today:

https://www.theregister.com/2024/05/22/starlink_tcp_performance_evaluation/

Excerpt:

> Using PING, he found "minimum latency changes regularly every 15 
> seconds" and surmised "It appears that this change correlates to the 
> Starlink user's terminal being assigned to a different satellite. That 
> implies that the user equipment 'tracks' each satellite for a 
> 15-second interval, which corresponds to a tracking angle of 11 
> degrees of arc."
>
> During those handovers, Huston observed some packet loss – and a 
> significant increase in latency. "The worst case in this data set is a 
> shift from 30ms to 80ms," he wrote. Further: "Within each 15-second 
> satellite tracking interval, the latency variation is relatively high. 
> The average variation of jitter between successive RTT intervals is 
> 6.7ms. The latency spikes at handover impose an additional 30ms to 
> 50ms indicating the presence of deep buffers in the system to 
> accommodate the transient issues associated with satellite handover."
>
> Overall, Huston believes Starlink has "a very high jitter rate, a 
> packet drop rate of around one percent to two percent that is 
> unrelated to network congestion, and a latency profile that jumps 
> regularly every 15 seconds."

[No need to cc me in replies, I'll read them on the mailiing list.]