Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: Sebastian Moeller <moeller0@gmx.de>
To: Ulrich Speidel <u.speidel@auckland.ac.nz>,
	Ulrich Speidel via Starlink <starlink@lists.bufferbloat.net>,
	starlink@lists.bufferbloat.net
Subject: Re: [Starlink] Starlink "beam spread"
Date: Wed, 31 Aug 2022 08:26:09 +0200	[thread overview]
Message-ID: <9CE05D69-FC37-4C97-9D8D-D46B2DF6DE16@gmx.de> (raw)
In-Reply-To: <15982a40-2b34-7ed1-bfa3-bced03fc3839@auckland.ac.nz>

Hi Ulrich,

On 31 August 2022 00:50:35 CEST, Ulrich Speidel via Starlink <starlink@lists.bufferbloat.net> wrote:
>There's another aspect here that is often overlooked when looking purely at the data rate that you can get from your fibre/cable/wifi/satellite, and this is where the data comes from.
>
>A large percentage of Internet content these days comes from content delivery networks (CDNs). These innately work on the assumption that it's the core of the Internet that presents a bottleneck, and that the aggregate bandwidth of all last mile connections is high in comparison. A second assumption is that a large share of the content that gets requested gets requested many times, and many times by users in the same corner(s) of the Internet. The conclusion is that therefore content is best served from a location close to the end user, so as to keep RTTs low and - importantly - keep the load of long distance bottleneck links.
>
>Now it's fairly clear that large numbers of fibres to end users make for the best kind of network between CDN and end user. Local WiFi hotspots with limited range allow frequency re-use, as do ground based cellular networks, so they're OK, too, in that respect.  But anything that needs to project RF energy over a longer distance to get directly to the end user hasn't got nature on its side.
>
>This is, IMHO, Starlink's biggest design flaw at the moment: Going direct to end user site rather providing a bridge to a local ISP may be circumventing the lack of last mile infrastructure in the US, but it also makes incredibly inefficient use of spectrum and satellite resource. If every viral cat video that a thousand Starlink users in Iowa are just dying to see literally has to go to space a thousand times and back again rather than once, you arguably have a problem.

        Why? Internet access service is predominantly a service to transport any packets the users send and request when they do so. Caching content closer to the users or multicast tricks are basically optimizations that (occasionally) help decrease costs/increase margins for the operator, but IMHO they are exactly that, optimizations. So if they can not be used, no harm is done. Since caching is not perfect, such optimisations really are no way to safely increase the oversubscription rate either. Mind you I am not saying such measures are useless, but in IAS I consider them to be optional. Ideas about caching in space seem a bit pie-in-the-sky (pun intended) since at 4ms delay this would only help if operating CDNs in space would be cheaper than on earth at the base station or if the ground to satellite capacity was smaller then the aggregate satellite to end user capacity (both per satellite), no? 

Regards
        P.

P.S.: I think the same applies to GSM/LTE/5G basestations, as far as I can see 'edge' servuces (storage or compute) are interesting options for ISPs to offer higher ARPU products than commodity IAS, and not things required for a functional internet. Again nothing bad about offering such services, just they are optional.


>
>And yes, small neighbourhood networks of the type Mike described could put a significant dent into that problem. But do Starlink actually see Mike supplying 100 people as helpful, or do they see it as 99 customers they can no longer sell a dishy to? Given how they push their services into the market, I suspect it might be the latter.
>
>On 31/08/2022 10:07 am, Brandon Butterworth via Starlink wrote:
>> On Tue Aug 30, 2022 at 02:01:49PM -0700, David Lang via Starlink wrote:
>> > You are absolutly correct that people who can get fiber (and probably even
>> > most DSL) are far better using that than Starlink, and
>> > last-few-hundred-meters wireless can be better (like DSL, it depends on the
>> > exact service available)
>> ...
>> > People who can get that sort of service are not the target users for
>> > Starlink.
>> 
>> But unless Starlink turn them away some will still take the
>> service despite better options.
>> 
>> I do UK FWA and FTTP in rural areas and know others in the
>> industry. Some have reported being turned down as the
>> odd customer is waiting for Starlink (instead of taking a
>> government GBP4k+ subsidy giving them free fibre/FWA install)
>> 
>> There's no telling some people.
>> 
>> brandon
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

  parent reply	other threads:[~2022-08-31  6:26 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.3.1661875202.32670.starlink@lists.bufferbloat.net>
2022-08-30 16:53 ` David P. Reed
2022-08-30 17:32   ` Doc Searls
2022-08-30 20:09     ` Mike Puchol
2022-08-30 20:35       ` Daniel AJ Sokolov
2022-08-30 20:40         ` Mike Puchol
2022-08-30 21:09       ` David Lang
2022-08-30 21:01   ` David Lang
2022-08-30 22:07     ` Brandon Butterworth
2022-08-30 22:21       ` David Lang
2022-08-30 22:37         ` Brandon Butterworth
2022-08-30 23:07           ` David Lang
2022-08-30 23:45             ` Brandon Butterworth
2022-08-30 23:28           ` David P. Reed
2022-08-31  0:12             ` David Lang
2022-08-31  0:31               ` Dave Taht
2022-08-31  0:32               ` David P. Reed
2022-08-31 10:29                 ` Dave Collier-Brown
2022-08-31 18:51                   ` David Lang
2022-08-31 19:04             ` Dave Taht
2022-08-30 22:50       ` Ulrich Speidel
2022-08-30 23:13         ` David Lang
2022-08-31  0:46         ` tom
2022-08-31  0:58           ` Dave Taht
2022-08-31  7:36             ` Mike Puchol
2022-08-31  6:26         ` Sebastian Moeller [this message]
2022-08-31  7:25           ` Ulrich Speidel
2022-08-31  7:31             ` Hayden Simon
2022-08-31  7:33             ` David Lang
2022-08-31  9:59               ` Mike Puchol
2022-08-31 10:06                 ` David Lang
2022-08-31 10:12                   ` Mike Puchol
2022-08-31 17:52                 ` Dick Roy
2022-08-31 13:41               ` Ulrich Speidel
2022-08-31 14:30                 ` Mike Puchol
2022-08-31 21:44                   ` Ulrich Speidel
2022-09-01  7:58                 ` Sebastian Moeller
2022-09-01 11:38                   ` Ulrich Speidel
2022-09-01 19:54                     ` Michael Richardson
2022-09-01 21:08                       ` tom
2022-09-02  7:52                         ` Sebastian Moeller
2022-09-02 12:29                           ` tom
2022-08-31  7:49             ` Sebastian Moeller
2022-08-31  9:25               ` Brandon Butterworth
2022-08-31  9:34                 ` David Lang
2022-09-01  9:12                   ` Brandon Butterworth
2022-08-31 14:52   ` Dave Taht
2022-08-31 15:22     ` [Starlink] starlink upload behavior Dave Taht
2022-09-01 19:24       ` Luis A. Cornejo
2022-09-01 19:50         ` Dave Taht
2022-08-31  8:15 [Starlink] Starlink "beam spread" David Fernández
2022-08-31 14:51 David Fernández
2022-08-31 18:09 ` Michael Richardson
2022-08-31 21:46 ` Ulrich Speidel
2022-08-31 23:44   ` Lin Han
2022-09-01 19:26   ` Dave Taht
     [not found] <mailman.800.1661972667.1281.starlink@lists.bufferbloat.net>
2022-08-31 19:51 ` David P. Reed
2022-08-31 20:28   ` David Lang
2022-08-31 21:17     ` David P. Reed
2022-08-31 21:33       ` David Lang
2022-09-01  7:05         ` Mike Puchol
2022-09-01 11:43           ` Ulrich Speidel
2022-09-01  8:09       ` David Lang
2022-09-01 15:19 David Fernández
2022-09-01 16:33 ` Darrell Budic
2022-09-02  9:32   ` David Fernández
2022-09-01 19:56 ` Michael Richardson
2022-09-02 12:27   ` Sebastian Moeller
2022-09-02 18:34     ` Michael Richardson
2022-09-02 20:11       ` Sebastian Moeller

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/starlink.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9CE05D69-FC37-4C97-9D8D-D46B2DF6DE16@gmx.de \
    --to=moeller0@gmx.de \
    --cc=starlink@lists.bufferbloat.net \
    --cc=u.speidel@auckland.ac.nz \
    /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