Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
To: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] Starlink lost over 200 satellites in two months – tracker data
Date: Mon, 2 Oct 2023 15:48:18 +0200	[thread overview]
Message-ID: <a3f983b0-e406-47f8-b862-27a7b7966137@gmail.com> (raw)
In-Reply-To: <31028.1696249662@localhost>


Le 02/10/2023 à 14:27, Michael Richardson via Starlink a écrit :
> Ulrich Speidel via Starlink <starlink@lists.bufferbloat.net> wrote:
>      > In the case of Starlink, there is also the minor issue that their initial
>      > constellation that they started commercial ops with isn't ISL-capable, so
>      > there may be an incentive here to retire some satellites early, perhaps, and
>      > fill their orbital slots with more capable birds.
>
> I think that it falls into the fail-early dot-com mantra :-)
> Shorter lifetimes means shorter times to upgrade the network.
> Not just the ISL, but also the rest of the forwarding hardware.
>
> Given that spaceX is putting these satellites up at marginal launch costs,
> and I think getting a very very significant R&D and publicity boost from the
> very rapid pace of launches and booster reuses, it seems like it's just a win-win-win.

I think it is excellent that a LEO constellation can be upgraded that 
fast.  It means there will be an ever improved service to end users.  
This reliable launch frequency, orbiting, de-orbiting, are extraordinary 
technical achievements.

However, as with everything, one should also think about the 
inconvenients.  It can't simply be a win-win-win, without someone to 
loose something.

Probably one of the inconvenients is the additional risks involved by 
re-entry, new collision avoidance necessities, and sky observation 
blockage.  There is also the risk of some unwanted collision hapening up 
there but deemed as wanted by some.  It is new unknowns - says a 
non-expert -  that we add to the already shaky overall system.  They 
should not be overlooked.

True too:  probably it is the technology too that might help alleviate 
these potential problems (if problems they are), and not the lack of 
technology.

Alex

>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

  reply	other threads:[~2023-10-02 13:48 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-19 14:48 the keyboard of geoff goodfellow
2023-09-19 22:55 ` Dave Taht
2023-10-02 10:15   ` Alexandre Petrescu
2023-10-02 10:39     ` Ulrich Speidel
2023-10-02 12:27       ` Michael Richardson
2023-10-02 13:48         ` Alexandre Petrescu [this message]
2023-10-02 20:08     ` David Lang

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=a3f983b0-e406-47f8-b862-27a7b7966137@gmail.com \
    --to=alexandre.petrescu@gmail.com \
    --cc=starlink@lists.bufferbloat.net \
    /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