From: Ulrich Speidel <u.speidel@auckland.ac.nz>
To: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] Jamaican Starlink Outages and a hint of shared infrastructure
Date: Tue, 25 Jun 2024 10:19:27 +1200 [thread overview]
Message-ID: <29b64dbf-34c4-4616-9724-9c79bdcc1bb4@auckland.ac.nz> (raw)
In-Reply-To: <CAHn=e4iDNpha=nOh3_uJapeQrmT1OJtw-Brt0AO1PxPtDDXATw@mail.gmail.com>
This is actually a wider problem and it's not just a Starlink one. In
grad school, we teach students what a wonderful thing this Internet is,
and how it abounds with algorithms that find the shortest path and make
life wonderful. In practice, most people who "buy Internet" don't look
much past where their immediate physical connection terminates and what
might be lurking upstream. I had dinner with the CEO of a REN a few
years ago who complained bitterly that some university managers didn't
understand that if they made them an offer to build a connection for
them, it meant that they could get a dedicated fibre pair all the way to
the other side of the world if they needed it. And of course their
offering was a bit dearer than that of the local retail ISP who was also
offering "X Gb/s" - but of course only going as far as their own
infrastructure. From where the university traffic would have been
travelling cattle class.
This can also lead to weird effects globally. For example, much of the
traffic between Japan and New Zealand *could* in principle trundle down
to Guam and from there to Sydney and then to Auckland. Which would be
kind of shortest path. And occasionally it does. But just as often, you
see it crossing the Pacific to the US West Coast (or from Guam to
Hawaii) and from there back to New Zealand. Why? Good question. Was it
because US backhaul carriers were cheaper for a while with the US dollar
being soft and the Australian / NZ currencies surging in comparison?
Were there government incentives for carriers to let traffic run through
US territory for intelligence access (if so, the NSA would have to fear
a strong dollar I guess)?
With Starlink, keeping traffic out of space might seem a bit weird given
their 100 Gb/s lasers, but yes it does mean downlinking to
infrastructure that may path-share with with the infrastructure you're
seeking to back up. But lasering your traffic around means adding
latency - the path may zig-zag badly or may even overshoot the target.
Plus the latency won't be stable. So keeping traffic out of space isn't
such a bad idea after all perhaps. Then again, Jamaica's fibre
connectivity is by and large not great circle path either...
On 25/06/2024 2:42 am, J Pan via Starlink wrote:
> can you give the reference to the complaint so we can dive into it a
> bit? once the user packet reaches the satellite, it needs to get to
> the ground (sooner than later according to starlink's current
> practice), which may run into the same fiber to tunnel the packet from
> the landing ground station to the user's home pop. once at the pop,
> most starlink pop's now have at least two neighbor pop's, so
> theoretically, starlink has the capability to route packets to a
> different landing ground station through inter-sat links and another
> pop, if it can arrange so properly
> --
> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan
>
> On Mon, Jun 24, 2024 at 3:40 AM Inemesit Affia via Starlink
> <starlink@lists.bufferbloat.net> wrote:
>> I don't live in Jamaica but I just saw a user complain his service goes out at the same time his local provider does.
>>
>> The provider is Flow Jamaica and they seem to get service via C&W Caribbean according to another poster.
>>
>> Service going out together likely means there's shared infrastructure. And buying Starlink as backup and having it fail hard without rerouting several times in a row is below expectations.
>>
>> There's another provider in Jamaica. Digicel that seems to have separate infrastructure but that might not be value for money to have alternative connectivity.
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
--
****************************************************************
Dr. Ulrich Speidel
School of Computer Science
Room 303S.594 (City Campus)
The University of Auckland
u.speidel@auckland.ac.nz
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************
next prev parent reply other threads:[~2024-06-24 22:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-19 17:31 [Starlink] I still dream of an tiny on-orbit repair and inspection robot Dave Taht
2024-06-19 18:44 ` Kenneth Porter
2024-06-24 10:39 ` [Starlink] Jamaican Starlink Outages and a hint of shared infrastructure Inemesit Affia
2024-06-24 14:42 ` J Pan
2024-06-24 22:19 ` Ulrich Speidel [this message]
2024-06-25 3:42 ` David Lang
2024-06-25 4:34 ` Ulrich Speidel
2024-06-25 5:37 ` Sebastian Moeller
2024-06-25 6:54 ` Gert Doering
2024-06-25 7:26 ` Sebastian Moeller
2024-06-25 19:07 ` J Pan
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=29b64dbf-34c4-4616-9724-9c79bdcc1bb4@auckland.ac.nz \
--to=u.speidel@auckland.ac.nz \
--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