[Bloat] A Transport Protocol's View of Starlink

[Kenneth Porter <shiva@sewingwitch.com>]

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.