From: "Dick Roy" <dickroy@alum.mit.edu>
To: "'Mike Puchol'" <mike@starlink.sx>,
"'Daniel AJ Sokolov'" <daniel@falco.ca>,
"'David Lang'" <david@lang.hm>
Cc: <starlink@lists.bufferbloat.net>
Subject: Re: [Starlink] Starlink Roaming
Date: Mon, 21 Feb 2022 23:51:42 -0800 [thread overview]
Message-ID: <E5E59A9B145441C983E72F8DF5D8A29C@SRA6> (raw)
In-Reply-To: <80753e77-f7ba-466f-8222-66c16059f600@Spark>
[-- Attachment #1: Type: text/plain, Size: 4179 bytes --]
All excellent points and right on! Thanks!
RR
_____
From: Mike Puchol [mailto:mike@starlink.sx]
Sent: Monday, February 21, 2022 11:42 PM
To: 'Daniel AJ Sokolov'; 'David Lang'; dickroy@alum.mit.edu
Cc: starlink@lists.bufferbloat.net
Subject: RE: [Starlink] Starlink Roaming
I did over-simplify so the point was better understood. On the optical
gateways, these exist already:
https://mynaric.com/products/ground-capabilities/
Once you have an optical mesh in orbit, the only practical way to provide it
with massive capacity is optical links - there isn't enough radio spectrum
that would do it (without a massive ground gateway network with enough
physical separation). You can create a network of optical gateways that
guarantees a number of them will not be impared by cloud cover at any given
time. Optical has the advantage of being license-free, too.
Best,
Mike
On Feb 22, 2022, 10:20 +0300, Dick Roy <dickroy@alum.mit.edu>, wrote:
_____
From: Starlink [mailto:starlink-bounces@lists.bufferbloat.net] On Behalf Of
Mike Puchol
Sent: Monday, February 21, 2022 9:35 PM
To: Daniel AJ Sokolov; David Lang
Cc: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] Starlink Roaming
Actually, laser links would make gateway connectivity *worse*. If we take
the scenario attached, one gateway is suddenly having to serve traffic from
all UTs that were not previously under coverage.
A satellite under full load can saturate two gateway links by itself. If you
load, say, 20 satellites in an orbital plane, onto a single gateway, over
ISL, you effectively have 5% of each satellite's capacity available (given
an equal distribution of demand, of course there will be satellites with no
UTs to cover etc.).
[RR] I think to do this analysis correctly; one needs to consider the larger
system and the time-varying loads on the components thereof. What you say is
true; just a bit over-simplified to be maximally useful. Routing through
complex congested networks is well-studied problem and hnts at possible
solutions can probably be found there:-))
Eventually they will go for optical gateways, it's the only way to get
enough capacity to the constellation, specially the 30k satellite version.
[RR] What do you mean by ""optical gateway"? An optical link from the
satellite to the ground station? That would be real expensive at least
power-wise and unreliable.
Best,
Mike
On Feb 22, 2022, 05:17 +0300, David Lang <david@lang.hm>, wrote:
On Mon, 21 Feb 2022, Daniel AJ Sokolov wrote:
On 2022-02-21 at 13:52, David Lang wrote:
They told me that I could try it, and it may work, may be degraded a
bit, or may not work at all. They do plan to add roaming capabilities in
the future (my guess is that the laser satellites will enable a lot more
flexibility)
Isn't that a very optimistic assessment? :-)
Laser links are great for remote locations with very few users, but how
could they relieve overbooking of Starlink in areas with too many users?
The laser links can reduce the required density of ground stations, but
they don't add capacity to the network. Any ground station not built
thanks to laser links adds load to other ground stations - and, maybe
more importantly, adds load to the satellite that does eventually
connect to a ground station.
Can laser links really help on a large scale, or are they just a small
help here and there?
My thinking is that the laser links will make it possible to route the
traffic
from wherever I am to the appropriate ground station that I'm registered
with as
opposed to the current bent-pipe approach where, if I move to far from my
registered location, I need to talk to a different ground station.
Currently there are two limits in any area for coverage:
1. satellite bandwidth
2. ground station bandwidth
laser links will significantly reduce the effect of the second one.
We know that they can do mobile dishes (they are testing it currently on
Elon's
gulfstream, FAR more mobile that I will ever be :-) )
David Lang
_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink
[-- Attachment #2: Type: text/html, Size: 12068 bytes --]
next prev parent reply other threads:[~2022-02-22 7:51 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-14 19:53 Jonathan Bennett
2022-02-14 20:29 ` David Lang
2022-02-14 21:43 ` Mike Puchol
2022-02-14 21:53 ` Jonathan Bennett
2022-02-14 21:59 ` Mike Puchol
2022-02-21 7:22 ` Larry Press
2022-02-21 7:29 ` David Lang
2022-02-21 20:31 ` Dick Roy
2022-02-21 20:43 ` Mike Puchol
2022-02-21 20:52 ` David Lang
2022-02-21 21:17 ` Dick Roy
2022-02-21 21:32 ` David Lang
2022-02-21 21:58 ` Nathan Owens
2022-02-21 22:26 ` Dick Roy
2022-02-21 23:08 ` Steve Golson
2022-02-21 23:15 ` Nathan Owens
2022-02-22 1:19 ` Dick Roy
2022-02-21 22:02 ` Daniel AJ Sokolov
2022-02-22 2:17 ` David Lang
2022-02-22 5:34 ` Mike Puchol
2022-02-22 7:20 ` Dick Roy
2022-02-22 7:42 ` Mike Puchol
2022-02-22 7:51 ` Dick Roy [this message]
2022-02-22 9:03 ` Sebastian Moeller
2022-02-22 9:40 ` Mike Puchol
2022-02-22 9:46 ` Sebastian Moeller
2022-02-22 10:01 ` Mike Puchol
2022-02-22 10:37 ` Vint Cerf
2022-02-22 11:14 ` Mike Puchol
2022-02-22 7:58 ` Ulrich Speidel
2022-02-22 8:51 ` David Lang
2022-02-22 7:47 ` Dick Roy
2022-02-22 8:55 ` David Lang
2022-02-22 23:14 ` Dick Roy
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=E5E59A9B145441C983E72F8DF5D8A29C@SRA6 \
--to=dickroy@alum.mit.edu \
--cc=daniel@falco.ca \
--cc=david@lang.hm \
--cc=mike@starlink.sx \
--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