Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: Vint Cerf <vint@google.com>
To: Mike Puchol <mike@starlink.sx>
Cc: Sebastian Moeller <moeller0@gmx.de>,
	starlink@lists.bufferbloat.net,
	 Daniel AJ Sokolov <daniel@falco.ca>
Subject: Re: [Starlink] Starlink Roaming
Date: Tue, 22 Feb 2022 05:37:10 -0500	[thread overview]
Message-ID: <CAHxHggf6JcqDS20g5DsO294+Qczduw7WiKUbVQfa0cYWmYm0DQ@mail.gmail.com> (raw)
In-Reply-To: <bfe1b5f8-4ab2-40fd-b9b6-b0cd8560c4c6@Spark>


[-- Attachment #1.1: Type: text/plain, Size: 6780 bytes --]

pun intended?
Mynaric is one of the more visible ones.

:-)

v



On Tue, Feb 22, 2022 at 5:01 AM Mike Puchol <mike@starlink.sx> wrote:

> It all depends on the power. We operate FSOC terminals that can do 20 Gbps
> at 20km+, and are eye-safe (un-aided, if you look at one using binoculars,
> different story).
>
> Power also depends on receiver sensitivity, if you can reconstruct a
> signal from less photons, your power requirements drop, and efficiency
> increases. There is a lot of research going on in this field, and there are
> many companies that are trying to get into the ground-to-air optical link
> game. Mynaric is one of the more visible ones.
>
> Best,
>
> Mike
> On Feb 22, 2022, 12:46 +0300, Sebastian Moeller <moeller0@gmx.de>, wrote:
>
>
>
> On Feb 22, 2022, at 10:40, Mike Puchol <mike@starlink.sx> wrote:
>
> The optical links work in IR spectrum, so non-visible. They would not be a
> concern for aircraft the same way green lasers are.
>
>
> Puzzled. IR lasers still wreck havoc when hitting the eye/retina, so why
> are these considered safer than visible spectrum lasers? In a lab context
> IR lasers are typically considered more dangerous as they are invisible and
> hence harder to see/avoid. I am happy to believe that there is a reason why
> they are safer, just trying ot reconcile that with my laser-safety seminar
> ;)
>
>
> On David’s comment "but if you can easily route traffic to a ground
> station that's further away and not currently saturated”, that is true as
> long as the path that is connected over ISL has visibility of that other
> ground station. I will add ISL to my tracker shortly so we can start
> simulating these things.
>
> Best,
>
> Mike
> On Feb 22, 2022, 12:04 +0300, Sebastian Moeller <moeller0@gmx.de>, wrote:
>
> 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
>
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>


-- 
Please send any postal/overnight deliveries to:
Vint Cerf
1435 Woodhurst Blvd
McLean, VA 22102
703-448-0965

until further notice

[-- Attachment #1.2: Type: text/html, Size: 9046 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3992 bytes --]

  reply	other threads:[~2022-02-22 10:37 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
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 [this message]
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=CAHxHggf6JcqDS20g5DsO294+Qczduw7WiKUbVQfa0cYWmYm0DQ@mail.gmail.com \
    --to=vint@google.com \
    --cc=daniel@falco.ca \
    --cc=mike@starlink.sx \
    --cc=moeller0@gmx.de \
    --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