From: Spencer Sevilla <spencer.builds.networks@gmail.com>
To: Eugene Chang <eugene.chang@alum.mit.edu>
Cc: "David Fernández" <davidfdzp@gmail.com>,
"starlink@lists.bufferbloat.net" <starlink@lists.bufferbloat.net>
Subject: Re: [Starlink] Starlink Digest, Vol 25, Issue 28
Date: Thu, 20 Apr 2023 15:07:32 -0700 [thread overview]
Message-ID: <5472C863-B81B-42C9-B9A4-7BF032F075FD@gmail.com> (raw)
In-Reply-To: <EF816E63-C23D-401D-B94C-782DAC3751F6@alum.mit.edu>
[-- Attachment #1: Type: text/plain, Size: 5876 bytes --]
+1 to Gene, I have shared the exact same confusion on this thread.
For satellites moving so fast (horizon to horizon in ~90sec), any network functions above L2 (e.g. routing, caching, etc) feel like they’d spend all their time churning. Keeping the satellites as bent-pipe repeaters between a dishy and a ground station effectively hides their orbital mobility from all other layers in the network and allows for stability in other layers.
Now, caching *at* the dishy, on the other hand… sounds like a great idea! Caching at the ground station as well, though that doesn’t get you any gains in terms of minimizing satellite network bandwidth.
Spencer
> On Apr 20, 2023, at 14:34, Eugene Chang via Starlink <starlink@lists.bufferbloat.net> wrote:
>
> Friends,
> As I follow the discussion of putting computers on satellite, I can understand the attraction if I apply the discussion with a satellite and server above my location, suspended by a skyhook. The geometry is very easy (some variations of a triangle). However, with an LEO satellite (or MEO), most of the time the server is not overhead, it is hidden by the horizon.
>
> Have I missed comments (or naively not understood comments) about how the solutions work when the server is not overhead? I wanted to hear about data locality and how the desired behavior varies according to the position of the server. Does some of the proposed edge computing imply (or assume) the data is needed on many satellites so that there is always a server overhead with the needed data? (Then we have lots of data synchronization challenges.) Clearly, this suggests there is a scaling problem for edge computing solutions because for a single server, most of the time the computer is not at the edge near me.
>
> What am I missing?
>
> Gene
> -----------------------------------
> Eugene Chang
> eugene.chang@alum.mit.edu <mailto:eugene.chang@alum.mit.edu>
> +1-781-799-0233 (in Honolulu)
>
>
>
>
>
>> On Apr 20, 2023, at 2:24 AM, David Fernández via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>> wrote:
>>
>> Well, O3b MPower (MEO satellites) is offering independent one hop
>> dedicated access to the (Microsoft Azure) cloud as "killer
>> application". If the cloud is on the satellite, half-hop.
>>
>> Starlink GWs are near Google Cloud datacenters.
>>
>> Blue Origin is on the mission to move Amazon Cloud to orbit,
>> eventually, maybe, leaving the Earth as a garden to enjoy, without any
>> industry on the surface (in a century, maybe). Kuiper will offer one
>> hop access to Amazon Cloud, then half-hop.
>>
>> What seems a crazy idea today will be eventually implemented later,
>> like Starlink (Teledesic failed, fingers crossed Starlink does not go
>> bankrupt, although I would expect it be saved by Department of
>> Defense, as Iridium was saved).
>>
>> As we were discussing recently, maybe starting with anycast DNS
>> servers on satellites is a first step to consider, before embarking
>> any other type of cloud servers.
>>
>> Regards,
>>
>> David
>>
>>> Date: Thu, 20 Apr 2023 04:33:00 +0000
>>> From: Ulrich Speidel <u.speidel@auckland.ac.nz <mailto:u.speidel@auckland.ac.nz>>
>>> To: "tom@evslin.com <mailto:tom@evslin.com>" <tom@evslin.com <mailto:tom@evslin.com>>, 'Michael Richardson'
>>> <mcr@sandelman.ca <mailto:mcr@sandelman.ca>>, 'starlink' <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>>,
>>> "e-impact@ietf.org <mailto:e-impact@ietf.org>" <e-impact@ietf.org <mailto:e-impact@ietf.org>>
>>> Subject: Re: [Starlink] DataCenters in Space (was Re: fiber IXPs in
>>> space)
>>> Message-ID:
>>> <SY4PR01MB697983BB5DEB1B2AA0B2690BCE639@SY4PR01MB6979.ausprd01.prod.outlook.com <mailto:SY4PR01MB697983BB5DEB1B2AA0B2690BCE639@SY4PR01MB6979.ausprd01.prod.outlook.com>>
>>>
>>> Content-Type: text/plain; charset="windows-1252"
>>>
>>> Where do I even start? The lack of substantial bandwidth between space and
>>> ground? The extra latency between ground and space compared to terrestrial
>>> cloud, especially as terrestrial cloud edge can move much closer to
>>> customers when space can't? The fact that every LEO satellite is both a few
>>> 100 km from every customer and out of the customer's range depending on when
>>> you look? That low temperatures in space don't mean superconductive chips
>>> that produce zero heat, and that that heat is difficult to get rid of in
>>> space? That generating power in space is orders of magnitude more expensive
>>> than on the ground?
>>>
>>> Just because Starlink can provide a service somewhere between DSL and low to
>>> medium grade fibre to a few million around the globe it's not "done". Even
>>> with 10x the number of satellites and a couple of times the current capacity
>>> per satellite, Starlink isn't going to supply more than a couple of 100
>>> million at best, and that's not even accounting for growth in demand from
>>> IOT...
>>>
>>> --
>>>
>>> ****************************************************************
>>> Dr. Ulrich Speidel
>>>
>>> School of Computer Science
>>>
>>> Room 303S.594 (City Campus)
>>> Ph: (+64-9)-373-7599 ext. 85282
>>>
>>> The University of Auckland
>>> ulrich@cs.auckland.ac.nz <mailto:ulrich@cs.auckland.ac.nz><mailto:ulrich@cs.auckland.ac.nz>
>>> http://www.cs.auckland.ac.nz/~ulrich/
>>> ****************************************************************
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
>> https://lists.bufferbloat.net/listinfo/starlink
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
[-- Attachment #2: Type: text/html, Size: 16853 bytes --]
next prev parent reply other threads:[~2023-04-20 22:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.751.1681965188.1222.starlink@lists.bufferbloat.net>
2023-04-20 12:24 ` David Fernández
2023-04-20 16:14 ` Michael Richardson
2023-04-20 16:20 ` David Lang
2023-04-20 21:34 ` Eugene Chang
2023-04-20 22:07 ` Spencer Sevilla [this message]
2023-04-20 22:11 ` David Lang
2023-04-21 0:03 ` tom
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=5472C863-B81B-42C9-B9A4-7BF032F075FD@gmail.com \
--to=spencer.builds.networks@gmail.com \
--cc=davidfdzp@gmail.com \
--cc=eugene.chang@alum.mit.edu \
--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