Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: Sebastian Moeller <moeller0@gmx.de>
To: Mike Puchol <mike@starlink.sx>
Cc: Daniel AJ Sokolov <daniel@falco.ca>, David Lang <david@lang.hm>,
	dickroy@alum.mit.edu, starlink@lists.bufferbloat.net
Subject: Re: [Starlink] Starlink Roaming
Date: Tue, 22 Feb 2022 10:03:52 +0100	[thread overview]
Message-ID: <66B75B7A-82DF-4A92-BC74-CB0422E2BABC@gmx.de> (raw)
In-Reply-To: <80753e77-f7ba-466f-8222-66c16059f600@Spark>

Intersting!

Silly question, giving that there are already law suits for people pointing lasers at airplanes, how are these commercial laster terminals avoiding that issue?

Regards
	Sebastian




> On Feb 22, 2022, at 08:42, Mike Puchol <mike@starlink.sx> wrote:
> 
> 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 thereJ)
>> 
>> 
>> 
>> 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
>> 
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink


  parent reply	other threads:[~2022-02-22  9:04 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
2022-02-22  9:03                       ` Sebastian Moeller [this message]
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=66B75B7A-82DF-4A92-BC74-CB0422E2BABC@gmx.de \
    --to=moeller0@gmx.de \
    --cc=daniel@falco.ca \
    --cc=david@lang.hm \
    --cc=dickroy@alum.mit.edu \
    --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