> 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 _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
