Re: [Starlink] Starlink Digest, Vol 25, Issue 28

Re: [Starlink] Starlink Digest, Vol 25, Issue 28

[David Fernández]

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>
> To: "tom@evslin.com" <tom@evslin.com>, 'Michael Richardson'
> 	<mcr@sandelman.ca>, 'starlink' <starlink@lists.bufferbloat.net>,
> 	"e-impact@ietf.org" <e-impact@ietf.org>
> Subject: Re: [Starlink] DataCenters in Space (was Re:  fiber IXPs in
> 	space)
> Message-ID:
> 	<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>
> http://www.cs.auckland.ac.nz/~ulrich/
> ****************************************************************

Re: [Starlink] Starlink Digest, Vol 25, Issue 28

[Michael Richardson]

David Fernández via Starlink wrote:
    > 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.

For Starlink customers, having a DNS recursive cache on the satellite you are
talking to certainly saves half a hop, if the cache is big enough.
If the gateway part of the bent pipe suffers from bufferbloat,
then having DNS queries from the client avoid that part seems like a win.
Also, the recursive queries from the DNS recursive cache can be switched on a
different circuit to the gateway, or marked better to avoid the bufferbloat.

{or, you know, you could fix the bloat. In the satellite to satellite laser
circuits, I suspect that the bandwidth available will fluctuate wildly.
Engineers will be reluctant to throw away delay tolerant packets in that case}

(I'm not sure we should call it an anycast DNS service, because even though
it looks similiar to the clients to the things we do with BGP, its not really
the same.  Also, squatting on/intersepting 8.8.8.8, etc. would be a very bad
thing to do.  It would have to be a new address. But, because we wouldn't be
using BGP, it does not need to occupy an entire /24. )

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

Re: [Starlink] Starlink Digest, Vol 25, Issue 28

[David Lang]

[-- Attachment #1: Type: text/plain, Size: 2105 bytes --]

anycast doesn't require that you use BGP, it just means that you have the same 
IP address used in multiple places, and routes that send you to the closest one.

With starlink, they could put an address on every satellite (or every gateway) 
and it would handle the traffic would be handled by the first one that it ran 
across.

David Lang

  On Thu, 20 Apr 2023, Michael Richardson via Starlink wrote:

> David Fernández via Starlink wrote:
>    > 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.
>
> For Starlink customers, having a DNS recursive cache on the satellite you are
> talking to certainly saves half a hop, if the cache is big enough.
> If the gateway part of the bent pipe suffers from bufferbloat,
> then having DNS queries from the client avoid that part seems like a win.
> Also, the recursive queries from the DNS recursive cache can be switched on a
> different circuit to the gateway, or marked better to avoid the bufferbloat.
>
> {or, you know, you could fix the bloat. In the satellite to satellite laser
> circuits, I suspect that the bandwidth available will fluctuate wildly.
> Engineers will be reluctant to throw away delay tolerant packets in that case}
>
> (I'm not sure we should call it an anycast DNS service, because even though
> it looks similiar to the clients to the things we do with BGP, its not really
> the same.  Also, squatting on/intersepting 8.8.8.8, etc. would be a very bad
> thing to do.  It would have to be a new address. But, because we wouldn't be
> using BGP, it does not need to occupy an entire /24. )
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
>
>
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Starlink Digest, Vol 25, Issue 28

[Eugene Chang]

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

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
+1-781-799-0233 (in Honolulu)





> On Apr 20, 2023, at 2:24 AM, David Fernández via Starlink <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>
>> To: "tom@evslin.com" <tom@evslin.com>, 'Michael Richardson'
>> 	<mcr@sandelman.ca>, 'starlink' <starlink@lists.bufferbloat.net>,
>> 	"e-impact@ietf.org" <e-impact@ietf.org>
>> Subject: Re: [Starlink] DataCenters in Space (was Re:  fiber IXPs in
>> 	space)
>> Message-ID:
>> 	<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>
>> http://www.cs.auckland.ac.nz/~ulrich/
>> ****************************************************************
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink


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

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Starlink] Starlink Digest, Vol 25, Issue 28

[Spencer Sevilla]

[-- 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 --]

Re: [Starlink] Starlink Digest, Vol 25, Issue 28

[David Lang]

[-- Attachment #1: Type: text/plain, Size: 5205 bytes --]

On Thu, 20 Apr 2023, Eugene Chang via Starlink 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?

1. data like DNS where it really is the same everywhere and changes relatively 
slowly so it works well in this environment. (streaming data could possibly fall 
in this category, depending on how popular something is)

2. compute loads where you don't get the answer back immediately and can wait 
until the next orbit to get the answer (or where the processing time is large 
enough that the latency of sending the results around the world when it's done 
are small compared to the time it takes to generate the response) This is not 
what people think of, as it's not people waiting for the answer from a browser, 
but there is a lot more number-crunching than you think.


But yes, there are large categories of servers that this won't work for.

David Lang


> Gene
> -----------------------------------
> Eugene Chang
> 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> 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>
>>> To: "tom@evslin.com" <tom@evslin.com>, 'Michael Richardson'
>>> 	<mcr@sandelman.ca>, 'starlink' <starlink@lists.bufferbloat.net>,
>>> 	"e-impact@ietf.org" <e-impact@ietf.org>
>>> Subject: Re: [Starlink] DataCenters in Space (was Re:  fiber IXPs in
>>> 	space)
>>> Message-ID:
>>> 	<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>
>>> http://www.cs.auckland.ac.nz/~ulrich/
>>> ****************************************************************
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>
>

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Starlink Digest, Vol 25, Issue 28

[tom]

The newest use case is waiting for a response from AI chatbots. We're
already conditioned to not have this be immediate.

Attributes of this use case are small volumes both up and down but compute
intensity at the datacenter.

-----Original Message-----
From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf Of David
Lang via Starlink
Sent: Thursday, April 20, 2023 6:12 PM
To: Eugene Chang <eugene.chang@alum.mit.edu>
Cc: starlink@lists.bufferbloat.net; David Fernández <davidfdzp@gmail.com>
Subject: Re: [Starlink] Starlink Digest, Vol 25, Issue 28

On Thu, 20 Apr 2023, Eugene Chang via Starlink 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?

1. data like DNS where it really is the same everywhere and changes
relatively slowly so it works well in this environment. (streaming data
could possibly fall in this category, depending on how popular something is)

2. compute loads where you don't get the answer back immediately and can
wait until the next orbit to get the answer (or where the processing time is
large enough that the latency of sending the results around the world when
it's done are small compared to the time it takes to generate the response)
This is not what people think of, as it's not people waiting for the answer
from a browser, but there is a lot more number-crunching than you think.


But yes, there are large categories of servers that this won't work for.

David Lang


> Gene
> -----------------------------------
> Eugene Chang
> 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> 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>
>>> To: "tom@evslin.com" <tom@evslin.com>, 'Michael Richardson'
>>> 	<mcr@sandelman.ca>, 'starlink' <starlink@lists.bufferbloat.net>,
>>> 	"e-impact@ietf.org" <e-impact@ietf.org>
>>> Subject: Re: [Starlink] DataCenters in Space (was Re:  fiber IXPs in
>>> 	space)
>>> Message-ID:
>>> 	
>>> <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>
>>> http://www.cs.auckland.ac.nz/~ulrich/
>>> ****************************************************************
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>
>