[Bloat] A Transport Protocol's View of Starlink

[Stephen Hemminger]

On Wed, 22 May 2024 06:16:17 -0700
Kenneth Porter via Bloat <bloat at 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.