[Bloat] starlink bloat in review

[Bloat] starlink bloat in review

[Dave Taht]

"In my week of testing, Starlink was perfectly fine for anything that
buffers — I was able to stream Netflix and Disney Plus in 4K and jump
around YouTube videos without significant issues — but doing something
faster-paced, like quickly scrolling through TikTok videos, would run
into delays."

https://www.theverge.com/22435030/starlink-satellite-internet-spacex-review

To me that "jump around youtube" is telling me that BBR is working on starlink.

Also of interest in this article was links to their open source
copyrights, which confirm linux 4.9 is in use.

-- 
Latest Podcast:
https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/

Dave Täht CTO, TekLibre, LLC

Re: [Bloat] starlink bloat in review

[Matt Mathis]

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.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

We must not tolerate intolerance;
       however our response must be carefully measured:
            too strong would be hypocritical and risks spiraling out of control;
            too weak risks being mistaken for tacit approval.

On Sat, May 15, 2021 at 3:08 PM Dave Taht <dave.taht@gmail.com> wrote:
>
> "In my week of testing, Starlink was perfectly fine for anything that
> buffers — I was able to stream Netflix and Disney Plus in 4K and jump
> around YouTube videos without significant issues — but doing something
> faster-paced, like quickly scrolling through TikTok videos, would run
> into delays."
>
> https://www.theverge.com/22435030/starlink-satellite-internet-spacex-review
>
> To me that "jump around youtube" is telling me that BBR is working on starlink.
>
> Also of interest in this article was links to their open source
> copyrights, which confirm linux 4.9 is in use.
>
> --
> Latest Podcast:
> https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/
>
> Dave Täht CTO, TekLibre, LLC
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] starlink bloat in review

[Neal Cardwell]

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

Re: [Bloat] starlink bloat in review

[Jim Gettys]

[-- 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 --]

Re: [Bloat] [Starlink] starlink bloat in review

[Nathan Owens]

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

Here's someone's monitoring setup with high frequency pings:
https://snapshot.raintank.io/dashboard/snapshot/eL3CqijxCvIn0yJz05QQkg47OTNlk05A?orgId=2
Looks better than the 50-115ms reported.

On Mon, May 17, 2021 at 8:34 AM Neal Cardwell <ncardwell@google.com> 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
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>

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