From: Stephen Hemminger <stephen@networkplumber.org>
To: Kenneth Porter via Bloat <bloat@lists.bufferbloat.net>
Cc: Kenneth Porter <shiva@sewingwitch.com>
Subject: Re: [Bloat] A Transport Protocol's View of Starlink
Date: Wed, 22 May 2024 08:59:27 -0700 [thread overview]
Message-ID: <20240522085927.32b82e93@hermes.local> (raw)
In-Reply-To: <4223FB1D3EC8265F9E30D997@[192.168.11.128]>
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.
next prev parent reply other threads:[~2024-05-22 15:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-22 13:16 Kenneth Porter
2024-05-22 15:59 ` Stephen Hemminger [this message]
2024-05-22 16:03 ` Sebastian Moeller
2024-05-22 18:55 ` Kenneth Porter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240522085927.32b82e93@hermes.local \
--to=stephen@networkplumber.org \
--cc=bloat@lists.bufferbloat.net \
--cc=shiva@sewingwitch.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox