Re: [Bloat] starlink bloat in review

[Jim Gettys <jg@freedesktop.org>]

[-- Attachment #1: Type: text/plain, Size: 1796 bytes --]

As always, we have the problem of the last mile, in this case the hop into
the starlink network, and whatever is going on in the home router end. Most
Wi-Fi bloat is much worse than the last mile bloat, but you have to set out
to measure each independently.

When I first ran into buffer bloat, I measured 8 second latencies on the
bed upstairs, which if you moved the laptop even a few inches might drop to
something sane.

The customer doesn't care where the bloat is, just that it's happening...

Jim

On Mon, May 17, 2021, 11:08 AM Neal Cardwell via Bloat <
bloat@lists.bufferbloat.net> wrote:

> On Sat, May 15, 2021 at 7:00 PM Matt Mathis via Bloat
> <bloat@lists.bufferbloat.net> wrote:
> >
> > I don't understand: starlink doesn't terminate the TCP connection,
> > does it?   Or are you referring to YT's BBR adequately addressing
> > Starlinks variable RTT?   "Adequately" is probably the operative word.
> > It is not too hard to imagine what goes wrong with BBR if the actual
> > path length varies, and on an underloaded network, you may not be able
> > to even detect the symptoms.
>
> On that note, the article mentions:
>   "Starlink itself measures ping times for Counter-Strike: Go and
> Fortnite in its app, and I rarely saw those numbers dip below 50ms,
> mostly hovering around 85-115ms."
>
> If the range 50ms to 115ms is representative of two-way propagation
> delays on their network, then it sounds like BBR can probably perform
> reasonably well in that environment. The algorithm is designed to
> tolerate factor-of-two variations in RTT and still maintain full
> utilization, if there is reasonable buffering.
>
> neal
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>

[-- Attachment #2: Type: text/html, Size: 2628 bytes --]