Re: [Starlink] fiber IXPs in space

Re: [Starlink] fiber IXPs in space

[David Fernández]

Wondering what benefit would have for any space agency to move its DNS
root server "up there"?

Is GEO an option?

Regards,

David

> Date: Thu, 13 Apr 2023 08:57:47 -0700
> From: Dave Taht <dave.taht@gmail.com>
> To: Dave Taht via Starlink <starlink@lists.bufferbloat.net>
> Subject: [Starlink] fiber IXPs in space
> Message-ID:
> 	<CAA93jw6ES-b_9h0K+wZJ64fB+1T2T8or+WNi9kXjp8w0c248Aw@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> "The Kepler Network will streamline on-orbit communications with a
> network infrastructure designed to act as Internet exchange points
> (IXP) for space-to-space data relay. The Internet-ready constellation
> will deliver data to and from spacecraft in real time, enabling
> high-speed data relay through SDA-standard optical terminals."
>
> https://kepler.space/2023/04/13/kepler-raises-92-million-usd-series-c-to-complete-internet-ready-optical-constellation/
>
> I keep wondering when or if Nasa will find a way to move their DNS
> root server "up there" . DNS data is not all that much... it is the
> original distributed database...
>
>
> --
> AMA March 31: https://www.broadband.io/c/broadband-grant-events/dave-taht
> Dave Täht CEO, TekLibre, LLC
>

Re: [Starlink] fiber IXPs in space

[Michael Richardson]

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


David Fernández via Starlink wrote:
    > Wondering what benefit would have for any space agency to move its DNS
    > root server "up there"?

Probably very little.

    > Is GEO an option?

The delay up to GEO and back is pretty long.
LEO would be better, but doesn't stay in the same place for many.
But, how often do you need to query root name servers if you cache well?

But, advantages that I can see:

1) power.  uninterrupted, disjoint from terrestrial infrastructure.
2) so available all over a hemisphere despite whatever disaster occurs.
3) can answer queries from other space situated systems.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: [Starlink] fiber IXPs in space

[David Fernández]

The delay up to GEO and back is slightly more than half a second.

I am not aware of any space situated systems making DNS queries, are
there any, even proposed?

Maybe for the IPFS?
https://libre.space/2023/04/12/ipfs-tiny/

Regards,

David

2023-04-13 19:22 GMT+02:00, Michael Richardson <mcr@sandelman.ca>:
>
> David Fernández via Starlink wrote:
>     > Wondering what benefit would have for any space agency to move its
> DNS
>     > root server "up there"?
>
> Probably very little.
>
>     > Is GEO an option?
>
> The delay up to GEO and back is pretty long.
> LEO would be better, but doesn't stay in the same place for many.
> But, how often do you need to query root name servers if you cache well?
>
> But, advantages that I can see:
>
> 1) power.  uninterrupted, disjoint from terrestrial infrastructure.
> 2) so available all over a hemisphere despite whatever disaster occurs.
> 3) can answer queries from other space situated systems.
>
>

Re: [Starlink] fiber IXPs in space

[Michael Richardson]

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


David Fernández via Starlink wrote:
    > The delay up to GEO and back is slightly more than half a second.

exactly.

    > I am not aware of any space situated systems making DNS queries, are
    > there any, even proposed?

Someone has to move first before the other systems can think about it...


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: [Starlink] fiber IXPs in space

[Tom Evslin]

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

There are plenty of DNA queries going to starlink Leo's. Shame for them to come back to a gateway. Cache could be in each bird and/ or full server in Leos accessible by iscSent from my phoneTom Evslin@tevslinblog.tomevslin.com
-------- Original message --------From: Michael Richardson via Starlink <starlink@lists.bufferbloat.net> Date: 4/13/23  4:01 PM  (GMT-05:00) To: David Fernández <davidfdzp@gmail.com> Cc: starlink <starlink@lists.bufferbloat.net> Subject: Re: [Starlink] fiber IXPs in space David Fernández via Starlink wrote:    > The delay up to GEO and back is slightly more than half a second.exactly.    > I am not aware of any space situated systems making DNS queries, are    > there any, even proposed?Someone has to move first before the other systems can think about it...

[-- Attachment #2: Type: text/html, Size: 1664 bytes --]

[Starlink] DataCenters in Space (was Re: fiber IXPs in space)

[Michael Richardson]

I saw this reported in BIS-Spaceflight.
(I'm usually a few months behind in reading it)
I like the "first objective"!

https://www.thalesgroup.com/en/worldwide/space/press-release/ascend-thales-alenia-space-lead-european-feasibility-study-data

Cannes, November 14, 2022 – Thales Alenia Space, the joint company between
Thales (67%) and Leonardo (33%), has been chosen by the European Commission
to lead the ASCEND (Advanced Space Cloud for European Net zero emission and
Data sovereignty) feasibility study for data centers in orbit, as part of
Europe’s vast Horizon Europe research program.

Digital technology’s expanding environmental footprint is becoming a major
challenge: the burgeoning need for digitalization means that data centers in
Europe and around the world are growing at an exponential pace, which in turn
has a critical energy and environmental impact.

The first objective of this study will be to assess if the carbon emissions
from the production and launch of these space infrastructures will be
significantly lower than the emissions generated by ground-based data
centers, therefore contributing to the achievement of global carbon
neutrality. The second objective will be to prove that it is possible to
develop the required launch solution and to ensure the deployment and
operability of these spaceborne data centers using robotic assistance
technologies currently being developed in Europe, such as the EROSS IOD
demonstrator.

This project is expected to demonstrate to which extent space-based data
centers would limit the energy and environmental impact of their ground
counterparts, thus allowing major investments within the scope of Europe’s
Green Deal, possibly justifying the development of a more climate-friendly,
reusable heavy launch vehicle. Europe could thus regain its leadership in
space transport and space logistics, as well as the assembly and operations
of large infrastructures in orbit.

Re: [Starlink] DataCenters in Space (was Re: fiber IXPs in space)

[tom]

I think space-based data centers will be the rule rather than the exception. Wrote about that a couple of years ago although, as usual, things have not happened as quickly as I predicted https://blog.tomevslin.com/2021/07/computing-clouds-in-orbit-a-possible-roadmap.html

-----Original Message-----
From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf Of Michael Richardson via Starlink
Sent: Wednesday, April 19, 2023 7:35 PM
To: starlink <starlink@lists.bufferbloat.net>; e-impact@ietf.org
Subject: [Starlink] DataCenters in Space (was Re: fiber IXPs in space)


I saw this reported in BIS-Spaceflight.
(I'm usually a few months behind in reading it) I like the "first objective"!

https://www.thalesgroup.com/en/worldwide/space/press-release/ascend-thales-alenia-space-lead-european-feasibility-study-data

Cannes, November 14, 2022 – Thales Alenia Space, the joint company between Thales (67%) and Leonardo (33%), has been chosen by the European Commission to lead the ASCEND (Advanced Space Cloud for European Net zero emission and Data sovereignty) feasibility study for data centers in orbit, as part of Europe’s vast Horizon Europe research program.

Digital technology’s expanding environmental footprint is becoming a major
challenge: the burgeoning need for digitalization means that data centers in Europe and around the world are growing at an exponential pace, which in turn has a critical energy and environmental impact.

The first objective of this study will be to assess if the carbon emissions from the production and launch of these space infrastructures will be significantly lower than the emissions generated by ground-based data centers, therefore contributing to the achievement of global carbon neutrality. The second objective will be to prove that it is possible to develop the required launch solution and to ensure the deployment and operability of these spaceborne data centers using robotic assistance technologies currently being developed in Europe, such as the EROSS IOD demonstrator.

This project is expected to demonstrate to which extent space-based data centers would limit the energy and environmental impact of their ground counterparts, thus allowing major investments within the scope of Europe’s Green Deal, possibly justifying the development of a more climate-friendly, reusable heavy launch vehicle. Europe could thus regain its leadership in space transport and space logistics, as well as the assembly and operations of large infrastructures in orbit.

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

Re: [Starlink] DataCenters in Space (was Re: fiber IXPs in space)

[Vint Cerf]

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

O&M will be a bear
v


On Wed, Apr 19, 2023 at 9:13 PM Tom Evslin via Starlink <
starlink@lists.bufferbloat.net> wrote:

> I think space-based data centers will be the rule rather than the
> exception. Wrote about that a couple of years ago although, as usual,
> things have not happened as quickly as I predicted
> https://blog.tomevslin.com/2021/07/computing-clouds-in-orbit-a-possible-roadmap.html
>
> -----Original Message-----
> From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf Of
> Michael Richardson via Starlink
> Sent: Wednesday, April 19, 2023 7:35 PM
> To: starlink <starlink@lists.bufferbloat.net>; e-impact@ietf.org
> Subject: [Starlink] DataCenters in Space (was Re: fiber IXPs in space)
>
>
> I saw this reported in BIS-Spaceflight.
> (I'm usually a few months behind in reading it) I like the "first
> objective"!
>
>
> https://www.thalesgroup.com/en/worldwide/space/press-release/ascend-thales-alenia-space-lead-european-feasibility-study-data
>
> Cannes, November 14, 2022 – Thales Alenia Space, the joint company between
> Thales (67%) and Leonardo (33%), has been chosen by the European Commission
> to lead the ASCEND (Advanced Space Cloud for European Net zero emission and
> Data sovereignty) feasibility study for data centers in orbit, as part of
> Europe’s vast Horizon Europe research program.
>
> Digital technology’s expanding environmental footprint is becoming a major
> challenge: the burgeoning need for digitalization means that data centers
> in Europe and around the world are growing at an exponential pace, which in
> turn has a critical energy and environmental impact.
>
> The first objective of this study will be to assess if the carbon
> emissions from the production and launch of these space infrastructures
> will be significantly lower than the emissions generated by ground-based
> data centers, therefore contributing to the achievement of global carbon
> neutrality. The second objective will be to prove that it is possible to
> develop the required launch solution and to ensure the deployment and
> operability of these spaceborne data centers using robotic assistance
> technologies currently being developed in Europe, such as the EROSS IOD
> demonstrator.
>
> This project is expected to demonstrate to which extent space-based data
> centers would limit the energy and environmental impact of their ground
> counterparts, thus allowing major investments within the scope of Europe’s
> Green Deal, possibly justifying the development of a more climate-friendly,
> reusable heavy launch vehicle. Europe could thus regain its leadership in
> space transport and space logistics, as well as the assembly and operations
> of large infrastructures in orbit.
>
> _______________________________________________
> 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
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346


until further notice

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

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

Re: [Starlink] [E-impact] DataCenters in Space (was Re: fiber IXPs in space)

[Hesham ElBakoury]

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

Here is an interesting article about DC in space to mitigate power
consumption.
https://www.google.com/amp/s/english.elpais.com/science-tech/2022-12-28/data-centers-move-into-space-to-mitigate-power-consumption-and-pollution.html%3foutputType=amp

Hesham

On Wed, Apr 19, 2023, 8:06 PM Toerless Eckert <tte@cs.fau.de> wrote:

> I am looking forward to "Space Cowboys 2 - Data Center Edition"
>
> On Wed, Apr 19, 2023 at 09:16:38PM -0400, Vint Cerf wrote:
> > O&M will be a bear
> > v
> >
> >
> > On Wed, Apr 19, 2023 at 9:13 PM Tom Evslin via Starlink <
> > starlink@lists.bufferbloat.net> wrote:
> >
> > > I think space-based data centers will be the rule rather than the
> > > exception. Wrote about that a couple of years ago although, as usual,
> > > things have not happened as quickly as I predicted
> > >
> https://blog.tomevslin.com/2021/07/computing-clouds-in-orbit-a-possible-roadmap.html
> > >
> > > -----Original Message-----
> > > From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf Of
> > > Michael Richardson via Starlink
> > > Sent: Wednesday, April 19, 2023 7:35 PM
> > > To: starlink <starlink@lists.bufferbloat.net>; e-impact@ietf.org
> > > Subject: [Starlink] DataCenters in Space (was Re: fiber IXPs in space)
> > >
> > >
> > > I saw this reported in BIS-Spaceflight.
> > > (I'm usually a few months behind in reading it) I like the "first
> > > objective"!
> > >
> > >
> > >
> https://www.thalesgroup.com/en/worldwide/space/press-release/ascend-thales-alenia-space-lead-european-feasibility-study-data
> > >
> > > Cannes, November 14, 2022 – Thales Alenia Space, the joint company
> between
> > > Thales (67%) and Leonardo (33%), has been chosen by the European
> Commission
> > > to lead the ASCEND (Advanced Space Cloud for European Net zero
> emission and
> > > Data sovereignty) feasibility study for data centers in orbit, as part
> of
> > > Europe’s vast Horizon Europe research program.
> > >
> > > Digital technology’s expanding environmental footprint is becoming a
> major
> > > challenge: the burgeoning need for digitalization means that data
> centers
> > > in Europe and around the world are growing at an exponential pace,
> which in
> > > turn has a critical energy and environmental impact.
> > >
> > > The first objective of this study will be to assess if the carbon
> > > emissions from the production and launch of these space infrastructures
> > > will be significantly lower than the emissions generated by
> ground-based
> > > data centers, therefore contributing to the achievement of global
> carbon
> > > neutrality. The second objective will be to prove that it is possible
> to
> > > develop the required launch solution and to ensure the deployment and
> > > operability of these spaceborne data centers using robotic assistance
> > > technologies currently being developed in Europe, such as the EROSS IOD
> > > demonstrator.
> > >
> > > This project is expected to demonstrate to which extent space-based
> data
> > > centers would limit the energy and environmental impact of their ground
> > > counterparts, thus allowing major investments within the scope of
> Europe’s
> > > Green Deal, possibly justifying the development of a more
> climate-friendly,
> > > reusable heavy launch vehicle. Europe could thus regain its leadership
> in
> > > space transport and space logistics, as well as the assembly and
> operations
> > > of large infrastructures in orbit.
> > >
> > > _______________________________________________
> > > 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
> > Google, LLC
> > 1900 Reston Metro Plaza, 16th Floor
> > Reston, VA 20190
> > +1 (571) 213 1346
> >
> >
> > until further notice
>
> --
> E-impact mailing list
> E-impact@ietf.org
> https://www.ietf.org/mailman/listinfo/e-impact
>

[-- Attachment #2: Type: text/html, Size: 6536 bytes --]

Re: [Starlink] [E-impact] DataCenters in Space (was Re: fiber IXPs in space)

[Daniel Schien]

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

I assume any object in orbit will be hidden from the sun some of the time. So, the machines will require some pretty big battery to go up with them.

I'd like to also know what the launch cost is.

Tom Segert estimates in his LinkedIn post, for a 100kg satellite payload:

"TL:DR ~57 ton CO2e for a typical ESA satellite (including Ariane 6 launch), <15t CO2e for a satellite built in a factory and launched with a re-usable rocket."

Depending on the type of server that should go up there, this is a fair amount of carbon to offset from brighter sunlight.

The article also gets the carbon footprint wrong:

"Data centers are big energy consumers – between 2% and 3% of all global consumption – a rate that is doubling every year."

The latest was IEA estimating it to be around 220-320 TWh (out of 30,000) in 2021 data and growing between 10-60% over 6 years in total (so let's than 10 CAGR). But it's certainly not doubling every year. That's just completely wrong.


Daniel Schien

Senior Lecturer in Computer Science

Department of Computer Science | University of Bristol

Submit software engineering project ideas for 2022

bris.ac.uk/software-engineering
Watch: https://youtu.be/lU-ZsBDFWDI

Merchant Venturers Building , Woodland Rd Bristol, BS8 1UB
Book a meeting: https://outlook.office365.com/owa/calendar/OfficeHours@bristol.ac.uk/booki<https://outlook.office365.com/owa/calendar/OfficeHours@bristol.ac.uk/bookings/>

________________________________
From: E-impact <e-impact-bounces@ietf.org> on behalf of Vint Cerf <vint=40google.com@dmarc.ietf.org>
Sent: Thursday, April 20, 2023 2:16:38 AM
To: tom@evslin.com <tom@evslin.com>
Cc: Michael Richardson <mcr@sandelman.ca>; starlink <starlink@lists.bufferbloat.net>; e-impact@ietf.org <e-impact@ietf.org>
Subject: Re: [E-impact] [Starlink] DataCenters in Space (was Re: fiber IXPs in space)

O&M will be a bear
v


On Wed, Apr 19, 2023 at 9:13 PM Tom Evslin via Starlink <starlink@lists.bufferbloat.net<mailto:starlink@lists.bufferbloat.net>> wrote:
I think space-based data centers will be the rule rather than the exception. Wrote about that a couple of years ago although, as usual, things have not happened as quickly as I predicted https://blog.tomevslin.com/2021/07/computing-clouds-in-orbit-a-possible-roadmap.html

-----Original Message-----
From: Starlink <starlink-bounces@lists.bufferbloat.net<mailto:starlink-bounces@lists.bufferbloat.net>> On Behalf Of Michael Richardson via Starlink
Sent: Wednesday, April 19, 2023 7:35 PM
To: starlink <starlink@lists.bufferbloat.net<mailto:starlink@lists.bufferbloat.net>>; e-impact@ietf.org<mailto:e-impact@ietf.org>
Subject: [Starlink] DataCenters in Space (was Re: fiber IXPs in space)


I saw this reported in BIS-Spaceflight.
(I'm usually a few months behind in reading it) I like the "first objective"!

https://www.thalesgroup.com/en/worldwide/space/press-release/ascend-thales-alenia-space-lead-european-feasibility-study-data

Cannes, November 14, 2022 – Thales Alenia Space, the joint company between Thales (67%) and Leonardo (33%), has been chosen by the European Commission to lead the ASCEND (Advanced Space Cloud for European Net zero emission and Data sovereignty) feasibility study for data centers in orbit, as part of Europe’s vast Horizon Europe research program.

Digital technology’s expanding environmental footprint is becoming a major
challenge: the burgeoning need for digitalization means that data centers in Europe and around the world are growing at an exponential pace, which in turn has a critical energy and environmental impact.

The first objective of this study will be to assess if the carbon emissions from the production and launch of these space infrastructures will be significantly lower than the emissions generated by ground-based data centers, therefore contributing to the achievement of global carbon neutrality. The second objective will be to prove that it is possible to develop the required launch solution and to ensure the deployment and operability of these spaceborne data centers using robotic assistance technologies currently being developed in Europe, such as the EROSS IOD demonstrator.

This project is expected to demonstrate to which extent space-based data centers would limit the energy and environmental impact of their ground counterparts, thus allowing major investments within the scope of Europe’s Green Deal, possibly justifying the development of a more climate-friendly, reusable heavy launch vehicle. Europe could thus regain its leadership in space transport and space logistics, as well as the assembly and operations of large infrastructures in orbit.

_______________________________________________
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<mailto:Starlink@lists.bufferbloat.net>
https://lists.bufferbloat.net/listinfo/starlink


--
Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346


until further notice




[-- Attachment #2: Type: text/html, Size: 10956 bytes --]

Re: [Starlink] [E-impact] DataCenters in Space (was Re: fiber IXPs in space)

[Chris Adams]

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

Hi folks,

Is there a link to the underlying assumptions in for this "data centres in space” story or the report?

The press release mentioned solar powerplants generating several hundred megawatts. That would require a massive amount of solar!

For context, this list here shows the largest solar plants in the US, as of June 2021:

https://list.solar/plants/largest-plants/solar-plants-usa/

Even the smallest one, kicking out 200 Megawatts has a surface areas of 5.1 square kilometers, and it only goes upward from there.

For this to be plausible, you’d need panels to be orders of magnitude more efficient than they are on land when in space, even before you think about how heavy it would be get multiple square kilometres of solar panel into orbit.

C



Chris Adams

Executive Director

w: thegreenwebfoundation.org
e: chris@thegreenwebfoundation.org
t: @mrchrisadams

German Office
Naunynstrasse 40
10999 Berlin
Germany

See our contact page for more details
https://www.thegreenwebfoundation.org/contact/

Book a short call with me to discuss something.
https://cal.com/mrchrisadams
Chris Adams

Executive Director

w: thegreenwebfoundation.org
e: chris@thegreenwebfoundation.org
t: @mrchrisadams

German Office
Naunynstrasse 40
10999 Berlin
Germany

See our contact page for more details
https://www.thegreenwebfoundation.org/contact/

Book a short call with me to discuss something.
https://cal.com/mrchrisadams


> On 20. Apr 2023, at 07:43, Daniel Schien <Daniel.Schien@bristol.ac.uk> wrote:
> 
> I assume any object in orbit will be hidden from the sun some of the time. So, the machines will require some pretty big battery to go up with them. 
> 
> I'd like to also know what the launch cost is. 
> 
> Tom Segert estimates in his LinkedIn post, for a 100kg satellite payload:
> 
> "TL:DR ~57 ton CO2e for a typical ESA satellite (including Ariane 6 launch), <15t CO2e for a satellite built in a factory and launched with a re-usable rocket."
> 
> Depending on the type of server that should go up there, this is a fair amount of carbon to offset from brighter sunlight.
> 
> The article also gets the carbon footprint wrong:
> 
> "Data centers are big energy consumers – between 2% and 3% of all global consumption – a rate that is doubling every year."
> 
> The latest was IEA estimating it to be around 220-320 TWh (out of 30,000) in 2021 data and growing between 10-60% over 6 years in total (so let's than 10 CAGR). But it's certainly not doubling every year. That's just completely wrong.
> 
> 
> Daniel Schien
> Senior Lecturer in Computer Science
> Department of Computer Science | University of Bristol
> Submit software engineering project ideas for 2022
> 
> bris.ac.uk/software-engineering <>
> Watch: https://youtu.be/lU-ZsBDFWDI
> 
> Merchant Venturers Building , Woodland Rd Bristol, BS8 1UB
> Book a meeting: https://outlook.office365.com/owa/calendar/OfficeHours@bristol.ac.uk/booki <https://outlook.office365.com/owa/calendar/OfficeHours@bristol.ac.uk/bookings/>
> From: E-impact <e-impact-bounces@ietf.org> on behalf of Vint Cerf <vint=40google.com@dmarc.ietf.org>
> Sent: Thursday, April 20, 2023 2:16:38 AM
> To: tom@evslin.com <tom@evslin.com>
> Cc: Michael Richardson <mcr@sandelman.ca>; starlink <starlink@lists.bufferbloat.net>; e-impact@ietf.org <e-impact@ietf.org>
> Subject: Re: [E-impact] [Starlink] DataCenters in Space (was Re: fiber IXPs in space)
>  
> O&M will be a bear
> v
> 
> 
> On Wed, Apr 19, 2023 at 9:13 PM Tom Evslin via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>> wrote:
> I think space-based data centers will be the rule rather than the exception. Wrote about that a couple of years ago although, as usual, things have not happened as quickly as I predicted https://blog.tomevslin.com/2021/07/computing-clouds-in-orbit-a-possible-roadmap.html
> 
> -----Original Message-----
> From: Starlink <starlink-bounces@lists.bufferbloat.net <mailto:starlink-bounces@lists.bufferbloat.net>> On Behalf Of Michael Richardson via Starlink
> Sent: Wednesday, April 19, 2023 7:35 PM
> To: starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>>; e-impact@ietf.org <mailto:e-impact@ietf.org>
> Subject: [Starlink] DataCenters in Space (was Re: fiber IXPs in space)
> 
> 
> I saw this reported in BIS-Spaceflight.
> (I'm usually a few months behind in reading it) I like the "first objective"!
> 
> https://www.thalesgroup.com/en/worldwide/space/press-release/ascend-thales-alenia-space-lead-european-feasibility-study-data
> 
> Cannes, November 14, 2022 – Thales Alenia Space, the joint company between Thales (67%) and Leonardo (33%), has been chosen by the European Commission to lead the ASCEND (Advanced Space Cloud for European Net zero emission and Data sovereignty) feasibility study for data centers in orbit, as part of Europe’s vast Horizon Europe research program.
> 
> Digital technology’s expanding environmental footprint is becoming a major
> challenge: the burgeoning need for digitalization means that data centers in Europe and around the world are growing at an exponential pace, which in turn has a critical energy and environmental impact.
> 
> The first objective of this study will be to assess if the carbon emissions from the production and launch of these space infrastructures will be significantly lower than the emissions generated by ground-based data centers, therefore contributing to the achievement of global carbon neutrality. The second objective will be to prove that it is possible to develop the required launch solution and to ensure the deployment and operability of these spaceborne data centers using robotic assistance technologies currently being developed in Europe, such as the EROSS IOD demonstrator.
> 
> This project is expected to demonstrate to which extent space-based data centers would limit the energy and environmental impact of their ground counterparts, thus allowing major investments within the scope of Europe’s Green Deal, possibly justifying the development of a more climate-friendly, reusable heavy launch vehicle. Europe could thus regain its leadership in space transport and space logistics, as well as the assembly and operations of large infrastructures in orbit.
> 
> _______________________________________________
> 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 <mailto:Starlink@lists.bufferbloat.net>
> https://lists.bufferbloat.net/listinfo/starlink
> 
> 
> -- 
> Please send any postal/overnight deliveries to:
> Vint Cerf
> Google, LLC
> 1900 Reston Metro Plaza, 16th Floor
> Reston, VA 20190
> +1 (571) 213 1346
> 
> 
> until further notice
> 
> 
> 
> -- 
> E-impact mailing list
> E-impact@ietf.org
> https://www.ietf.org/mailman/listinfo/e-impact


[-- Attachment #2: Type: text/html, Size: 13369 bytes --]

Re: [Starlink] [E-impact] DataCenters in Space (was Re: fiber IXPs in space)

[Hesham ElBakoury]

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

There is a white paper on DC in space:
https://go.avalanchetechnology.com/datacenters-in-space-whitepaper

Hesham

On Thu, Apr 20, 2023, 2:32 AM Chris Adams <chris@thegreenwebfoundation.org>
wrote:

> Hi folks,
>
> Is there a link to the underlying assumptions in for this "data centres in
> space” story or the report?
>
> The press release mentioned *solar powerplants generating several hundred
> megawatts*. That would require a *massive* amount of solar!
>
> For context, this list here shows the largest solar plants in the US, as
> of June 2021:
>
> https://list.solar/plants/largest-plants/solar-plants-usa/
>
> Even the smallest one, kicking out 200 Megawatts has a surface areas of
> 5.1 square kilometers, and it only goes upward from there.
>
> For this to be plausible, you’d need panels to be orders of magnitude more
> efficient than they are on land when in space, even before you think about
> how heavy it would be get multiple square kilometres of solar panel into
> orbit.
>
> C
>
>
>
> Chris Adams
>
> Executive Director
>
> w: thegreenwebfoundation.org
> e: chris@thegreenwebfoundation.org
> t: @mrchrisadams
>
> German Office
> Naunynstrasse 40
> 10999 Berlin
> Germany
>
> See our contact page for more details
> https://www.thegreenwebfoundation.org/contact/
>
> Book a short call with me to discuss something.
> https://cal.com/mrchrisadams
> Chris Adams
>
> Executive Director
>
> w: thegreenwebfoundation.org
> e: chris@thegreenwebfoundation.org
> t: @mrchrisadams
>
> German Office
> Naunynstrasse 40
> 10999 Berlin
> Germany
>
> See our contact page for more details
> https://www.thegreenwebfoundation.org/contact/
>
> Book a short call with me to discuss something.
> https://cal.com/mrchrisadams
>
>
> On 20. Apr 2023, at 07:43, Daniel Schien <Daniel.Schien@bristol.ac.uk>
> wrote:
>
> I assume any object in orbit will be hidden from the sun some of the time.
> So, the machines will require some pretty big battery to go up with them.
>
> I'd like to also know what the launch cost is.
>
> Tom Segert estimates in his LinkedIn post, for a 100kg satellite payload:
>
> "TL:DR ~57 ton CO2e for a typical ESA satellite (including Ariane 6
> launch), <15t CO2e for a satellite built in a factory and launched with a
> re-usable rocket."
>
> Depending on the type of server that should go up there, this is a fair
> amount of carbon to offset from brighter sunlight.
>
> The article also gets the carbon footprint wrong:
>
> "Data centers are big energy consumers – between 2% and 3% of all global
> consumption – a rate that is doubling every year."
>
> The latest was IEA estimating it to be around 220-320 TWh (out of 30,000)
> in 2021 data and growing between 10-60% over 6 years in total (so let's
> than 10 CAGR). But it's certainly not doubling every year. That's just
> completely wrong.
>
>
> Daniel Schien
> Senior Lecturer in Computer Science
> Department of Computer Science | University of Bristol
> *Submit software engineering project ideas for 2022*
>
> bris.ac.uk/software-engineering
> Watch: https://youtu.be/lU-ZsBDFWDI
>
> Merchant Venturers Building , Woodland Rd Bristol, BS8 1UB
> *Book a meeting*:
> https://outlook.office365.com/owa/calendar/OfficeHours@bristol.ac.uk/booki
> <https://outlook.office365.com/owa/calendar/OfficeHours@bristol.ac.uk/bookings/>
> ------------------------------
> *From:* E-impact <e-impact-bounces@ietf.org> on behalf of Vint Cerf <vint=
> 40google.com@dmarc.ietf.org>
> *Sent:* Thursday, April 20, 2023 2:16:38 AM
> *To:* tom@evslin.com <tom@evslin.com>
> *Cc:* Michael Richardson <mcr@sandelman.ca>; starlink <
> starlink@lists.bufferbloat.net>; e-impact@ietf.org <e-impact@ietf.org>
> *Subject:* Re: [E-impact] [Starlink] DataCenters in Space (was Re: fiber
> IXPs in space)
>
> O&M will be a bear
> v
>
>
> On Wed, Apr 19, 2023 at 9:13 PM Tom Evslin via Starlink <
> starlink@lists.bufferbloat.net> wrote:
>
> I think space-based data centers will be the rule rather than the
> exception. Wrote about that a couple of years ago although, as usual,
> things have not happened as quickly as I predicted
> https://blog.tomevslin.com/2021/07/computing-clouds-in-orbit-a-possible-roadmap.html
>
> -----Original Message-----
> From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf Of
> Michael Richardson via Starlink
> Sent: Wednesday, April 19, 2023 7:35 PM
> To: starlink <starlink@lists.bufferbloat.net>; e-impact@ietf.org
> Subject: [Starlink] DataCenters in Space (was Re: fiber IXPs in space)
>
>
> I saw this reported in BIS-Spaceflight.
> (I'm usually a few months behind in reading it) I like the "first
> objective"!
>
>
> https://www.thalesgroup.com/en/worldwide/space/press-release/ascend-thales-alenia-space-lead-european-feasibility-study-data
>
> Cannes, November 14, 2022 – Thales Alenia Space, the joint company between
> Thales (67%) and Leonardo (33%), has been chosen by the European Commission
> to lead the ASCEND (Advanced Space Cloud for European Net zero emission and
> Data sovereignty) feasibility study for data centers in orbit, as part of
> Europe’s vast Horizon Europe research program.
>
> Digital technology’s expanding environmental footprint is becoming a major
> challenge: the burgeoning need for digitalization means that data centers
> in Europe and around the world are growing at an exponential pace, which in
> turn has a critical energy and environmental impact.
>
> The first objective of this study will be to assess if the carbon
> emissions from the production and launch of these space infrastructures
> will be significantly lower than the emissions generated by ground-based
> data centers, therefore contributing to the achievement of global carbon
> neutrality. The second objective will be to prove that it is possible to
> develop the required launch solution and to ensure the deployment and
> operability of these spaceborne data centers using robotic assistance
> technologies currently being developed in Europe, such as the EROSS IOD
> demonstrator.
>
> This project is expected to demonstrate to which extent space-based data
> centers would limit the energy and environmental impact of their ground
> counterparts, thus allowing major investments within the scope of Europe’s
> Green Deal, possibly justifying the development of a more climate-friendly,
> reusable heavy launch vehicle. Europe could thus regain its leadership in
> space transport and space logistics, as well as the assembly and operations
> of large infrastructures in orbit.
>
> _______________________________________________
> 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
> Google, LLC
> 1900 Reston Metro Plaza, 16th Floor
> Reston, VA 20190
> +1 (571) 213 1346
>
>
> until further notice
>
>
>
> --
> E-impact mailing list
> E-impact@ietf.org
> https://www.ietf.org/mailman/listinfo/e-impact
>
>
> --
> E-impact mailing list
> E-impact@ietf.org
> https://www.ietf.org/mailman/listinfo/e-impact
>

[-- Attachment #2: Type: text/html, Size: 15095 bytes --]

Re: [Starlink] [E-impact] DataCenters in Space (was Re: fiber IXPs in space)

[Hesham ElBakoury]

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

Sorry for the typo. The link to the white paper is
https://go.avalanche-technology.com/datacenters-in-space-whitepaper

Hesham

On Thu, Apr 20, 2023, 5:50 AM Hesham ElBakoury <helbakoury@gmail.com> wrote:

> There is a white paper on DC in space:
> https://go.avalanchetechnology.com/datacenters-in-space-whitepaper
>
> Hesham
>
> On Thu, Apr 20, 2023, 2:32 AM Chris Adams <chris@thegreenwebfoundation.org>
> wrote:
>
>> Hi folks,
>>
>> Is there a link to the underlying assumptions in for this "data centres
>> in space” story or the report?
>>
>> The press release mentioned *solar powerplants generating several
>> hundred megawatts*. That would require a *massive* amount of solar!
>>
>> For context, this list here shows the largest solar plants in the US, as
>> of June 2021:
>>
>> https://list.solar/plants/largest-plants/solar-plants-usa/
>>
>> Even the smallest one, kicking out 200 Megawatts has a surface areas of
>> 5.1 square kilometers, and it only goes upward from there.
>>
>> For this to be plausible, you’d need panels to be orders of magnitude
>> more efficient than they are on land when in space, even before you think
>> about how heavy it would be get multiple square kilometres of solar panel
>> into orbit.
>>
>> C
>>
>>
>>
>> Chris Adams
>>
>> Executive Director
>>
>> w: thegreenwebfoundation.org
>> e: chris@thegreenwebfoundation.org
>> t: @mrchrisadams
>>
>> German Office
>> Naunynstrasse 40
>> 10999 Berlin
>> Germany
>>
>> See our contact page for more details
>> https://www.thegreenwebfoundation.org/contact/
>>
>> Book a short call with me to discuss something.
>> https://cal.com/mrchrisadams
>> Chris Adams
>>
>> Executive Director
>>
>> w: thegreenwebfoundation.org
>> e: chris@thegreenwebfoundation.org
>> t: @mrchrisadams
>>
>> German Office
>> Naunynstrasse 40
>> 10999 Berlin
>> Germany
>>
>> See our contact page for more details
>> https://www.thegreenwebfoundation.org/contact/
>>
>> Book a short call with me to discuss something.
>> https://cal.com/mrchrisadams
>>
>>
>> On 20. Apr 2023, at 07:43, Daniel Schien <Daniel.Schien@bristol.ac.uk>
>> wrote:
>>
>> I assume any object in orbit will be hidden from the sun some of the
>> time. So, the machines will require some pretty big battery to go up with
>> them.
>>
>> I'd like to also know what the launch cost is.
>>
>> Tom Segert estimates in his LinkedIn post, for a 100kg satellite payload:
>>
>> "TL:DR ~57 ton CO2e for a typical ESA satellite (including Ariane 6
>> launch), <15t CO2e for a satellite built in a factory and launched with a
>> re-usable rocket."
>>
>> Depending on the type of server that should go up there, this is a fair
>> amount of carbon to offset from brighter sunlight.
>>
>> The article also gets the carbon footprint wrong:
>>
>> "Data centers are big energy consumers – between 2% and 3% of all global
>> consumption – a rate that is doubling every year."
>>
>> The latest was IEA estimating it to be around 220-320 TWh (out of 30,000)
>> in 2021 data and growing between 10-60% over 6 years in total (so let's
>> than 10 CAGR). But it's certainly not doubling every year. That's just
>> completely wrong.
>>
>>
>> Daniel Schien
>> Senior Lecturer in Computer Science
>> Department of Computer Science | University of Bristol
>> *Submit software engineering project ideas for 2022*
>>
>> bris.ac.uk/software-engineering
>> Watch: https://youtu.be/lU-ZsBDFWDI
>>
>> Merchant Venturers Building , Woodland Rd Bristol, BS8 1UB
>> *Book a meeting*:
>> https://outlook.office365.com/owa/calendar/OfficeHours@bristol.ac.uk/booki
>> <https://outlook.office365.com/owa/calendar/OfficeHours@bristol.ac.uk/bookings/>
>> ------------------------------
>> *From:* E-impact <e-impact-bounces@ietf.org> on behalf of Vint Cerf
>> <vint=40google.com@dmarc.ietf.org>
>> *Sent:* Thursday, April 20, 2023 2:16:38 AM
>> *To:* tom@evslin.com <tom@evslin.com>
>> *Cc:* Michael Richardson <mcr@sandelman.ca>; starlink <
>> starlink@lists.bufferbloat.net>; e-impact@ietf.org <e-impact@ietf.org>
>> *Subject:* Re: [E-impact] [Starlink] DataCenters in Space (was Re: fiber
>> IXPs in space)
>>
>> O&M will be a bear
>> v
>>
>>
>> On Wed, Apr 19, 2023 at 9:13 PM Tom Evslin via Starlink <
>> starlink@lists.bufferbloat.net> wrote:
>>
>> I think space-based data centers will be the rule rather than the
>> exception. Wrote about that a couple of years ago although, as usual,
>> things have not happened as quickly as I predicted
>> https://blog.tomevslin.com/2021/07/computing-clouds-in-orbit-a-possible-roadmap.html
>>
>> -----Original Message-----
>> From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf Of
>> Michael Richardson via Starlink
>> Sent: Wednesday, April 19, 2023 7:35 PM
>> To: starlink <starlink@lists.bufferbloat.net>; e-impact@ietf.org
>> Subject: [Starlink] DataCenters in Space (was Re: fiber IXPs in space)
>>
>>
>> I saw this reported in BIS-Spaceflight.
>> (I'm usually a few months behind in reading it) I like the "first
>> objective"!
>>
>>
>> https://www.thalesgroup.com/en/worldwide/space/press-release/ascend-thales-alenia-space-lead-european-feasibility-study-data
>>
>> Cannes, November 14, 2022 – Thales Alenia Space, the joint company
>> between Thales (67%) and Leonardo (33%), has been chosen by the European
>> Commission to lead the ASCEND (Advanced Space Cloud for European Net zero
>> emission and Data sovereignty) feasibility study for data centers in orbit,
>> as part of Europe’s vast Horizon Europe research program.
>>
>> Digital technology’s expanding environmental footprint is becoming a major
>> challenge: the burgeoning need for digitalization means that data centers
>> in Europe and around the world are growing at an exponential pace, which in
>> turn has a critical energy and environmental impact.
>>
>> The first objective of this study will be to assess if the carbon
>> emissions from the production and launch of these space infrastructures
>> will be significantly lower than the emissions generated by ground-based
>> data centers, therefore contributing to the achievement of global carbon
>> neutrality. The second objective will be to prove that it is possible to
>> develop the required launch solution and to ensure the deployment and
>> operability of these spaceborne data centers using robotic assistance
>> technologies currently being developed in Europe, such as the EROSS IOD
>> demonstrator.
>>
>> This project is expected to demonstrate to which extent space-based data
>> centers would limit the energy and environmental impact of their ground
>> counterparts, thus allowing major investments within the scope of Europe’s
>> Green Deal, possibly justifying the development of a more climate-friendly,
>> reusable heavy launch vehicle. Europe could thus regain its leadership in
>> space transport and space logistics, as well as the assembly and operations
>> of large infrastructures in orbit.
>>
>> _______________________________________________
>> 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
>> Google, LLC
>> 1900 Reston Metro Plaza, 16th Floor
>> Reston, VA 20190
>> +1 (571) 213 1346
>>
>>
>> until further notice
>>
>>
>>
>> --
>> E-impact mailing list
>> E-impact@ietf.org
>> https://www.ietf.org/mailman/listinfo/e-impact
>>
>>
>> --
>> E-impact mailing list
>> E-impact@ietf.org
>> https://www.ietf.org/mailman/listinfo/e-impact
>>
>

[-- Attachment #2: Type: text/html, Size: 16185 bytes --]

Re: [Starlink] [E-impact] DataCenters in Space (was Re: fiber IXPs in space)

[Eugene Y Chang]

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

Wow … 5.1 square kilometer of solar panels.
It is going to be really good at catching micrometeorites and small space debris.
A few small nicks won’t matter. Should we care?

The James Webb already caught a few in it’s mirror. So far it wasn’t serious.

Gene
----------------------------------------------
Eugene Chang
IEEE Communications Society & Signal Processing Society,
    Hawaii Chapter Chair
IEEE Hawaii Section, Industry Engagement Coordinator
IEEE Senior Life Member
eugene.chang@ieee.org
m 781-799-0233 (in Honolulu)



> On Apr 19, 2023, at 11:31 PM, Chris Adams via Starlink <starlink@lists.bufferbloat.net> wrote:
> 
> Hi folks,
> 
> Is there a link to the underlying assumptions in for this "data centres in space” story or the report?
> 
> The press release mentioned solar powerplants generating several hundred megawatts. That would require a massive amount of solar!
> 
> For context, this list here shows the largest solar plants in the US, as of June 2021:
> 
> https://list.solar/plants/largest-plants/solar-plants-usa/ <https://list.solar/plants/largest-plants/solar-plants-usa/>
> 
> Even the smallest one, kicking out 200 Megawatts has a surface areas of 5.1 square kilometers, and it only goes upward from there.
> 
> For this to be plausible, you’d need panels to be orders of magnitude more efficient than they are on land when in space, even before you think about how heavy it would be get multiple square kilometres of solar panel into orbit.
> 
> C
> 
> 
> 
> Chris Adams
> 
> Executive Director
> 
> w: thegreenwebfoundation.org
> e: chris@thegreenwebfoundation.org
> t: @mrchrisadams
> 
> German Office
> Naunynstrasse 40
> 10999 Berlin
> Germany
> 
> See our contact page for more details
> https://www.thegreenwebfoundation.org/contact/ <https://www.thegreenwebfoundation.org/contact/>
> 
> Book a short call with me to discuss something.
> https://cal.com/mrchrisadams <https://cal.com/mrchrisadams>
> Chris Adams
> 
> Executive Director
> 
> w: thegreenwebfoundation.org
> e: chris@thegreenwebfoundation.org
> t: @mrchrisadams
> 
> German Office
> Naunynstrasse 40
> 10999 Berlin
> Germany
> 
> See our contact page for more details
> https://www.thegreenwebfoundation.org/contact/ <https://www.thegreenwebfoundation.org/contact/>
> 
> Book a short call with me to discuss something.
> https://cal.com/mrchrisadams <https://cal.com/mrchrisadams>
> 
> 
>> On 20. Apr 2023, at 07:43, Daniel Schien <Daniel.Schien@bristol.ac.uk> wrote:
>> 
>> I assume any object in orbit will be hidden from the sun some of the time. So, the machines will require some pretty big battery to go up with them.
>> 
>> I'd like to also know what the launch cost is.
>> 
>> Tom Segert estimates in his LinkedIn post, for a 100kg satellite payload:
>> 
>> "TL:DR ~57 ton CO2e for a typical ESA satellite (including Ariane 6 launch), <15t CO2e for a satellite built in a factory and launched with a re-usable rocket."
>> 
>> Depending on the type of server that should go up there, this is a fair amount of carbon to offset from brighter sunlight.
>> 
>> The article also gets the carbon footprint wrong:
>> 
>> "Data centers are big energy consumers – between 2% and 3% of all global consumption – a rate that is doubling every year."
>> 
>> The latest was IEA estimating it to be around 220-320 TWh (out of 30,000) in 2021 data and growing between 10-60% over 6 years in total (so let's than 10 CAGR). But it's certainly not doubling every year. That's just completely wrong.
>> 
>> 
>> Daniel Schien
>> Senior Lecturer in Computer Science
>> Department of Computer Science | University of Bristol
>> Submit software engineering project ideas for 2022
>> 
>> bris.ac.uk/software-engineering <>
>> Watch: https://youtu.be/lU-ZsBDFWDI <https://youtu.be/lU-ZsBDFWDI>
>> 
>> Merchant Venturers Building , Woodland Rd Bristol, BS8 1UB
>> Book a meeting: https://outlook.office365.com/owa/calendar/OfficeHours@bristol.ac.uk/booki <https://outlook.office365.com/owa/calendar/OfficeHours@bristol.ac.uk/bookings/>
>> From: E-impact <e-impact-bounces@ietf.org> on behalf of Vint Cerf <vint=40google.com@dmarc.ietf.org>
>> Sent: Thursday, April 20, 2023 2:16:38 AM
>> To: tom@evslin.com <tom@evslin.com>
>> Cc: Michael Richardson <mcr@sandelman.ca>; starlink <starlink@lists.bufferbloat.net>; e-impact@ietf.org <e-impact@ietf.org>
>> Subject: Re: [E-impact] [Starlink] DataCenters in Space (was Re: fiber IXPs in space)
>> 
>> O&M will be a bear
>> v
>> 
>> 
>> On Wed, Apr 19, 2023 at 9:13 PM Tom Evslin via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>> wrote:
>> I think space-based data centers will be the rule rather than the exception. Wrote about that a couple of years ago although, as usual, things have not happened as quickly as I predicted https://blog.tomevslin.com/2021/07/computing-clouds-in-orbit-a-possible-roadmap.html <https://blog.tomevslin.com/2021/07/computing-clouds-in-orbit-a-possible-roadmap.html>
>> 
>> -----Original Message-----
>> From: Starlink <starlink-bounces@lists.bufferbloat.net <mailto:starlink-bounces@lists.bufferbloat.net>> On Behalf Of Michael Richardson via Starlink
>> Sent: Wednesday, April 19, 2023 7:35 PM
>> To: starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>>; e-impact@ietf.org <mailto:e-impact@ietf.org>
>> Subject: [Starlink] DataCenters in Space (was Re: fiber IXPs in space)
>> 
>> 
>> I saw this reported in BIS-Spaceflight.
>> (I'm usually a few months behind in reading it) I like the "first objective"!
>> 
>> https://www.thalesgroup.com/en/worldwide/space/press-release/ascend-thales-alenia-space-lead-european-feasibility-study-data <https://www.thalesgroup.com/en/worldwide/space/press-release/ascend-thales-alenia-space-lead-european-feasibility-study-data>
>> 
>> Cannes, November 14, 2022 – Thales Alenia Space, the joint company between Thales (67%) and Leonardo (33%), has been chosen by the European Commission to lead the ASCEND (Advanced Space Cloud for European Net zero emission and Data sovereignty) feasibility study for data centers in orbit, as part of Europe’s vast Horizon Europe research program.
>> 
>> Digital technology’s expanding environmental footprint is becoming a major
>> challenge: the burgeoning need for digitalization means that data centers in Europe and around the world are growing at an exponential pace, which in turn has a critical energy and environmental impact.
>> 
>> The first objective of this study will be to assess if the carbon emissions from the production and launch of these space infrastructures will be significantly lower than the emissions generated by ground-based data centers, therefore contributing to the achievement of global carbon neutrality. The second objective will be to prove that it is possible to develop the required launch solution and to ensure the deployment and operability of these spaceborne data centers using robotic assistance technologies currently being developed in Europe, such as the EROSS IOD demonstrator.
>> 
>> This project is expected to demonstrate to which extent space-based data centers would limit the energy and environmental impact of their ground counterparts, thus allowing major investments within the scope of Europe’s Green Deal, possibly justifying the development of a more climate-friendly, reusable heavy launch vehicle. Europe could thus regain its leadership in space transport and space logistics, as well as the assembly and operations of large infrastructures in orbit.
>> 
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
>> https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>
>> 
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
>> https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>
>> 
>> 
>> --
>> Please send any postal/overnight deliveries to:
>> Vint Cerf
>> Google, LLC
>> 1900 Reston Metro Plaza, 16th Floor
>> Reston, VA 20190
>> +1 (571) 213 1346
>> 
>> 
>> until further notice
>> 
>> 
>> 
>> --
>> E-impact mailing list
>> E-impact@ietf.org
>> https://www.ietf.org/mailman/listinfo/e-impact
> 
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink


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

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

Re: [Starlink] [E-impact] DataCenters in Space (was Re: fiber IXPs in space)

[Hesham ElBakoury]

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

The article about the ASCEND project says:
"Very low ambient temperatures in space will dramatically reduce the need
for cooling equipment that consumes enormous amounts of energy. A
significant part of a data center’s energy use is for cooling equipment,
accounting for more than 50% in some facilities. Temperatures can be as low
as -292°F (-180°C) when an orbiting object is in the Earth’s shadow."

Hesham

On Wed, Apr 19, 2023, 10:44 PM Daniel Schien <Daniel.Schien@bristol.ac.uk>
wrote:

> I assume any object in orbit will be hidden from the sun some of the time.
> So, the machines will require some pretty big battery to go up with them.
>
> I'd like to also know what the launch cost is.
>
> Tom Segert estimates in his LinkedIn post, for a 100kg satellite payload:
>
> "TL:DR ~57 ton CO2e for a typical ESA satellite (including Ariane 6
> launch), <15t CO2e for a satellite built in a factory and launched with a
> re-usable rocket."
>
> Depending on the type of server that should go up there, this is a fair
> amount of carbon to offset from brighter sunlight.
>
> The article also gets the carbon footprint wrong:
>
> "Data centers are big energy consumers – between 2% and 3% of all global
> consumption – a rate that is doubling every year."
>
> The latest was IEA estimating it to be around 220-320 TWh (out of 30,000)
> in 2021 data and growing between 10-60% over 6 years in total (so let's
> than 10 CAGR). But it's certainly not doubling every year. That's just
> completely wrong.
>
>
> Daniel Schien
>
> Senior Lecturer in Computer Science
>
> Department of Computer Science | University of Bristol
>
> *Submit software engineering project ideas for 2022*
>
> bris.ac.uk/software-engineering
> Watch: https://youtu.be/lU-ZsBDFWDI
>
> Merchant Venturers Building , Woodland Rd Bristol, BS8 1UB
> *Book a meeting*:
> https://outlook.office365.com/owa/calendar/OfficeHours@bristol.ac.uk/booki
> <https://outlook.office365.com/owa/calendar/OfficeHours@bristol.ac.uk/bookings/>
> ------------------------------
> *From:* E-impact <e-impact-bounces@ietf.org> on behalf of Vint Cerf <vint=
> 40google.com@dmarc.ietf.org>
> *Sent:* Thursday, April 20, 2023 2:16:38 AM
> *To:* tom@evslin.com <tom@evslin.com>
> *Cc:* Michael Richardson <mcr@sandelman.ca>; starlink <
> starlink@lists.bufferbloat.net>; e-impact@ietf.org <e-impact@ietf.org>
> *Subject:* Re: [E-impact] [Starlink] DataCenters in Space (was Re: fiber
> IXPs in space)
>
> O&M will be a bear
> v
>
>
> On Wed, Apr 19, 2023 at 9:13 PM Tom Evslin via Starlink <
> starlink@lists.bufferbloat.net> wrote:
>
> I think space-based data centers will be the rule rather than the
> exception. Wrote about that a couple of years ago although, as usual,
> things have not happened as quickly as I predicted
> https://blog.tomevslin.com/2021/07/computing-clouds-in-orbit-a-possible-roadmap.html
>
> -----Original Message-----
> From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf Of
> Michael Richardson via Starlink
> Sent: Wednesday, April 19, 2023 7:35 PM
> To: starlink <starlink@lists.bufferbloat.net>; e-impact@ietf.org
> Subject: [Starlink] DataCenters in Space (was Re: fiber IXPs in space)
>
>
> I saw this reported in BIS-Spaceflight.
> (I'm usually a few months behind in reading it) I like the "first
> objective"!
>
>
> https://www.thalesgroup.com/en/worldwide/space/press-release/ascend-thales-alenia-space-lead-european-feasibility-study-data
>
> Cannes, November 14, 2022 – Thales Alenia Space, the joint company between
> Thales (67%) and Leonardo (33%), has been chosen by the European Commission
> to lead the ASCEND (Advanced Space Cloud for European Net zero emission and
> Data sovereignty) feasibility study for data centers in orbit, as part of
> Europe’s vast Horizon Europe research program.
>
> Digital technology’s expanding environmental footprint is becoming a major
> challenge: the burgeoning need for digitalization means that data centers
> in Europe and around the world are growing at an exponential pace, which in
> turn has a critical energy and environmental impact.
>
> The first objective of this study will be to assess if the carbon
> emissions from the production and launch of these space infrastructures
> will be significantly lower than the emissions generated by ground-based
> data centers, therefore contributing to the achievement of global carbon
> neutrality. The second objective will be to prove that it is possible to
> develop the required launch solution and to ensure the deployment and
> operability of these spaceborne data centers using robotic assistance
> technologies currently being developed in Europe, such as the EROSS IOD
> demonstrator.
>
> This project is expected to demonstrate to which extent space-based data
> centers would limit the energy and environmental impact of their ground
> counterparts, thus allowing major investments within the scope of Europe’s
> Green Deal, possibly justifying the development of a more climate-friendly,
> reusable heavy launch vehicle. Europe could thus regain its leadership in
> space transport and space logistics, as well as the assembly and operations
> of large infrastructures in orbit.
>
> _______________________________________________
> 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
> Google, LLC
> 1900 Reston Metro Plaza, 16th Floor
> Reston, VA 20190
> +1 (571) 213 1346
>
>
> until further notice
>
>
>
> --
> E-impact mailing list
> E-impact@ietf.org
> https://www.ietf.org/mailman/listinfo/e-impact
>

[-- Attachment #2: Type: text/html, Size: 12316 bytes --]

Re: [Starlink] [E-impact] DataCenters in Space (was Re: fiber IXPs in space)

[Sebastian Moeller]

Hi Hesham,

the problem is not primarily the temperature of space, but the fact that computers tend to produce heat themselves that needs to be deposed off and vacuum makes a hell of a thermal isolator... so essentially I think you need to radiate your heat out as infrared light, no convection possible.
I am with Ulrich on this, the economics of this do not look favorable, except maybe for a few applications where being closer to the end points (or the satellites themselves) matter enormously.

Regards
	Sebastian


> On Apr 20, 2023, at 13:10, Hesham ElBakoury via Starlink <starlink@lists.bufferbloat.net> wrote:
> 
> The article about the ASCEND project says:
> "Very low ambient temperatures in space will dramatically reduce the need for cooling equipment that consumes enormous amounts of energy. A significant part of a data center’s energy use is for cooling equipment, accounting for more than 50% in some facilities. Temperatures can be as low as -292°F (-180°C) when an orbiting object is in the Earth’s shadow."
> 
> Hesham
> 
> On Wed, Apr 19, 2023, 10:44 PM Daniel Schien <Daniel.Schien@bristol.ac.uk> wrote:
> I assume any object in orbit will be hidden from the sun some of the time. So, the machines will require some pretty big battery to go up with them. 
> 
> I'd like to also know what the launch cost is. 
> 
> Tom Segert estimates in his LinkedIn post, for a 100kg satellite payload:
> 
> "TL:DR ~57 ton CO2e for a typical ESA satellite (including Ariane 6 launch), <15t CO2e for a satellite built in a factory and launched with a re-usable rocket."
> 
> Depending on the type of server that should go up there, this is a fair amount of carbon to offset from brighter sunlight.
> 
> The article also gets the carbon footprint wrong:
> 
> "Data centers are big energy consumers – between 2% and 3% of all global consumption – a rate that is doubling every year."
> 
> The latest was IEA estimating it to be around 220-320 TWh (out of 30,000) in 2021 data and growing between 10-60% over 6 years in total (so let's than 10 CAGR). But it's certainly not doubling every year. That's just completely wrong.
> 
> 
> Daniel Schien
> Senior Lecturer in Computer Science
> Department of Computer Science | University of Bristol
> Submit software engineering project ideas for 2022
> 
> bris.ac.uk/software-engineering
> Watch: https://youtu.be/lU-ZsBDFWDI
> 
> Merchant Venturers Building , Woodland Rd Bristol, BS8 1UB
> Book a meeting: https://outlook.office365.com/owa/calendar/OfficeHours@bristol.ac.uk/booki
> 
> From: E-impact <e-impact-bounces@ietf.org> on behalf of Vint Cerf <vint=40google.com@dmarc.ietf.org>
> Sent: Thursday, April 20, 2023 2:16:38 AM
> To: tom@evslin.com <tom@evslin.com>
> Cc: Michael Richardson <mcr@sandelman.ca>; starlink <starlink@lists.bufferbloat.net>; e-impact@ietf.org <e-impact@ietf.org>
> Subject: Re: [E-impact] [Starlink] DataCenters in Space (was Re: fiber IXPs in space)
>  
> O&M will be a bear
> v
> 
> 
> On Wed, Apr 19, 2023 at 9:13 PM Tom Evslin via Starlink <starlink@lists.bufferbloat.net> wrote:
> I think space-based data centers will be the rule rather than the exception. Wrote about that a couple of years ago although, as usual, things have not happened as quickly as I predicted https://blog.tomevslin.com/2021/07/computing-clouds-in-orbit-a-possible-roadmap.html
> 
> -----Original Message-----
> From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf Of Michael Richardson via Starlink
> Sent: Wednesday, April 19, 2023 7:35 PM
> To: starlink <starlink@lists.bufferbloat.net>; e-impact@ietf.org
> Subject: [Starlink] DataCenters in Space (was Re: fiber IXPs in space)
> 
> 
> I saw this reported in BIS-Spaceflight.
> (I'm usually a few months behind in reading it) I like the "first objective"!
> 
> https://www.thalesgroup.com/en/worldwide/space/press-release/ascend-thales-alenia-space-lead-european-feasibility-study-data
> 
> Cannes, November 14, 2022 – Thales Alenia Space, the joint company between Thales (67%) and Leonardo (33%), has been chosen by the European Commission to lead the ASCEND (Advanced Space Cloud for European Net zero emission and Data sovereignty) feasibility study for data centers in orbit, as part of Europe’s vast Horizon Europe research program.
> 
> Digital technology’s expanding environmental footprint is becoming a major
> challenge: the burgeoning need for digitalization means that data centers in Europe and around the world are growing at an exponential pace, which in turn has a critical energy and environmental impact.
> 
> The first objective of this study will be to assess if the carbon emissions from the production and launch of these space infrastructures will be significantly lower than the emissions generated by ground-based data centers, therefore contributing to the achievement of global carbon neutrality. The second objective will be to prove that it is possible to develop the required launch solution and to ensure the deployment and operability of these spaceborne data centers using robotic assistance technologies currently being developed in Europe, such as the EROSS IOD demonstrator.
> 
> This project is expected to demonstrate to which extent space-based data centers would limit the energy and environmental impact of their ground counterparts, thus allowing major investments within the scope of Europe’s Green Deal, possibly justifying the development of a more climate-friendly, reusable heavy launch vehicle. Europe could thus regain its leadership in space transport and space logistics, as well as the assembly and operations of large infrastructures in orbit.
> 
> _______________________________________________
> 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
> Google, LLC
> 1900 Reston Metro Plaza, 16th Floor
> Reston, VA 20190
> +1 (571) 213 1346
> 
> 
> until further notice
> 
> 
> 
> -- 
> E-impact mailing list
> E-impact@ietf.org
> https://www.ietf.org/mailman/listinfo/e-impact
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] [E-impact] DataCenters in Space (was Re: fiber IXPs in space)

[David Lang]

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

vaccum is a fantastic insulator, you only get rid of heat by radiation (the 
reason the shuttle normally had it's cargo doors open was to expose the 
radiators to space)

the biggest problem with spacecraft over the long run is getting rid of the 
heat.

David LAng

On Thu, 20 Apr 2023, Hesham ElBakoury via Starlink wrote:

> The article about the ASCEND project says:
> "Very low ambient temperatures in space will dramatically reduce the need
> for cooling equipment that consumes enormous amounts of energy. A
> significant part of a data center’s energy use is for cooling equipment,
> accounting for more than 50% in some facilities. Temperatures can be as low
> as -292°F (-180°C) when an orbiting object is in the Earth’s shadow."
>
> Hesham
>
> On Wed, Apr 19, 2023, 10:44 PM Daniel Schien <Daniel.Schien@bristol.ac.uk>
> wrote:
>
>> I assume any object in orbit will be hidden from the sun some of the time.
>> So, the machines will require some pretty big battery to go up with them.
>>
>> I'd like to also know what the launch cost is.
>>
>> Tom Segert estimates in his LinkedIn post, for a 100kg satellite payload:
>>
>> "TL:DR ~57 ton CO2e for a typical ESA satellite (including Ariane 6
>> launch), <15t CO2e for a satellite built in a factory and launched with a
>> re-usable rocket."
>>
>> Depending on the type of server that should go up there, this is a fair
>> amount of carbon to offset from brighter sunlight.
>>
>> The article also gets the carbon footprint wrong:
>>
>> "Data centers are big energy consumers – between 2% and 3% of all global
>> consumption – a rate that is doubling every year."
>>
>> The latest was IEA estimating it to be around 220-320 TWh (out of 30,000)
>> in 2021 data and growing between 10-60% over 6 years in total (so let's
>> than 10 CAGR). But it's certainly not doubling every year. That's just
>> completely wrong.
>>
>>
>> Daniel Schien
>>
>> Senior Lecturer in Computer Science
>>
>> Department of Computer Science | University of Bristol
>>
>> *Submit software engineering project ideas for 2022*
>>
>> bris.ac.uk/software-engineering
>> Watch: https://youtu.be/lU-ZsBDFWDI
>>
>> Merchant Venturers Building , Woodland Rd Bristol, BS8 1UB
>> *Book a meeting*:
>> https://outlook.office365.com/owa/calendar/OfficeHours@bristol.ac.uk/booki
>> <https://outlook.office365.com/owa/calendar/OfficeHours@bristol.ac.uk/bookings/>
>> ------------------------------
>> *From:* E-impact <e-impact-bounces@ietf.org> on behalf of Vint Cerf <vint=
>> 40google.com@dmarc.ietf.org>
>> *Sent:* Thursday, April 20, 2023 2:16:38 AM
>> *To:* tom@evslin.com <tom@evslin.com>
>> *Cc:* Michael Richardson <mcr@sandelman.ca>; starlink <
>> starlink@lists.bufferbloat.net>; e-impact@ietf.org <e-impact@ietf.org>
>> *Subject:* Re: [E-impact] [Starlink] DataCenters in Space (was Re: fiber
>> IXPs in space)
>>
>> O&M will be a bear
>> v
>>
>>
>> On Wed, Apr 19, 2023 at 9:13 PM Tom Evslin via Starlink <
>> starlink@lists.bufferbloat.net> wrote:
>>
>> I think space-based data centers will be the rule rather than the
>> exception. Wrote about that a couple of years ago although, as usual,
>> things have not happened as quickly as I predicted
>> https://blog.tomevslin.com/2021/07/computing-clouds-in-orbit-a-possible-roadmap.html
>>
>> -----Original Message-----
>> From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf Of
>> Michael Richardson via Starlink
>> Sent: Wednesday, April 19, 2023 7:35 PM
>> To: starlink <starlink@lists.bufferbloat.net>; e-impact@ietf.org
>> Subject: [Starlink] DataCenters in Space (was Re: fiber IXPs in space)
>>
>>
>> I saw this reported in BIS-Spaceflight.
>> (I'm usually a few months behind in reading it) I like the "first
>> objective"!
>>
>>
>> https://www.thalesgroup.com/en/worldwide/space/press-release/ascend-thales-alenia-space-lead-european-feasibility-study-data
>>
>> Cannes, November 14, 2022 – Thales Alenia Space, the joint company between
>> Thales (67%) and Leonardo (33%), has been chosen by the European Commission
>> to lead the ASCEND (Advanced Space Cloud for European Net zero emission and
>> Data sovereignty) feasibility study for data centers in orbit, as part of
>> Europe’s vast Horizon Europe research program.
>>
>> Digital technology’s expanding environmental footprint is becoming a major
>> challenge: the burgeoning need for digitalization means that data centers
>> in Europe and around the world are growing at an exponential pace, which in
>> turn has a critical energy and environmental impact.
>>
>> The first objective of this study will be to assess if the carbon
>> emissions from the production and launch of these space infrastructures
>> will be significantly lower than the emissions generated by ground-based
>> data centers, therefore contributing to the achievement of global carbon
>> neutrality. The second objective will be to prove that it is possible to
>> develop the required launch solution and to ensure the deployment and
>> operability of these spaceborne data centers using robotic assistance
>> technologies currently being developed in Europe, such as the EROSS IOD
>> demonstrator.
>>
>> This project is expected to demonstrate to which extent space-based data
>> centers would limit the energy and environmental impact of their ground
>> counterparts, thus allowing major investments within the scope of Europe’s
>> Green Deal, possibly justifying the development of a more climate-friendly,
>> reusable heavy launch vehicle. Europe could thus regain its leadership in
>> space transport and space logistics, as well as the assembly and operations
>> of large infrastructures in orbit.
>>
>> _______________________________________________
>> 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
>> Google, LLC
>> 1900 Reston Metro Plaza, 16th Floor
>> Reston, VA 20190
>> +1 (571) 213 1346
>>
>>
>> until further notice
>>
>>
>>
>> --
>> E-impact mailing list
>> E-impact@ietf.org
>> https://www.ietf.org/mailman/listinfo/e-impact
>>
>

Re: [Starlink] [E-impact] DataCenters in Space (was Re: fiber IXPs in space)

[Dave Collier-Brown]

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

Another point they missed: on earth, we can use conductive cooling and transfer the heat from the machines to a flow of air.  In space, we can only use radiative cooling, and we need to be out of the sun to have enough temperature difference.

--dave

On 4/20/23 07:10, Hesham ElBakoury via Starlink wrote:
The article about the ASCEND project says:
"Very low ambient temperatures in space will dramatically reduce the need for cooling equipment that consumes enormous amounts of energy. A significant part of a data center’s energy use is for cooling equipment, accounting for more than 50% in some facilities. Temperatures can be as low as -292°F (-180°C) when an orbiting object is in the Earth’s shadow."

Hesham

On Wed, Apr 19, 2023, 10:44 PM Daniel Schien <Daniel.Schien@bristol.ac.uk<mailto:Daniel.Schien@bristol.ac.uk>> wrote:
I assume any object in orbit will be hidden from the sun some of the time. So, the machines will require some pretty big battery to go up with them.

I'd like to also know what the launch cost is.

Tom Segert estimates in his LinkedIn post, for a 100kg satellite payload:

"TL:DR ~57 ton CO2e for a typical ESA satellite (including Ariane 6 launch), <15t CO2e for a satellite built in a factory and launched with a re-usable rocket."

Depending on the type of server that should go up there, this is a fair amount of carbon to offset from brighter sunlight.

The article also gets the carbon footprint wrong:

"Data centers are big energy consumers – between 2% and 3% of all global consumption – a rate that is doubling every year."

The latest was IEA estimating it to be around 220-320 TWh (out of 30,000) in 2021 data and growing between 10-60% over 6 years in total (so let's than 10 CAGR). But it's certainly not doubling every year. That's just completely wrong.


Daniel Schien

Senior Lecturer in Computer Science

Department of Computer Science | University of Bristol



Submit software engineering project ideas for 2022

bris.ac.uk/software-engineering
Watch: https://youtu.be/lU-ZsBDFWDI

Merchant Venturers Building , Woodland Rd Bristol, BS8 1UB
Book a meeting: https://outlook.office365.com/owa/calendar/OfficeHours@bristol.ac.uk/booki<https://outlook.office365.com/owa/calendar/OfficeHours@bristol.ac.uk/bookings/>

________________________________
From: E-impact <e-impact-bounces@ietf.org<mailto:e-impact-bounces@ietf.org>> on behalf of Vint Cerf <vint=40google.com@dmarc.ietf.org<mailto:40google.com@dmarc.ietf.org>>
Sent: Thursday, April 20, 2023 2:16:38 AM
To: tom@evslin.com<mailto:tom@evslin.com> <tom@evslin.com<mailto:tom@evslin.com>>
Cc: 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: [E-impact] [Starlink] DataCenters in Space (was Re: fiber IXPs in space)

O&M will be a bear
v


On Wed, Apr 19, 2023 at 9:13 PM Tom Evslin via Starlink <starlink@lists.bufferbloat.net<mailto:starlink@lists.bufferbloat.net>> wrote:
I think space-based data centers will be the rule rather than the exception. Wrote about that a couple of years ago although, as usual, things have not happened as quickly as I predicted https://blog.tomevslin.com/2021/07/computing-clouds-in-orbit-a-possible-roadmap.html

-----Original Message-----
From: Starlink <starlink-bounces@lists.bufferbloat.net<mailto:starlink-bounces@lists.bufferbloat.net>> On Behalf Of Michael Richardson via Starlink
Sent: Wednesday, April 19, 2023 7:35 PM
To: starlink <starlink@lists.bufferbloat.net<mailto:starlink@lists.bufferbloat.net>>; e-impact@ietf.org<mailto:e-impact@ietf.org>
Subject: [Starlink] DataCenters in Space (was Re: fiber IXPs in space)


I saw this reported in BIS-Spaceflight.
(I'm usually a few months behind in reading it) I like the "first objective"!

https://www.thalesgroup.com/en/worldwide/space/press-release/ascend-thales-alenia-space-lead-european-feasibility-study-data

Cannes, November 14, 2022 – Thales Alenia Space, the joint company between Thales (67%) and Leonardo (33%), has been chosen by the European Commission to lead the ASCEND (Advanced Space Cloud for European Net zero emission and Data sovereignty) feasibility study for data centers in orbit, as part of Europe’s vast Horizon Europe research program.

Digital technology’s expanding environmental footprint is becoming a major
challenge: the burgeoning need for digitalization means that data centers in Europe and around the world are growing at an exponential pace, which in turn has a critical energy and environmental impact.

The first objective of this study will be to assess if the carbon emissions from the production and launch of these space infrastructures will be significantly lower than the emissions generated by ground-based data centers, therefore contributing to the achievement of global carbon neutrality. The second objective will be to prove that it is possible to develop the required launch solution and to ensure the deployment and operability of these spaceborne data centers using robotic assistance technologies currently being developed in Europe, such as the EROSS IOD demonstrator.

This project is expected to demonstrate to which extent space-based data centers would limit the energy and environmental impact of their ground counterparts, thus allowing major investments within the scope of Europe’s Green Deal, possibly justifying the development of a more climate-friendly, reusable heavy launch vehicle. Europe could thus regain its leadership in space transport and space logistics, as well as the assembly and operations of large infrastructures in orbit.

_______________________________________________
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<mailto:Starlink@lists.bufferbloat.net>
https://lists.bufferbloat.net/listinfo/starlink


--
Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346


until further notice



--
E-impact mailing list
E-impact@ietf.org<mailto:E-impact@ietf.org>
https://www.ietf.org/mailman/listinfo/e-impact



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


--
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
dave.collier-brown@indexexchange.com<mailto:dave.collier-brown@indexexchange.com> |              -- Mark Twain


CONFIDENTIALITY NOTICE AND DISCLAIMER : This telecommunication, including any and all attachments, contains confidential information intended only for the person(s) to whom it is addressed. Any dissemination, distribution, copying or disclosure is strictly prohibited and is not a waiver of confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and delete the message from your inbox and deleted items folders. This telecommunication does not constitute an express or implied agreement to conduct transactions by electronic means, nor does it constitute a contract offer, a contract amendment or an acceptance of a contract offer. Contract terms contained in this telecommunication are subject to legal review and the completion of formal documentation and are not binding until same is confirmed in writing and has been signed by an authorized signatory.

[-- Attachment #2: Type: text/html, Size: 16029 bytes --]

Re: [Starlink] [E-impact] DataCenters in Space (was Re: fiber IXPs in space)

[Ulrich Speidel]

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

Indeed. There's another point that's been missed in the "superconductor" 
suggestion: Why do we get the heat in the first place?

Superconductors are great when it comes to reducing resistive losses in 
long and / or high current conductors (power distribution, MRI magnets, 
...). But this isn't why computer chips get hot. Let me take you back to 
your Physics 101 when you learned that Power P was the product of 
current I and voltage V. A logic chip like a CPU is nothing but an 
assortment of gazillions of little switches. When a switch is open, it 
may have voltage across it but no current flows: no power gets 
dissipated. If it's closed, current may flow but there won't be any 
voltage across it. Also not a source of power loss.

The power loss (heat generation) happens when the little switches are 
switching, i.e., when they are between open and closed and when there is 
both a bit of voltage and a bit of current present. Naively you might 
say that a switch is either on or off, and so that shouldn't occur, but 
in both theory and practice, an instantaneous loss-free switching 
process requires a signal of infinite bandwidth when subjected to 
Fourier analysis. Fourier analysis allows us to model any signal as a 
combination of sinusoidal signals of different frequency, amplitude and 
phase, and it's in particular the high-and-in-the-direction-of-infinity 
frequency components of that combination that are needed for the 
"ïnstantaneous"switching. Unfortunately, in any real circuit of larger 
than zero size, reactive elements (capacitive and inductive components 
or parasitic properties of that nature) attenuate these. So the only 
real switching we can actually do in real life is switching that 
dissipates power when it happens - no matter whether the chip is built 
using superconductors or not.

In a modern CPU, a significant percentage of gates are this this "gray" 
in-between state between 0 and 1 for a significant part of the time, 
which is why you need elaborate cooling fans and water coolers etc., and 
it's also why clock frequencies haven't increased substantially in 
recent years.

On 21/04/2023 12:06 am, Dave Collier-Brown via Starlink wrote:
>
> Another point they missed: on earth, we can use conductive cooling and 
> transfer the heat from the machines to a flow of air.  In space, we 
> can only use radiative cooling, and we need to be out of the sun to 
> have enough temperature difference.
>
> --dave
>
> On 4/20/23 07:10, Hesham ElBakoury via Starlink wrote:
>> The article about the ASCEND project says:
>> "Very low ambient temperatures in space will dramatically reduce the 
>> need for cooling equipment that consumes enormous amounts of energy. 
>> A significant part of a data center’s energy use is for cooling 
>> equipment, accounting for more than 50% in some facilities. 
>> Temperatures can be as low as -292°F (-180°C) when an orbiting object 
>> is in the Earth’s shadow."
>>
>> Hesham
>>
>> On Wed, Apr 19, 2023, 10:44 PM Daniel Schien 
>> <Daniel.Schien@bristol.ac.uk> wrote:
>>
>>     I assume any object in orbit will be hidden from the sun some of
>>     the time. So, the machines will require some pretty big battery
>>     to go up with them.
>>
>>     I'd like to also know what the launch cost is.
>>
>>     Tom Segert estimates in his LinkedIn post, for a 100kg satellite
>>     payload:
>>
>>     "TL:DR ~57 ton CO2e for a typical ESA satellite (including Ariane
>>     6 launch), <15t CO2e for a satellite built in a factory and
>>     launched with a re-usable rocket."
>>
>>     Depending on the type of server that should go up there, this is
>>     a fair amount of carbon to offset from brighter sunlight.
>>
>>     The article also gets the carbon footprint wrong:
>>
>>     "Data centers are big energy consumers – between 2% and 3% of all
>>     global consumption – a rate that is doubling every year."
>>
>>     The latest was IEA estimating it to be around 220-320 TWh (out of
>>     30,000) in 2021 data and growing between 10-60% over 6 years in
>>     total (so let's than 10 CAGR). But it's certainly not doubling
>>     every year. That's just completely wrong.
>>
>>
>>           DanielSchien
>>
>>     Senior Lecturer in Computer Science
>>
>>     Department of Computer Science | University of Bristol
>>
>>     	
>>     	
>>     	
>>
>>     *Submit software engineering project ideas for 2022*
>>
>>
>>     	http://bris.ac.uk/software-engineering
>>     Watch: https://youtu.be/lU-ZsBDFWDI
>>     <https://youtu.be/lU-ZsBDFWDI>
>>
>>
>>     	Merchant Venturers Building , Woodland Rd Bristol, BS8 1UB
>>
>>     *Book a meeting*:
>>     https://outlook.office365.com/owa/calendar/OfficeHours@bristol.ac.uk/booki
>>     <https://outlook.office365.com/owa/calendar/OfficeHours@bristol.ac.uk/bookings/>
>>
>>
>>
>>     ------------------------------------------------------------------------
>>     *From:* E-impact <e-impact-bounces@ietf.org> on behalf of Vint
>>     Cerf <vint=40google.com@dmarc.ietf.org>
>>     *Sent:* Thursday, April 20, 2023 2:16:38 AM
>>     *To:* tom@evslin.com <tom@evslin.com>
>>     *Cc:* Michael Richardson <mcr@sandelman.ca>; starlink
>>     <starlink@lists.bufferbloat.net>; e-impact@ietf.org
>>     <e-impact@ietf.org>
>>     *Subject:* Re: [E-impact] [Starlink] DataCenters in Space (was
>>     Re: fiber IXPs in space)
>>     O&M will be a bear
>>     v
>>
>>
>>     On Wed, Apr 19, 2023 at 9:13 PM Tom Evslin via Starlink
>>     <starlink@lists.bufferbloat.net> wrote:
>>
>>         I think space-based data centers will be the rule rather than
>>         the exception. Wrote about that a couple of years ago
>>         although, as usual, things have not happened as quickly as I
>>         predicted
>>         https://blog.tomevslin.com/2021/07/computing-clouds-in-orbit-a-possible-roadmap.html
>>
>>         -----Original Message-----
>>         From: Starlink <starlink-bounces@lists.bufferbloat.net> On
>>         Behalf Of Michael Richardson via Starlink
>>         Sent: Wednesday, April 19, 2023 7:35 PM
>>         To: starlink <starlink@lists.bufferbloat.net>; e-impact@ietf.org
>>         Subject: [Starlink] DataCenters in Space (was Re: fiber IXPs
>>         in space)
>>
>>
>>         I saw this reported in BIS-Spaceflight.
>>         (I'm usually a few months behind in reading it) I like the
>>         "first objective"!
>>
>>         https://www.thalesgroup.com/en/worldwide/space/press-release/ascend-thales-alenia-space-lead-european-feasibility-study-data
>>
>>         Cannes, November 14, 2022 – Thales Alenia Space, the joint
>>         company between Thales (67%) and Leonardo (33%), has been
>>         chosen by the European Commission to lead the ASCEND
>>         (Advanced Space Cloud for European Net zero emission and Data
>>         sovereignty) feasibility study for data centers in orbit, as
>>         part of Europe’s vast Horizon Europe research program.
>>
>>         Digital technology’s expanding environmental footprint is
>>         becoming a major
>>         challenge: the burgeoning need for digitalization means that
>>         data centers in Europe and around the world are growing at an
>>         exponential pace, which in turn has a critical energy and
>>         environmental impact.
>>
>>         The first objective of this study will be to assess if the
>>         carbon emissions from the production and launch of these
>>         space infrastructures will be significantly lower than the
>>         emissions generated by ground-based data centers, therefore
>>         contributing to the achievement of global carbon neutrality.
>>         The second objective will be to prove that it is possible to
>>         develop the required launch solution and to ensure the
>>         deployment and operability of these spaceborne data centers
>>         using robotic assistance technologies currently being
>>         developed in Europe, such as the EROSS IOD demonstrator.
>>
>>         This project is expected to demonstrate to which extent
>>         space-based data centers would limit the energy and
>>         environmental impact of their ground counterparts, thus
>>         allowing major investments within the scope of Europe’s Green
>>         Deal, possibly justifying the development of a more
>>         climate-friendly, reusable heavy launch vehicle. Europe could
>>         thus regain its leadership in space transport and space
>>         logistics, as well as the assembly and operations of large
>>         infrastructures in orbit.
>>
>>         _______________________________________________
>>         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
>>     Google, LLC
>>     1900 Reston Metro Plaza, 16th Floor
>>     Reston, VA 20190
>>     +1 (571) 213 1346
>>
>>
>>     until further notice
>>
>>
>>
>>     -- 
>>     E-impact mailing list
>>     E-impact@ietf.org
>>     https://www.ietf.org/mailman/listinfo/e-impact
>>
>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
> -- 
> David Collier-Brown,         | Always do right. This will gratify
> System Programmer and Author | some people and astonish the rest
> dave.collier-brown@indexexchange.com  |              -- Mark Twain
>
> */CONFIDENTIALITY NOTICE AND DISCLAIMER/*/ : This telecommunication, 
> including any and all attachments, contains confidential information 
> intended only for the person(s) to whom it is addressed. Any 
> dissemination, distribution, copying or disclosure is strictly 
> prohibited and is not a waiver of confidentiality. If you have 
> received this telecommunication in error, please notify the sender 
> immediately by return electronic mail and delete the message from your 
> inbox and deleted items folders. This telecommunication does not 
> constitute an express or implied agreement to conduct transactions by 
> electronic means, nor does it constitute a contract offer, a contract 
> amendment or an acceptance of a contract offer. Contract terms 
> contained in this telecommunication are subject to legal review and 
> the completion of formal documentation and are not binding until same 
> is confirmed in writing and has been signed by an authorized signatory./
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>
-- 
****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel@auckland.ac.nz  
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************



[-- Attachment #2: Type: text/html, Size: 26412 bytes --]

Re: [Starlink] [E-impact] DataCenters in Space (was Re: fiber IXPs in space)

[tom]

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

The solar collectors should always be on the sun-side of the bird so effective at creating shade as well.

 

From: Hesham ElBakoury <helbakoury@gmail.com> 
Sent: Thursday, April 20, 2023 7:10 AM
To: Daniel Schien <Daniel.Schien@bristol.ac.uk>
Cc: Vint Cerf <vint=40google.com@dmarc.ietf.org>; tom@evslin.com; Michael Richardson <mcr@sandelman.ca>; starlink <starlink@lists.bufferbloat.net>; e-impact@ietf.org
Subject: Re: [E-impact] [Starlink] DataCenters in Space (was Re: fiber IXPs in space)

 

The article about the ASCEND project says:

"Very low ambient temperatures in space will dramatically reduce the need for cooling equipment that consumes enormous amounts of energy. A significant part of a data center’s energy use is for cooling equipment, accounting for more than 50% in some facilities. Temperatures can be as low as -292°F (-180°C) when an orbiting object is in the Earth’s shadow."

 

Hesham

 

On Wed, Apr 19, 2023, 10:44 PM Daniel Schien <Daniel.Schien@bristol.ac.uk <mailto:Daniel.Schien@bristol.ac.uk> > wrote:

I assume any object in orbit will be hidden from the sun some of the time. So, the machines will require some pretty big battery to go up with them. 

 

I'd like to also know what the launch cost is. 

 

Tom Segert estimates in his LinkedIn post, for a 100kg satellite payload:

 

"TL:DR ~57 ton CO2e for a typical ESA satellite (including Ariane 6 launch), <15t CO2e for a satellite built in a factory and launched with a re-usable rocket."

 

Depending on the type of server that should go up there, this is a fair amount of carbon to offset from brighter sunlight.

 

The article also gets the carbon footprint wrong:

 

"Data centers are big energy consumers – between 2% and 3% of all global consumption – a rate that is doubling every year."

 

The latest was IEA estimating it to be around 220-320 TWh (out of 30,000) in 2021 data and growing between 10-60% over 6 years in total (so let's than 10 CAGR). But it's certainly not doubling every year. That's just completely wrong.

 

 




Daniel Schien


Senior Lecturer in Computer Science

Department of Computer Science | University of Bristol

		
Submit software engineering project ideas for 2022


	
bris.ac.uk/software-engineering
Watch:  <https://youtu.be/lU-ZsBDFWDI> https://youtu.be/lU-ZsBDFWDI


	
Merchant Venturers Building , Woodland Rd Bristol, BS8 1UB


	

Book a meeting:  <https://outlook.office365.com/owa/calendar/OfficeHours@bristol.ac.uk/bookings/> https://outlook.office365.com/owa/calendar/OfficeHours@bristol.ac.uk/booki

 

  _____  

From: E-impact <e-impact-bounces@ietf.org <mailto:e-impact-bounces@ietf.org> > on behalf of Vint Cerf <vint=40google.com@dmarc.ietf.org <mailto:40google.com@dmarc.ietf.org> >
Sent: Thursday, April 20, 2023 2:16:38 AM
To: tom@evslin.com <mailto:tom@evslin.com>  <tom@evslin.com <mailto:tom@evslin.com> >
Cc: 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: [E-impact] [Starlink] DataCenters in Space (was Re: fiber IXPs in space) 

 

O&M will be a bear 

v

 

 

On Wed, Apr 19, 2023 at 9:13 PM Tom Evslin via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net> > wrote:

I think space-based data centers will be the rule rather than the exception. Wrote about that a couple of years ago although, as usual, things have not happened as quickly as I predicted https://blog.tomevslin.com/2021/07/computing-clouds-in-orbit-a-possible-roadmap.html

-----Original Message-----
From: Starlink <starlink-bounces@lists.bufferbloat.net <mailto:starlink-bounces@lists.bufferbloat.net> > On Behalf Of Michael Richardson via Starlink
Sent: Wednesday, April 19, 2023 7:35 PM
To: starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net> >; e-impact@ietf.org <mailto:e-impact@ietf.org> 
Subject: [Starlink] DataCenters in Space (was Re: fiber IXPs in space)


I saw this reported in BIS-Spaceflight.
(I'm usually a few months behind in reading it) I like the "first objective"!

https://www.thalesgroup.com/en/worldwide/space/press-release/ascend-thales-alenia-space-lead-european-feasibility-study-data

Cannes, November 14, 2022 – Thales Alenia Space, the joint company between Thales (67%) and Leonardo (33%), has been chosen by the European Commission to lead the ASCEND (Advanced Space Cloud for European Net zero emission and Data sovereignty) feasibility study for data centers in orbit, as part of Europe’s vast Horizon Europe research program.

Digital technology’s expanding environmental footprint is becoming a major
challenge: the burgeoning need for digitalization means that data centers in Europe and around the world are growing at an exponential pace, which in turn has a critical energy and environmental impact.

The first objective of this study will be to assess if the carbon emissions from the production and launch of these space infrastructures will be significantly lower than the emissions generated by ground-based data centers, therefore contributing to the achievement of global carbon neutrality. The second objective will be to prove that it is possible to develop the required launch solution and to ensure the deployment and operability of these spaceborne data centers using robotic assistance technologies currently being developed in Europe, such as the EROSS IOD demonstrator.

This project is expected to demonstrate to which extent space-based data centers would limit the energy and environmental impact of their ground counterparts, thus allowing major investments within the scope of Europe’s Green Deal, possibly justifying the development of a more climate-friendly, reusable heavy launch vehicle. Europe could thus regain its leadership in space transport and space logistics, as well as the assembly and operations of large infrastructures in orbit.

_______________________________________________
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 <mailto:Starlink@lists.bufferbloat.net> 
https://lists.bufferbloat.net/listinfo/starlink




 

-- 

Please send any postal/overnight deliveries to:

Vint Cerf

Google, LLC

1900 Reston Metro Plaza, 16th Floor

Reston, VA 20190

+1 (571) 213 1346

 

 

until further notice

 

 

 

-- 
E-impact mailing list
E-impact@ietf.org <mailto:E-impact@ietf.org> 
https://www.ietf.org/mailman/listinfo/e-impact


[-- Attachment #2: Type: text/html, Size: 15874 bytes --]

Re: [Starlink] [E-impact] DataCenters in Space (was Re: fiber IXPs in space)

[Rodney W. Grimes]

> The article about the ASCEND project says:
> "Very low ambient temperatures in space will dramatically reduce the need
> for cooling equipment that consumes enormous amounts of energy. A
> significant part of a data center?s energy use is for cooling equipment,
> accounting for more than 50% in some facilities. Temperatures can be as low
> as -292?F (-180?C) when an orbiting object is in the Earth?s shadow."

They seem to have skipped over the con's of trying to cool equipment
in space, there is no "mass" to cool into.  There is no "air" to
cool with.  You have to use conduction to get the heat from your
chips to the outer shell of the spacecraft, then you have to battle
with tring to radiate that heat into a VACUUM!  People think they
have heat limiting issues today with ground based electronis, just
wait tell they try to solve this in a spacecraft!!!

Someone should calculate the radiated surface size needed to remove
the heat generated by a 150W CPU into "space".  It might enlighten
some of these folks that think its all about the temperature of space,
its not, its about the thermal mass of space being near 0.

IMHO DC in space are going to have to find a solution to that MIPS
per W problem first!

> 
> Hesham
> 
> On Wed, Apr 19, 2023, 10:44 PM Daniel Schien <Daniel.Schien@bristol.ac.uk>
> wrote:
> 
> > I assume any object in orbit will be hidden from the sun some of the time.
> > So, the machines will require some pretty big battery to go up with them.
> >
> > I'd like to also know what the launch cost is.
> >
> > Tom Segert estimates in his LinkedIn post, for a 100kg satellite payload:
> >
> > "TL:DR ~57 ton CO2e for a typical ESA satellite (including Ariane 6
> > launch), <15t CO2e for a satellite built in a factory and launched with a
> > re-usable rocket."
> >
> > Depending on the type of server that should go up there, this is a fair
> > amount of carbon to offset from brighter sunlight.
> >
> > The article also gets the carbon footprint wrong:
> >
> > "Data centers are big energy consumers ? between 2% and 3% of all global
> > consumption ? a rate that is doubling every year."
> >
> > The latest was IEA estimating it to be around 220-320 TWh (out of 30,000)
> > in 2021 data and growing between 10-60% over 6 years in total (so let's
> > than 10 CAGR). But it's certainly not doubling every year. That's just
> > completely wrong.
> >
> >
> > Daniel Schien
> >
> > Senior Lecturer in Computer Science
> >
> > Department of Computer Science | University of Bristol
> >
> > *Submit software engineering project ideas for 2022*
> >
> > bris.ac.uk/software-engineering
> > Watch: https://youtu.be/lU-ZsBDFWDI
> >
> > Merchant Venturers Building , Woodland Rd Bristol, BS8 1UB
> > *Book a meeting*:
> > https://outlook.office365.com/owa/calendar/OfficeHours@bristol.ac.uk/booki
> > <https://outlook.office365.com/owa/calendar/OfficeHours@bristol.ac.uk/bookings/>
> > ------------------------------
> > *From:* E-impact <e-impact-bounces@ietf.org> on behalf of Vint Cerf <vint=
> > 40google.com@dmarc.ietf.org>
> > *Sent:* Thursday, April 20, 2023 2:16:38 AM
> > *To:* tom@evslin.com <tom@evslin.com>
> > *Cc:* Michael Richardson <mcr@sandelman.ca>; starlink <
> > starlink@lists.bufferbloat.net>; e-impact@ietf.org <e-impact@ietf.org>
> > *Subject:* Re: [E-impact] [Starlink] DataCenters in Space (was Re: fiber
> > IXPs in space)
> >
> > O&M will be a bear
> > v
> >
> >
> > On Wed, Apr 19, 2023 at 9:13?PM Tom Evslin via Starlink <
> > starlink@lists.bufferbloat.net> wrote:
> >
> > I think space-based data centers will be the rule rather than the
> > exception. Wrote about that a couple of years ago although, as usual,
> > things have not happened as quickly as I predicted
> > https://blog.tomevslin.com/2021/07/computing-clouds-in-orbit-a-possible-roadmap.html
> >
> > -----Original Message-----
> > From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf Of
> > Michael Richardson via Starlink
> > Sent: Wednesday, April 19, 2023 7:35 PM
> > To: starlink <starlink@lists.bufferbloat.net>; e-impact@ietf.org
> > Subject: [Starlink] DataCenters in Space (was Re: fiber IXPs in space)
> >
> >
> > I saw this reported in BIS-Spaceflight.
> > (I'm usually a few months behind in reading it) I like the "first
> > objective"!
> >
> >
> > https://www.thalesgroup.com/en/worldwide/space/press-release/ascend-thales-alenia-space-lead-european-feasibility-study-data
> >
> > Cannes, November 14, 2022 ? Thales Alenia Space, the joint company between
> > Thales (67%) and Leonardo (33%), has been chosen by the European Commission
> > to lead the ASCEND (Advanced Space Cloud for European Net zero emission and
> > Data sovereignty) feasibility study for data centers in orbit, as part of
> > Europe?s vast Horizon Europe research program.
> >
> > Digital technology?s expanding environmental footprint is becoming a major
> > challenge: the burgeoning need for digitalization means that data centers
> > in Europe and around the world are growing at an exponential pace, which in
> > turn has a critical energy and environmental impact.
> >
> > The first objective of this study will be to assess if the carbon
> > emissions from the production and launch of these space infrastructures
> > will be significantly lower than the emissions generated by ground-based
> > data centers, therefore contributing to the achievement of global carbon
> > neutrality. The second objective will be to prove that it is possible to
> > develop the required launch solution and to ensure the deployment and
> > operability of these spaceborne data centers using robotic assistance
> > technologies currently being developed in Europe, such as the EROSS IOD
> > demonstrator.
> >
> > This project is expected to demonstrate to which extent space-based data
> > centers would limit the energy and environmental impact of their ground
> > counterparts, thus allowing major investments within the scope of Europe?s
> > Green Deal, possibly justifying the development of a more climate-friendly,
> > reusable heavy launch vehicle. Europe could thus regain its leadership in
> > space transport and space logistics, as well as the assembly and operations
> > of large infrastructures in orbit.
> >
> > _______________________________________________
> > 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
> > Google, LLC
> > 1900 Reston Metro Plaza, 16th Floor
> > Reston, VA 20190
> > +1 (571) 213 1346
> >
> >
> > until further notice
> >
> >
> >
> > --
> > E-impact mailing list
> > E-impact@ietf.org
> > https://www.ietf.org/mailman/listinfo/e-impact
> >

[ Charset UTF-8 unsupported, converting... ]
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
> 

Re: [Starlink] [E-impact] DataCenters in Space (was Re: fiber IXPs in space)

[Michael Richardson]

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


Daniel Schien <Daniel.Schien@bristol.ac.uk> wrote:
    > I assume any object in orbit will be hidden from the sun some of the
    > time. So, the machines will require some pretty big battery to go up
    > with them.

Why would we do that?  Make the orbits polar/sun-synchronous.

While GEO is pretty busy, I wonder if there are other interesting orbits.
Obviously, Lagrange points are one set, but are there half-GEO or 2xGEO
orbits that are somehow useful?

One point I got from Geoff Houston's talk on PING which I didn't understand
clearly before was that LEO wasn't just close to use, but that it was much
better protected from radiation.

    > "Data centers are big energy consumers – between 2% and 3% of all
    > global consumption – a rate that is doubling every year."

Back in 2000 the coal industry did a "study" that explained how coal was
critical to Internet growth.  Their modelling assumed every home router used
the same power as a Cisco 7000 series 14U router.

    > The latest was IEA estimating it to be around 220-320 TWh (out of
    > 30,000) in 2021 data and growing between 10-60% over 6 years in total
    > (so let's than 10 CAGR). But it's certainly not doubling every
    > year. That's just completely wrong.

+1
A related number is density: what's the power required/gigaflop?
And when will countries start rating themselves by gigaflops rather than tons
of steel or barrels of oil?

{You down the street from Bistol Aerospace?}

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide





[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 515 bytes --]

Re: [Starlink] [E-impact] DataCenters in Space (was Re: fiber IXPs in space)

[David Lang]

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

On Thu, 20 Apr 2023, Daniel Schien via Starlink wrote:

> I assume any object in orbit will be hidden from the sun some of the time. So, the machines will require some pretty big battery to go up with them.

less than you would think, as you get further away from the earth, the shadow of 
the earth is smaller (think about a lunar eclipse, the shadow of the earth is 
barely the size of the moon, and the eclipse doesn't last very long)

> I'd like to also know what the launch cost is.

Shuttle was ~50k/Kg
pre-spacex expendable rockets were ~$10k/kg
Falcon 9 has driven costs down into the ballpark of $1k/Kg (with indications 
that SpaceX internal costs may be significantly lower, but they price their 
launches at what the market will bear, under their competitors pricing)
Starship could get this down to under $10/Kg

David Lang

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

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

Re: [Starlink] DataCenters in Space (was Re: fiber IXPs in space)

[Hesham ElBakoury]

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

Yves Durand is the director of technology at Thales Alenia Space, the joint
venture charged with studying the feasibility of space data centers, with
the goal of deploying them in the early 2030s.

The article I sent before says: "Durand doesn’t doubt the viability of
building a data center in space, and says that construction will be “fully
automated – no astronauts. In fact, the project involves development of
special, robotic assembly technology.” A founding principle is to design a
modular facility with electronic components that can be easily transported
on a reusable space shuttles. Unlike terrestrial, fiber-based communication
facilities, the data centers in space will use optical technology."

Hesham

On Wed, Apr 19, 2023, 6:16 PM Vint Cerf via Starlink <
starlink@lists.bufferbloat.net> wrote:

> O&M will be a bear
> v
>
>
> On Wed, Apr 19, 2023 at 9:13 PM Tom Evslin via Starlink <
> starlink@lists.bufferbloat.net> wrote:
>
>> I think space-based data centers will be the rule rather than the
>> exception. Wrote about that a couple of years ago although, as usual,
>> things have not happened as quickly as I predicted
>> https://blog.tomevslin.com/2021/07/computing-clouds-in-orbit-a-possible-roadmap.html
>>
>> -----Original Message-----
>> From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf Of
>> Michael Richardson via Starlink
>> Sent: Wednesday, April 19, 2023 7:35 PM
>> To: starlink <starlink@lists.bufferbloat.net>; e-impact@ietf.org
>> Subject: [Starlink] DataCenters in Space (was Re: fiber IXPs in space)
>>
>>
>> I saw this reported in BIS-Spaceflight.
>> (I'm usually a few months behind in reading it) I like the "first
>> objective"!
>>
>>
>> https://www.thalesgroup.com/en/worldwide/space/press-release/ascend-thales-alenia-space-lead-european-feasibility-study-data
>>
>> Cannes, November 14, 2022 – Thales Alenia Space, the joint company
>> between Thales (67%) and Leonardo (33%), has been chosen by the European
>> Commission to lead the ASCEND (Advanced Space Cloud for European Net zero
>> emission and Data sovereignty) feasibility study for data centers in orbit,
>> as part of Europe’s vast Horizon Europe research program.
>>
>> Digital technology’s expanding environmental footprint is becoming a major
>> challenge: the burgeoning need for digitalization means that data centers
>> in Europe and around the world are growing at an exponential pace, which in
>> turn has a critical energy and environmental impact.
>>
>> The first objective of this study will be to assess if the carbon
>> emissions from the production and launch of these space infrastructures
>> will be significantly lower than the emissions generated by ground-based
>> data centers, therefore contributing to the achievement of global carbon
>> neutrality. The second objective will be to prove that it is possible to
>> develop the required launch solution and to ensure the deployment and
>> operability of these spaceborne data centers using robotic assistance
>> technologies currently being developed in Europe, such as the EROSS IOD
>> demonstrator.
>>
>> This project is expected to demonstrate to which extent space-based data
>> centers would limit the energy and environmental impact of their ground
>> counterparts, thus allowing major investments within the scope of Europe’s
>> Green Deal, possibly justifying the development of a more climate-friendly,
>> reusable heavy launch vehicle. Europe could thus regain its leadership in
>> space transport and space logistics, as well as the assembly and operations
>> of large infrastructures in orbit.
>>
>> _______________________________________________
>> 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
> Google, LLC
> 1900 Reston Metro Plaza, 16th Floor
> Reston, VA 20190
> +1 (571) 213 1346
>
>
> until further notice
>
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>

[-- Attachment #2: Type: text/html, Size: 7354 bytes --]

Re: [Starlink] DataCenters in Space (was Re: fiber IXPs in space)

[Nathan Owens]

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

Cheap(ish) Space to Earth optical has been tested by NASA/MIT with the
T-BIRD sat -- it used 2x 100G CFP optics and an off-the-shelf EDFA to send
200Gbps to a 12in telescope on earth while it was overhead.

On Thu, Apr 20, 2023 at 4:25 AM Hesham ElBakoury via Starlink <
starlink@lists.bufferbloat.net> wrote:

> Yves Durand is the director of technology at Thales Alenia Space, the
> joint venture charged with studying the feasibility of space data centers,
> with the goal of deploying them in the early 2030s.
>
> The article I sent before says: "Durand doesn’t doubt the viability of
> building a data center in space, and says that construction will be “fully
> automated – no astronauts. In fact, the project involves development of
> special, robotic assembly technology.” A founding principle is to design a
> modular facility with electronic components that can be easily transported
> on a reusable space shuttles. Unlike terrestrial, fiber-based communication
> facilities, the data centers in space will use optical technology."
>
> Hesham
>
> On Wed, Apr 19, 2023, 6:16 PM Vint Cerf via Starlink <
> starlink@lists.bufferbloat.net> wrote:
>
>> O&M will be a bear
>> v
>>
>>
>> On Wed, Apr 19, 2023 at 9:13 PM Tom Evslin via Starlink <
>> starlink@lists.bufferbloat.net> wrote:
>>
>>> I think space-based data centers will be the rule rather than the
>>> exception. Wrote about that a couple of years ago although, as usual,
>>> things have not happened as quickly as I predicted
>>> https://blog.tomevslin.com/2021/07/computing-clouds-in-orbit-a-possible-roadmap.html
>>>
>>> -----Original Message-----
>>> From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf Of
>>> Michael Richardson via Starlink
>>> Sent: Wednesday, April 19, 2023 7:35 PM
>>> To: starlink <starlink@lists.bufferbloat.net>; e-impact@ietf.org
>>> Subject: [Starlink] DataCenters in Space (was Re: fiber IXPs in space)
>>>
>>>
>>> I saw this reported in BIS-Spaceflight.
>>> (I'm usually a few months behind in reading it) I like the "first
>>> objective"!
>>>
>>>
>>> https://www.thalesgroup.com/en/worldwide/space/press-release/ascend-thales-alenia-space-lead-european-feasibility-study-data
>>>
>>> Cannes, November 14, 2022 – Thales Alenia Space, the joint company
>>> between Thales (67%) and Leonardo (33%), has been chosen by the European
>>> Commission to lead the ASCEND (Advanced Space Cloud for European Net zero
>>> emission and Data sovereignty) feasibility study for data centers in orbit,
>>> as part of Europe’s vast Horizon Europe research program.
>>>
>>> Digital technology’s expanding environmental footprint is becoming a
>>> major
>>> challenge: the burgeoning need for digitalization means that data
>>> centers in Europe and around the world are growing at an exponential pace,
>>> which in turn has a critical energy and environmental impact.
>>>
>>> The first objective of this study will be to assess if the carbon
>>> emissions from the production and launch of these space infrastructures
>>> will be significantly lower than the emissions generated by ground-based
>>> data centers, therefore contributing to the achievement of global carbon
>>> neutrality. The second objective will be to prove that it is possible to
>>> develop the required launch solution and to ensure the deployment and
>>> operability of these spaceborne data centers using robotic assistance
>>> technologies currently being developed in Europe, such as the EROSS IOD
>>> demonstrator.
>>>
>>> This project is expected to demonstrate to which extent space-based data
>>> centers would limit the energy and environmental impact of their ground
>>> counterparts, thus allowing major investments within the scope of Europe’s
>>> Green Deal, possibly justifying the development of a more climate-friendly,
>>> reusable heavy launch vehicle. Europe could thus regain its leadership in
>>> space transport and space logistics, as well as the assembly and operations
>>> of large infrastructures in orbit.
>>>
>>> _______________________________________________
>>> 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
>> Google, LLC
>> 1900 Reston Metro Plaza, 16th Floor
>> Reston, VA 20190
>> +1 (571) 213 1346
>>
>>
>> until further notice
>>
>>
>>
>> _______________________________________________
>> 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
>

[-- Attachment #2: Type: text/html, Size: 8328 bytes --]

Re: [Starlink] DataCenters in Space (was Re: fiber IXPs in space)

[Mike Puchol]

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

The only way these large constellations are going to be able to realize the promised capacities is by jumping the THz gap and use optical space-to-ground links. I see advances in coherent light giving gains in link budgets, and every time I ask someone in the FSOC industry “couldn’t you use UV lasers?” I get first a puzzled “are you crazy?” look, but is sometimes  followed by a “wait… wat…” look. Other than the inherent danger to humans, UV penetrates clouds nicely.

I eventually see caches onboard satellites, which conform a homogeneous mega-cache, able to improve hit ratio by use of ISL to route traffic to the right nodes. You actually need this as the satellites are constantly moving, so if you have to solve that problem, why not then to the whole way and take advantage?

Best,

Mike
On Apr 20, 2023 at 14:28 +0300, Nathan Owens via Starlink <starlink@lists.bufferbloat.net>, wrote:
> Cheap(ish) Space to Earth optical has been tested by NASA/MIT with the T-BIRD sat -- it used 2x 100G CFP optics and an off-the-shelf EDFA to send 200Gbps to a 12in telescope on earth while it was overhead.
>
> > On Thu, Apr 20, 2023 at 4:25 AM Hesham ElBakoury via Starlink <starlink@lists.bufferbloat.net> wrote:
> > > Yves Durand is the director of technology at Thales Alenia Space, the joint venture charged with studying the feasibility of space data centers, with the goal of deploying them in the early 2030s.
> > >
> > > The article I sent before says: "Durand doesn’t doubt the viability of building a data center in space, and says that construction will be “fully automated – no astronauts. In fact, the project involves development of special, robotic assembly technology.” A founding principle is to design a modular facility with electronic components that can be easily transported on a reusable space shuttles. Unlike terrestrial, fiber-based communication facilities, the data centers in space will use optical technology."
> > >
> > > Hesham
> > >
> > > > On Wed, Apr 19, 2023, 6:16 PM Vint Cerf via Starlink <starlink@lists.bufferbloat.net> wrote:
> > > > > O&M will be a bear
> > > > > v
> > > > >
> > > > >
> > > > > > On Wed, Apr 19, 2023 at 9:13 PM Tom Evslin via Starlink <starlink@lists.bufferbloat.net> wrote:
> > > > > > > I think space-based data centers will be the rule rather than the exception. Wrote about that a couple of years ago although, as usual, things have not happened as quickly as I predicted https://blog.tomevslin.com/2021/07/computing-clouds-in-orbit-a-possible-roadmap.html
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf Of Michael Richardson via Starlink
> > > > > > > Sent: Wednesday, April 19, 2023 7:35 PM
> > > > > > > To: starlink <starlink@lists.bufferbloat.net>; e-impact@ietf.org
> > > > > > > Subject: [Starlink] DataCenters in Space (was Re: fiber IXPs in space)
> > > > > > >
> > > > > > >
> > > > > > > I saw this reported in BIS-Spaceflight.
> > > > > > > (I'm usually a few months behind in reading it) I like the "first objective"!
> > > > > > >
> > > > > > > https://www.thalesgroup.com/en/worldwide/space/press-release/ascend-thales-alenia-space-lead-european-feasibility-study-data
> > > > > > >
> > > > > > > Cannes, November 14, 2022 – Thales Alenia Space, the joint company between Thales (67%) and Leonardo (33%), has been chosen by the European Commission to lead the ASCEND (Advanced Space Cloud for European Net zero emission and Data sovereignty) feasibility study for data centers in orbit, as part of Europe’s vast Horizon Europe research program.
> > > > > > >
> > > > > > > Digital technology’s expanding environmental footprint is becoming a major
> > > > > > > challenge: the burgeoning need for digitalization means that data centers in Europe and around the world are growing at an exponential pace, which in turn has a critical energy and environmental impact.
> > > > > > >
> > > > > > > The first objective of this study will be to assess if the carbon emissions from the production and launch of these space infrastructures will be significantly lower than the emissions generated by ground-based data centers, therefore contributing to the achievement of global carbon neutrality. The second objective will be to prove that it is possible to develop the required launch solution and to ensure the deployment and operability of these spaceborne data centers using robotic assistance technologies currently being developed in Europe, such as the EROSS IOD demonstrator.
> > > > > > >
> > > > > > > This project is expected to demonstrate to which extent space-based data centers would limit the energy and environmental impact of their ground counterparts, thus allowing major investments within the scope of Europe’s Green Deal, possibly justifying the development of a more climate-friendly, reusable heavy launch vehicle. Europe could thus regain its leadership in space transport and space logistics, as well as the assembly and operations of large infrastructures in orbit.
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > 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
> > > > > Google, LLC
> > > > > 1900 Reston Metro Plaza, 16th Floor
> > > > > Reston, VA 20190
> > > > > +1 (571) 213 1346
> > > > >
> > > > >
> > > > > until further notice
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > 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

[-- Attachment #2: Type: text/html, Size: 10071 bytes --]

Re: [Starlink] DataCenters in Space (was Re: fiber IXPs in space)

[Michael Richardson]

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


Mike Puchol via Starlink <starlink@lists.bufferbloat.net> wrote:
    > but is sometimes  followed by a “wait… wat…” look. Other than the
    > inherent danger to humans, UV penetrates clouds nicely.

"Hey Kids, if you are gonna watch Youtube, remember to wear your UV sunscreen!"


--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide





[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 515 bytes --]

Re: [Starlink] DataCenters in Space (was Re: fiber IXPs in space)

[Ulrich Speidel]

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

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/
****************************************************************



-------- Original message --------
From: Tom Evslin via Starlink <starlink@lists.bufferbloat.net>
Date: 20/04/23 1:13 pm (GMT+12:00)
To: 'Michael Richardson' <mcr@sandelman.ca>, 'starlink' <starlink@lists.bufferbloat.net>, e-impact@ietf.org
Subject: Re: [Starlink] DataCenters in Space (was Re: fiber IXPs in space)

I think space-based data centers will be the rule rather than the exception. Wrote about that a couple of years ago although, as usual, things have not happened as quickly as I predicted https://blog.tomevslin.com/2021/07/computing-clouds-in-orbit-a-possible-roadmap.html<https://blog.tomevslin.com/2021/07/computing-clouds-in-orbit-a-possible-roadmap.html>

-----Original Message-----
From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf Of Michael Richardson via Starlink
Sent: Wednesday, April 19, 2023 7:35 PM
To: starlink <starlink@lists.bufferbloat.net>; e-impact@ietf.org
Subject: [Starlink] DataCenters in Space (was Re: fiber IXPs in space)


I saw this reported in BIS-Spaceflight.
(I'm usually a few months behind in reading it) I like the "first objective"!

https://www.thalesgroup.com/en/worldwide/space/press-release/ascend-thales-alenia-space-lead-european-feasibility-study-data<https://www.thalesgroup.com/en/worldwide/space/press-release/ascend-thales-alenia-space-lead-european-feasibility-study-data>

Cannes, November 14, 2022 – Thales Alenia Space, the joint company between Thales (67%) and Leonardo (33%), has been chosen by the European Commission to lead the ASCEND (Advanced Space Cloud for European Net zero emission and Data sovereignty) feasibility study for data centers in orbit, as part of Europe’s vast Horizon Europe research program.

Digital technology’s expanding environmental footprint is becoming a major
challenge: the burgeoning need for digitalization means that data centers in Europe and around the world are growing at an exponential pace, which in turn has a critical energy and environmental impact.

The first objective of this study will be to assess if the carbon emissions from the production and launch of these space infrastructures will be significantly lower than the emissions generated by ground-based data centers, therefore contributing to the achievement of global carbon neutrality. The second objective will be to prove that it is possible to develop the required launch solution and to ensure the deployment and operability of these spaceborne data centers using robotic assistance technologies currently being developed in Europe, such as the EROSS IOD demonstrator.

This project is expected to demonstrate to which extent space-based data centers would limit the energy and environmental impact of their ground counterparts, thus allowing major investments within the scope of Europe’s Green Deal, possibly justifying the development of a more climate-friendly, reusable heavy launch vehicle. Europe could thus regain its leadership in space transport and space logistics, as well as the assembly and operations of large infrastructures in orbit.

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

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

[-- Attachment #2: Type: text/html, Size: 5863 bytes --]

Re: [Starlink] DataCenters in Space (was Re: fiber IXPs in space)

[Michael Richardson]

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


Ulrich Speidel <u.speidel@auckland.ac.nz> wrote:
    > 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?

Oh, yeah, you are totally right on all of these points.
* Not all DC processing is user-facing though!
* Some are just pure compute loads.
* Some of the customers for these DCs might be in space in the future.

    > 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...

Agreed.

I think that the useful/interesting result of this effort will be a
peer-reviewed model with some parameters that can be plugged into.
At 2025 prices, space-DC might not be useful.
Perhaps at 2035 prices, the balance might change.




--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide





[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 515 bytes --]

Re: [Starlink] fiber IXPs in space

[David Fernández]

In case you put a DNS server in the satellite, so that it replies
instead of a DNS server on ground, the RTT is reduced by half.

The idea would be that the satellite inspects IP packets and when it
detects a DNS query, instead of forwarding the packet to ground
station, it just answers back to the sender of the query.

Nowadays, satellites (starlink included) are still transparent and are
signal repeaters, not routers processing IP packets, so doing this is
not immediate at all, but it could bring some benefits.

CDNs or even datacenters (Cloud) in GEO or LEO is even more complex.

Regards,

David

Re: [Starlink] fiber IXPs in space

[Ulrich Speidel]

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

On 17/04/2023 5:54 am, David Fernández via Starlink wrote:
> In case you put a DNS server in the satellite, so that it replies
> instead of a DNS server on ground, the RTT is reduced by half.
>
> The idea would be that the satellite inspects IP packets and when it
> detects a DNS query, instead of forwarding the packet to ground
> station, it just answers back to the sender of the query.
Understood - it's just that the gain you have from this is quite small. 
DNS queries only happen the first time a host needs to resolve a name, 
and then again after cache expiry much later, so they account for only a 
tiny fraction of the traffic, and also for only a small amount of the 
total delay in page loads. RTT isn't really the big issue in Starlink - 
yes it's larger than it perhaps needs to be, and bufferbloat seems to be 
present, but compared to GEO, it's now in the range seen for terrestrial 
Internet.
>
> Nowadays, satellites (starlink included) are still transparent and are
> signal repeaters, not routers processing IP packets, so doing this is
> not immediate at all, but it could bring some benefits.

Yes, but the benefits are quite small.

>
> CDNs or even datacenters (Cloud) in GEO or LEO is even more complex.

Indeed. In so many ways.

Mind though that CDNs are generally tied in with DNS nowadays, and 
there's another snag: Take two users, Alice in the UK and Bob in New 
Zealand - pretty much antipodean, using Starlink in bent-pipe 
configuration, i.e., their traffic goes through, say, the London gateway 
in the UK and the Clevedon gateway in NZ. Now imagine both trying to 
resolve the same CDN hostname some time apart, but via the same 
satellite DNS as the satellite has moved from the UK to NZ in the 
interim. Say Alice resolves first and gets the IP address of a CDN 
server in the UK. If the satellite DNS now caches this, and Bob queries 
the same hostname, he gets directed to a server in the UK literally a 
world away instead of the Auckland one closest to him. So unless each 
satellite carries a geolocated copy of the world's DNS entries with it 
and makes a decision based on user location, you have a problem.

>
> Regards,
>
> David
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink 
> <https://lists.bufferbloat.net/listinfo/starlink>

-- 
****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel@auckland.ac.nz  
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************



[-- Attachment #2: Type: text/html, Size: 4080 bytes --]

Re: [Starlink] fiber IXPs in space

[David Lang]

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

On Mon, 17 Apr 2023, Ulrich Speidel via Starlink wrote:

> On 17/04/2023 5:54 am, David Fernández via Starlink wrote:
>> In case you put a DNS server in the satellite, so that it replies
>> instead of a DNS server on ground, the RTT is reduced by half.
>> 
>> The idea would be that the satellite inspects IP packets and when it
>> detects a DNS query, instead of forwarding the packet to ground
>> station, it just answers back to the sender of the query.

> Understood - it's just that the gain you have from this is quite small. DNS 
> queries only happen the first time a host needs to resolve a name, and then 
> again after cache expiry much later, so they account for only a tiny fraction 
> of the traffic, and also for only a small amount of the total delay in page 
> loads. RTT isn't really the big issue in Starlink - yes it's larger than it 
> perhaps needs to be, and bufferbloat seems to be present, but compared to 
> GEO, it's now in the range seen for terrestrial Internet.

DNS time is more significant than you think, due to the fact that so many 
websites pull data from many different locations, you end up with a lot of DNS 
queries when hitting a new site for the first time (and many of these queries 
are serial not parallel) so it adds quite a bit to the first rendering time of a 
page.

>> CDNs or even datacenters (Cloud) in GEO or LEO is even more complex.
>
> Indeed. In so many ways.
>
> Mind though that CDNs are generally tied in with DNS nowadays, and there's 
> another snag: Take two users, Alice in the UK and Bob in New Zealand - pretty 
> much antipodean, using Starlink in bent-pipe configuration, i.e., their 
> traffic goes through, say, the London gateway in the UK and the Clevedon 
> gateway in NZ. Now imagine both trying to resolve the same CDN hostname some 
> time apart, but via the same satellite DNS as the satellite has moved from 
> the UK to NZ in the interim. Say Alice resolves first and gets the IP address 
> of a CDN server in the UK. If the satellite DNS now caches this, and Bob 
> queries the same hostname, he gets directed to a server in the UK literally a 
> world away instead of the Auckland one closest to him. So unless each 
> satellite carries a geolocated copy of the world's DNS entries with it and 
> makes a decision based on user location, you have a problem.

This is true when the DNS answer is dynamic, but such cases also have short 
cache timeouts. Even with a 90 min orbit, a 15 min timeout would significantly 
lessen the impact (and I would expect that an orbital DNS would detect short 
timeouts and treat them as a signal to shorten the timeout even more)

David Lang

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

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

Re: [Starlink] fiber IXPs in space

[Ulrich Speidel]

On 17/04/2023 10:03 am, David Lang wrote:
> On Mon, 17 Apr 2023, Ulrich Speidel via Starlink wrote:
>
>> On 17/04/2023 5:54 am, David Fernández via Starlink wrote:
>>> In case you put a DNS server in the satellite, so that it replies
>>> instead of a DNS server on ground, the RTT is reduced by half.
>>>
>>> The idea would be that the satellite inspects IP packets and when it
>>> detects a DNS query, instead of forwarding the packet to ground
>>> station, it just answers back to the sender of the query.
>> Understood - it's just that the gain you have from this is quite 
>> small. DNS queries only happen the first time a host needs to resolve 
>> a name, and then again after cache expiry much later, so they account 
>> for only a tiny fraction of the traffic, and also for only a small 
>> amount of the total delay in page loads. RTT isn't really the big 
>> issue in Starlink - yes it's larger than it perhaps needs to be, and 
>> bufferbloat seems to be present, but compared to GEO, it's now in the 
>> range seen for terrestrial Internet.
>
> DNS time is more significant than you think, due to the fact that so 
> many websites pull data from many different locations, you end up with 
> a lot of DNS queries when hitting a new site for the first time (and 
> many of these queries are serial not parallel) so it adds quite a bit 
> to the first rendering time of a page.
But most people don't hit new sites most of the time, and a lot of 
cascading loads hit the same CDNs you've seen previously.
>
>>> CDNs or even datacenters (Cloud) in GEO or LEO is even more complex.
>>
>> Indeed. In so many ways.
>>
>> Mind though that CDNs are generally tied in with DNS nowadays, and 
>> there's another snag: Take two users, Alice in the UK and Bob in New 
>> Zealand - pretty much antipodean, using Starlink in bent-pipe 
>> configuration, i.e., their traffic goes through, say, the London 
>> gateway in the UK and the Clevedon gateway in NZ. Now imagine both 
>> trying to resolve the same CDN hostname some time apart, but via the 
>> same satellite DNS as the satellite has moved from the UK to NZ in 
>> the interim. Say Alice resolves first and gets the IP address of a 
>> CDN server in the UK. If the satellite DNS now caches this, and Bob 
>> queries the same hostname, he gets directed to a server in the UK 
>> literally a world away instead of the Auckland one closest to him. So 
>> unless each satellite carries a geolocated copy of the world's DNS 
>> entries with it and makes a decision based on user location, you have 
>> a problem.
>
> This is true when the DNS answer is dynamic, but such cases also have 
> short cache timeouts. Even with a 90 min orbit, a 15 min timeout would 
> significantly lessen the impact (and I would expect that an orbital 
> DNS would detect short timeouts and treat them as a signal to shorten 
> the timeout even more)

Timeout where? At the end user client or at the satellite?

At the end user client, a short timeout makes no sense at all because 
their host-to-CDN-IP server mapping shouldn't really change in bent pipe 
- only the sat hop changes.

If the timeout is meant to be on the satellite, it means that the 
satellite knows nothing about anything when it arrives to assist you, 
and needs to query some sort of (probably ground-based) DNS server anyway.

Also, the assumption that a satellite will return to the same spot after 
a full orbital period (of say 90 minutes) only applies to satellites in 
equatorial orbits (or polar orbits, and then only to the poles). In all 
other cases, the Earth's rotation will assure that the satellite's 
return to the same location takes many orbital periods.

>
> David Lang
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>
-- 
****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel@auckland.ac.nz
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************

Re: [Starlink] fiber IXPs in space

[David Lang]

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

On Mon, 17 Apr 2023, Ulrich Speidel wrote:

> On 17/04/2023 10:03 am, David Lang wrote:
>> On Mon, 17 Apr 2023, Ulrich Speidel via Starlink wrote:
>> 
>>> On 17/04/2023 5:54 am, David Fernández via Starlink wrote:
>>>> In case you put a DNS server in the satellite, so that it replies
>>>> instead of a DNS server on ground, the RTT is reduced by half.
>>>> 
>>>> The idea would be that the satellite inspects IP packets and when it
>>>> detects a DNS query, instead of forwarding the packet to ground
>>>> station, it just answers back to the sender of the query.
>>> Understood - it's just that the gain you have from this is quite small. 
>>> DNS queries only happen the first time a host needs to resolve a name, and 
>>> then again after cache expiry much later, so they account for only a tiny 
>>> fraction of the traffic, and also for only a small amount of the total 
>>> delay in page loads. RTT isn't really the big issue in Starlink - yes it's 
>>> larger than it perhaps needs to be, and bufferbloat seems to be present, 
>>> but compared to GEO, it's now in the range seen for terrestrial Internet.
>> 
>> DNS time is more significant than you think, due to the fact that so many 
>> websites pull data from many different locations, you end up with a lot of 
>> DNS queries when hitting a new site for the first time (and many of these 
>> queries are serial not parallel) so it adds quite a bit to the first 
>> rendering time of a page.
> But most people don't hit new sites most of the time, and a lot of cascading 
> loads hit the same CDNs you've seen previously.

the timeouts on DNS are short enough that they hit them every day when they wake 
up

>>>> CDNs or even datacenters (Cloud) in GEO or LEO is even more complex.
>>> 
>>> Indeed. In so many ways.
>>> 
>>> Mind though that CDNs are generally tied in with DNS nowadays, and there's 
>>> another snag: Take two users, Alice in the UK and Bob in New Zealand - 
>>> pretty much antipodean, using Starlink in bent-pipe configuration, i.e., 
>>> their traffic goes through, say, the London gateway in the UK and the 
>>> Clevedon gateway in NZ. Now imagine both trying to resolve the same CDN 
>>> hostname some time apart, but via the same satellite DNS as the satellite 
>>> has moved from the UK to NZ in the interim. Say Alice resolves first and 
>>> gets the IP address of a CDN server in the UK. If the satellite DNS now 
>>> caches this, and Bob queries the same hostname, he gets directed to a 
>>> server in the UK literally a world away instead of the Auckland one 
>>> closest to him. So unless each satellite carries a geolocated copy of the 
>>> world's DNS entries with it and makes a decision based on user location, 
>>> you have a problem.
>> 
>> This is true when the DNS answer is dynamic, but such cases also have short 
>> cache timeouts. Even with a 90 min orbit, a 15 min timeout would 
>> significantly lessen the impact (and I would expect that an orbital DNS 
>> would detect short timeouts and treat them as a signal to shorten the 
>> timeout even more)
>
> Timeout where? At the end user client or at the satellite?

at the DNS cache and at the client. If you are using DNS to redirect people to 
the closest/least loaded site, you need to have your DNS timeouts set short so 
that you can change where they go with minimal downtime. Many clients refuse to 
honor extremely short timeouts (IIRC about 15 min is the low end)

> At the end user client, a short timeout makes no sense at all because their 
> host-to-CDN-IP server mapping shouldn't really change in bent pipe - only the 
> sat hop changes.
>
> If the timeout is meant to be on the satellite, it means that the satellite 
> knows nothing about anything when it arrives to assist you, and needs to 
> query some sort of (probably ground-based) DNS server anyway.
>
> Also, the assumption that a satellite will return to the same spot after a 
> full orbital period (of say 90 minutes) only applies to satellites in 
> equatorial orbits (or polar orbits, and then only to the poles). In all other 
> cases, the Earth's rotation will assure that the satellite's return to the 
> same location takes many orbital periods.

when the satellite first comes into an area, it won't know what's appropriate to 
cach for the area, but it will start caching when people start using it, the 
first person suffers the full hit, but everyone after that benefits.

DNS data is not that large, getting enough storage into the satellites to serve 
90% of the non-dynamic data should not be a big deal. The dynamic data expires 
fast enough (and can be detected as being dynamic and expired faster in the 
satellite) that I'm not worried about serving data from one side of the world to 
the other.

David Lang

Re: [Starlink] fiber IXPs in space

[Ulrich Speidel]

On 17/04/2023 11:22 am, David Lang wrote:
> On Mon, 17 Apr 2023, Ulrich Speidel wrote:
>
>> On 17/04/2023 10:03 am, David Lang wrote:
>>> On Mon, 17 Apr 2023, Ulrich Speidel via Starlink wrote:
>>>
>>>> On 17/04/2023 5:54 am, David Fernández via Starlink wrote:
>>>>> In case you put a DNS server in the satellite, so that it replies
>>>>> instead of a DNS server on ground, the RTT is reduced by half.
>>>>>
>>>>> The idea would be that the satellite inspects IP packets and when it
>>>>> detects a DNS query, instead of forwarding the packet to ground
>>>>> station, it just answers back to the sender of the query.
>>>> Understood - it's just that the gain you have from this is quite 
>>>> small. DNS queries only happen the first time a host needs to 
>>>> resolve a name, and then again after cache expiry much later, so 
>>>> they account for only a tiny fraction of the traffic, and also for 
>>>> only a small amount of the total delay in page loads. RTT isn't 
>>>> really the big issue in Starlink - yes it's larger than it perhaps 
>>>> needs to be, and bufferbloat seems to be present, but compared to 
>>>> GEO, it's now in the range seen for terrestrial Internet.
>>>
>>> DNS time is more significant than you think, due to the fact that so 
>>> many websites pull data from many different locations, you end up 
>>> with a lot of DNS queries when hitting a new site for the first time 
>>> (and many of these queries are serial not parallel) so it adds quite 
>>> a bit to the first rendering time of a page.
>> But most people don't hit new sites most of the time, and a lot of 
>> cascading loads hit the same CDNs you've seen previously.
>
> the timeouts on DNS are short enough that they hit them every day when 
> they wake up

That's OK (and has to be that way or else DNS changes would never 
propagate).

But, an end client, typically hits the same site many times within a 
relatively short time window. For this, it does only need to do do one 
lookup. The client will then cache the entry. If it needs to look up 
again 15 minutes plus later doesn't really matter in terms of a LEO 
system - the client will be talking to a different satellite by then.

Also, the percentage of DNS queries relating to CDN servers is very high 
nowadays, because CDN use is so pervasive that people will claim that 
there is an "Internet outage" when a CDN goes down.

>
>>>>> CDNs or even datacenters (Cloud) in GEO or LEO is even more complex.
>>>>
>>>> Indeed. In so many ways.
>>>>
>>>> Mind though that CDNs are generally tied in with DNS nowadays, and 
>>>> there's another snag: Take two users, Alice in the UK and Bob in 
>>>> New Zealand - pretty much antipodean, using Starlink in bent-pipe 
>>>> configuration, i.e., their traffic goes through, say, the London 
>>>> gateway in the UK and the Clevedon gateway in NZ. Now imagine both 
>>>> trying to resolve the same CDN hostname some time apart, but via 
>>>> the same satellite DNS as the satellite has moved from the UK to NZ 
>>>> in the interim. Say Alice resolves first and gets the IP address of 
>>>> a CDN server in the UK. If the satellite DNS now caches this, and 
>>>> Bob queries the same hostname, he gets directed to a server in the 
>>>> UK literally a world away instead of the Auckland one closest to 
>>>> him. So unless each satellite carries a geolocated copy of the 
>>>> world's DNS entries with it and makes a decision based on user 
>>>> location, you have a problem.
>>>
>>> This is true when the DNS answer is dynamic, but such cases also 
>>> have short cache timeouts. Even with a 90 min orbit, a 15 min 
>>> timeout would significantly lessen the impact (and I would expect 
>>> that an orbital DNS would detect short timeouts and treat them as a 
>>> signal to shorten the timeout even more)
>>
>> Timeout where? At the end user client or at the satellite?
>
> at the DNS cache and at the client. If you are using DNS to redirect 
> people to the closest/least loaded site, you need to have your DNS 
> timeouts set short so that you can change where they go with minimal 
> downtime. Many clients refuse to honor extremely short timeouts (IIRC 
> about 15 min is the low end)
>
>> At the end user client, a short timeout makes no sense at all because 
>> their host-to-CDN-IP server mapping shouldn't really change in bent 
>> pipe - only the sat hop changes.
>>
>> If the timeout is meant to be on the satellite, it means that the 
>> satellite knows nothing about anything when it arrives to assist you, 
>> and needs to query some sort of (probably ground-based) DNS server 
>> anyway.
>>
>> Also, the assumption that a satellite will return to the same spot 
>> after a full orbital period (of say 90 minutes) only applies to 
>> satellites in equatorial orbits (or polar orbits, and then only to 
>> the poles). In all other cases, the Earth's rotation will assure that 
>> the satellite's return to the same location takes many orbital periods.
>
> when the satellite first comes into an area, it won't know what's 
> appropriate to cach for the area, but it will start caching when 
> people start using it, the first person suffers the full hit, but 
> everyone after that benefits.

Yes, full understood. That's how it works on terrestrial DNS (and even 
on GEO this would be a really good argument). But on LEO, that benefit 
only materialises if the second client and any others in the same area 
get to query the same satellite that handled the first client's query, 
because that's where the information would be cached if we had a DNS 
server of sorts on each bird. For this to happen, the second client and 
any subsequent ones have to query within minutes if not seconds of the 
first one. What is the probability for this to happen? This depends on 
the total number of active users hanging off that satellite and the 
popularity of the target host/site among them. The larger the number of 
users and the higher the site popularity, the more likely that cached 
entries will see a second or subsequent query. "Active" in this context 
means users navigating to new sites during the visibility window of that 
satellite.

Practically speaking, we know from various sources that each Starlink 
satellite provides - ballpark - a couple of dozen Gb/s in capacity, and 
that active users on a "busy" satellite see a couple of dozen Mb/s of 
that. "Busy" means most active users, and so we can conclude that the 
number of users per satellite who use any site is at most around 1000. 
The subset of users navigating to new sites among them is probably in 
the low 100's at best. If we're excluding new sites that aren't dynamic, 
we're probably down to a couple of dozen new static sites being queried 
per satellite pass. How many of these queries will be duplicates? Not a 
lot. If we're including sites that are dynamic, we're still not getting 
a huge probability of cache entry re-use.

>
> DNS data is not that large, getting enough storage into the satellites 
> to serve 90% of the non-dynamic data should not be a big deal. The 
> dynamic data expires fast enough (and can be detected as being dynamic 
> and expired faster in the satellite) that I'm not worried about 
> serving data from one side of the world to the other.
Yes, but the only advantage we'd get here is faster resolution for a 
very small subset of DNS queries.

-- 
****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel@auckland.ac.nz
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************

Re: [Starlink] fiber IXPs in space

[David Lang]

On Mon, 17 Apr 2023, Ulrich Speidel wrote:

>> at the DNS cache and at the client. If you are using DNS to redirect people 
>> to the closest/least loaded site, you need to have your DNS timeouts set 
>> short so that you can change where they go with minimal downtime. Many 
>> clients refuse to honor extremely short timeouts (IIRC about 15 min is the 
>> low end)
>> 
>>> At the end user client, a short timeout makes no sense at all because 
>>> their host-to-CDN-IP server mapping shouldn't really change in bent pipe - 
>>> only the sat hop changes.
>>> 
>>> If the timeout is meant to be on the satellite, it means that the 
>>> satellite knows nothing about anything when it arrives to assist you, and 
>>> needs to query some sort of (probably ground-based) DNS server anyway.
>>> 
>>> Also, the assumption that a satellite will return to the same spot after a 
>>> full orbital period (of say 90 minutes) only applies to satellites in 
>>> equatorial orbits (or polar orbits, and then only to the poles). In all 
>>> other cases, the Earth's rotation will assure that the satellite's return 
>>> to the same location takes many orbital periods.
>> 
>> when the satellite first comes into an area, it won't know what's 
>> appropriate to cach for the area, but it will start caching when people 
>> start using it, the first person suffers the full hit, but everyone after 
>> that benefits.
>
> Yes, full understood. That's how it works on terrestrial DNS (and even on GEO 
> this would be a really good argument). But on LEO, that benefit only 
> materialises if the second client and any others in the same area get to 
> query the same satellite that handled the first client's query, because 
> that's where the information would be cached if we had a DNS server of sorts 
> on each bird. For this to happen, the second client and any subsequent ones 
> have to query within minutes if not seconds of the first one. What is the 
> probability for this to happen? This depends on the total number of active 
> users hanging off that satellite and the popularity of the target host/site 
> among them. The larger the number of users and the higher the site 
> popularity, the more likely that cached entries will see a second or 
> subsequent query. "Active" in this context means users navigating to new 
> sites during the visibility window of that satellite.

I think it is going to be fairly common, but the beauty of the idea is that you 
don't have to risk much to try it. Long lived DNS answers (and especially root 
servers and TLD servers) can trivially be mirrored to the satellites, and you 
can experiment with caching to see what sort of hit rate you get. Even if you 
don't cache a lot of the CDN type traffic, it should still be a win to have the 
longer term stuff there.

> Practically speaking, we know from various sources that each Starlink 
> satellite provides - ballpark - a couple of dozen Gb/s in capacity, and that 
> active users on a "busy" satellite see a couple of dozen Mb/s of that. "Busy" 
> means most active users, and so we can conclude that the number of users per 
> satellite who use any site is at most around 1000. The subset of users 
> navigating to new sites among them is probably in the low 100's at best. If 
> we're excluding new sites that aren't dynamic, we're probably down to a 
> couple of dozen new static sites being queried per satellite pass. How many 
> of these queries will be duplicates? Not a lot. If we're including sites that 
> are dynamic, we're still not getting a huge probability of cache entry 
> re-use.

I think that each user is typically going to use a lot less than the 'couple 
dozen MB' that is the limits that we see, so the number of users in a cell would 
be much higher.

>> DNS data is not that large, getting enough storage into the satellites to 
>> serve 90% of the non-dynamic data should not be a big deal. The dynamic 
>> data expires fast enough (and can be detected as being dynamic and expired 
>> faster in the satellite) that I'm not worried about serving data from one 
>> side of the world to the other.
> Yes, but the only advantage we'd get here is faster resolution for a very 
> small subset of DNS queries.

and while that's not as big a win as faster resolution of a larger set, it's 
still a win.

There are various things that could be done if there is enough interest in 
starlink users to improve the CDN traffic, and it's not clear that misdirecting 
starlink users in some (or even many) cases would be that horrible. Geolocation 
is very imprecise at best and routinely misidentifies locations.

David Lang

Re: [Starlink] fiber IXPs in space

[Ulrich Speidel]

On 17/04/2023 1:04 pm, David Lang wrote:
> I think it is going to be fairly common, but the beauty of the idea is 
> that you don't have to risk much to try it. Long lived DNS answers 
> (and especially root servers and TLD servers) can trivially be 
> mirrored to the satellites, and you can experiment with caching to see 
> what sort of hit rate you get. Even if you don't cache a lot of the 
> CDN type traffic, it should still be a win to have the longer term 
> stuff there.

Yes - but root servers and TLD servers also get cached a long time at 
the clients. If each of your clients needs a root server and a few TLD 
lookups a day, it's not a huge gain in terms of performance.

It is however a significant step up in terms of complexity. E.g., your 
satellite-based DNS would have to point you at the TLD server that is 
topologically closest to your Starlink gateway, or risk a potentially 
much longer RTT for the lookup. So you'd need to maintain a list of TLD 
instances on your satellite-based DNS and return the one that 
corresponds to what your gateway-based DNS would get. Sure possible but 
more complex than a bog standard DNS server in a fixed network.

>
>> Practically speaking, we know from various sources that each Starlink 
>> satellite provides - ballpark - a couple of dozen Gb/s in capacity, 
>> and that active users on a "busy" satellite see a couple of dozen 
>> Mb/s of that. "Busy" means most active users, and so we can conclude 
>> that the number of users per satellite who use any site is at most 
>> around 1000. The subset of users navigating to new sites among them 
>> is probably in the low 100's at best. If we're excluding new sites 
>> that aren't dynamic, we're probably down to a couple of dozen new 
>> static sites being queried per satellite pass. How many of these 
>> queries will be duplicates? Not a lot. If we're including sites that 
>> are dynamic, we're still not getting a huge probability of cache 
>> entry re-use.
>
> I think that each user is typically going to use a lot less than the 
> 'couple dozen MB' that is the limits that we see, so the number of 
> users in a cell would be much higher.
Yes, but these users aren't "active" in the sense that they will be 
firing off DNS queries during the pass...
>
>>> DNS data is not that large, getting enough storage into the 
>>> satellites to serve 90% of the non-dynamic data should not be a big 
>>> deal. The dynamic data expires fast enough (and can be detected as 
>>> being dynamic and expired faster in the satellite) that I'm not 
>>> worried about serving data from one side of the world to the other.
>> Yes, but the only advantage we'd get here is faster resolution for a 
>> very small subset of DNS queries.
>
> and while that's not as big a win as faster resolution of a larger 
> set, it's still a win.
Yes, but are we chasing diminishing margins here when there are much 
bigger fish to fry?
>
> There are various things that could be done if there is enough 
> interest in starlink users to improve the CDN traffic, and it's not 
> clear that misdirecting starlink users in some (or even many) cases 
> would be that horrible. Geolocation is very imprecise at best and 
> routinely misidentifies locations.
See my comments on geolocation in my response to David Reed's post - I 
shouldn't have used that term.

-- 
****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel@auckland.ac.nz
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************

Re: [Starlink] fiber IXPs in space

[David Lang]

On Mon, 17 Apr 2023, Ulrich Speidel wrote:

> On 17/04/2023 1:04 pm, David Lang wrote:
>> I think it is going to be fairly common, but the beauty of the idea is that 
>> you don't have to risk much to try it. Long lived DNS answers (and 
>> especially root servers and TLD servers) can trivially be mirrored to the 
>> satellites, and you can experiment with caching to see what sort of hit 
>> rate you get. Even if you don't cache a lot of the CDN type traffic, it 
>> should still be a win to have the longer term stuff there.
>
> Yes - but root servers and TLD servers also get cached a long time at the 
> clients. If each of your clients needs a root server and a few TLD lookups a 
> day, it's not a huge gain in terms of performance.
>
> It is however a significant step up in terms of complexity. E.g., your 
> satellite-based DNS would have to point you at the TLD server that is 
> topologically closest to your Starlink gateway, or risk a potentially much 
> longer RTT for the lookup. So you'd need to maintain a list of TLD instances 
> on your satellite-based DNS and return the one that corresponds to what your 
> gateway-based DNS would get. Sure possible but more complex than a bog 
> standard DNS server in a fixed network.

really? I don't think the root and TLD servers do any geolocation, I think they 
have fixed answers and rely on anycast addresses to find the closest one. Adding 
those anycast addresses to the satellites would be transpoarent to all users 
(assuming the satellites are operating at the IP layer, the old bent-pipe 
approach did not, but once you have routing in space via the laser links...)

>>> Practically speaking, we know from various sources that each Starlink 
>>> satellite provides - ballpark - a couple of dozen Gb/s in capacity, and 
>>> that active users on a "busy" satellite see a couple of dozen Mb/s of 
>>> that. "Busy" means most active users, and so we can conclude that the 
>>> number of users per satellite who use any site is at most around 1000. The 
>>> subset of users navigating to new sites among them is probably in the low 
>>> 100's at best. If we're excluding new sites that aren't dynamic, we're 
>>> probably down to a couple of dozen new static sites being queried per 
>>> satellite pass. How many of these queries will be duplicates? Not a lot. 
>>> If we're including sites that are dynamic, we're still not getting a huge 
>>> probability of cache entry re-use.
>> 
>> I think that each user is typically going to use a lot less than the 
>> 'couple dozen MB' that is the limits that we see, so the number of users in 
>> a cell would be much higher.
> Yes, but these users aren't "active" in the sense that they will be firing 
> off DNS queries during the pass...

even users who are using the connection aren't going to be using dozens of MB of 
bandwidth.

>>>> DNS data is not that large, getting enough storage into the satellites to 
>>>> serve 90% of the non-dynamic data should not be a big deal. The dynamic 
>>>> data expires fast enough (and can be detected as being dynamic and 
>>>> expired faster in the satellite) that I'm not worried about serving data 
>>>> from one side of the world to the other.
>>> Yes, but the only advantage we'd get here is faster resolution for a very 
>>> small subset of DNS queries.
>> 
>> and while that's not as big a win as faster resolution of a larger set, 
>> it's still a win.
> Yes, but are we chasing diminishing margins here when there are much bigger 
> fish to fry?

possibly. it's worth discussing and DNS is an easy thing to start with compared 
to most others.

David Lang

Re: [Starlink] fiber IXPs in space

[Ulrich Speidel]

On 17/04/2023 2:34 pm, David Lang wrote:
> On Mon, 17 Apr 2023, Ulrich Speidel wrote:
>
>> On 17/04/2023 1:04 pm, David Lang wrote:
>>> I think it is going to be fairly common, but the beauty of the idea 
>>> is that you don't have to risk much to try it. Long lived DNS 
>>> answers (and especially root servers and TLD servers) can trivially 
>>> be mirrored to the satellites, and you can experiment with caching 
>>> to see what sort of hit rate you get. Even if you don't cache a lot 
>>> of the CDN type traffic, it should still be a win to have the longer 
>>> term stuff there.
>>
>> Yes - but root servers and TLD servers also get cached a long time at 
>> the clients. If each of your clients needs a root server and a few 
>> TLD lookups a day, it's not a huge gain in terms of performance.
>>
>> It is however a significant step up in terms of complexity. E.g., 
>> your satellite-based DNS would have to point you at the TLD server 
>> that is topologically closest to your Starlink gateway, or risk a 
>> potentially much longer RTT for the lookup. So you'd need to maintain 
>> a list of TLD instances on your satellite-based DNS and return the 
>> one that corresponds to what your gateway-based DNS would get. Sure 
>> possible but more complex than a bog standard DNS server in a fixed 
>> network.
>
> really? I don't think the root and TLD servers do any geolocation, I 
> think they have fixed answers and rely on anycast addresses to find 
> the closest one. Adding those anycast addresses to the satellites 
> would be transpoarent to all users (assuming the satellites are 
> operating at the IP layer, the old bent-pipe approach did not, but 
> once you have routing in space via the laser links...)

So what you're suggesting would be a generic anycast-based set of DNS 
records to be kept on all satellites?

Hm. My terrestrial RTT to the closest 8.8.8.8 and 8.8.4.4 anycast DNS 
servers is about 28 ms, indicating that they're over in Australia. No 
big surprise here, but that RTT isn't all too different from what I'd 
expect from a Starlink connection. That compares to < 1 ms to my local 
resolver.

Would an anycast-based generic DNS give us better RTT than a 
gateway-based DNS with full ability to cache local information?

Even with the laser links, it's worth repeating that most of Starlink's 
operation is still bent pipe, and likely to continue to be so in future. 
There is little evidence that the lasers are currently being used for 
anything but remote location access.

That said, bent pipe isn't the same as bent pipe. Analog telecom GEO 
sats used to do physical layer bent pipe with the satellite incapable of 
IP. If you have a satellite capable of IP, you can still call it a bent 
pipe as long as it downlinks traffic that has come in on the uplink. You 
could even run an IP-based tunnel between dishy and gateway that makes 
it appear like a single link for the next network layer up the stack. 
And do the same for lasers. There'd be a number of advantages in this.

>
>>>> Practically speaking, we know from various sources that each 
>>>> Starlink satellite provides - ballpark - a couple of dozen Gb/s in 
>>>> capacity, and that active users on a "busy" satellite see a couple 
>>>> of dozen Mb/s of that. "Busy" means most active users, and so we 
>>>> can conclude that the number of users per satellite who use any 
>>>> site is at most around 1000. The subset of users navigating to new 
>>>> sites among them is probably in the low 100's at best. If we're 
>>>> excluding new sites that aren't dynamic, we're probably down to a 
>>>> couple of dozen new static sites being queried per satellite pass. 
>>>> How many of these queries will be duplicates? Not a lot. If we're 
>>>> including sites that are dynamic, we're still not getting a huge 
>>>> probability of cache entry re-use.
>>>
>>> I think that each user is typically going to use a lot less than the 
>>> 'couple dozen MB' that is the limits that we see, so the number of 
>>> users in a cell would be much higher.
>> Yes, but these users aren't "active" in the sense that they will be 
>> firing off DNS queries during the pass...
>
> even users who are using the connection aren't going to be using 
> dozens of MB of bandwidth.
Yes - but that should reflect as a lower level of DNS usage in most 
cases, shouldn't it?
>
>>>>> DNS data is not that large, getting enough storage into the 
>>>>> satellites to serve 90% of the non-dynamic data should not be a 
>>>>> big deal. The dynamic data expires fast enough (and can be 
>>>>> detected as being dynamic and expired faster in the satellite) 
>>>>> that I'm not worried about serving data from one side of the world 
>>>>> to the other.
>>>> Yes, but the only advantage we'd get here is faster resolution for 
>>>> a very small subset of DNS queries.
>>>
>>> and while that's not as big a win as faster resolution of a larger 
>>> set, it's still a win.
>> Yes, but are we chasing diminishing margins here when there are much 
>> bigger fish to fry?
>
> possibly. it's worth discussing and DNS is an easy thing to start with 
> compared to most others.
>
> David Lang
>
-- 
****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel@auckland.ac.nz
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************

Re: [Starlink] fiber IXPs in space

[David Lang]

On Mon, 17 Apr 2023, Ulrich Speidel wrote:

> On 17/04/2023 2:34 pm, David Lang wrote:
>> On Mon, 17 Apr 2023, Ulrich Speidel wrote:
>> 
>>> On 17/04/2023 1:04 pm, David Lang wrote:
>>>> I think it is going to be fairly common, but the beauty of the idea is 
>>>> that you don't have to risk much to try it. Long lived DNS answers (and 
>>>> especially root servers and TLD servers) can trivially be mirrored to the 
>>>> satellites, and you can experiment with caching to see what sort of hit 
>>>> rate you get. Even if you don't cache a lot of the CDN type traffic, it 
>>>> should still be a win to have the longer term stuff there.
>>> 
>>> Yes - but root servers and TLD servers also get cached a long time at the 
>>> clients. If each of your clients needs a root server and a few TLD lookups 
>>> a day, it's not a huge gain in terms of performance.
>>> 
>>> It is however a significant step up in terms of complexity. E.g., your 
>>> satellite-based DNS would have to point you at the TLD server that is 
>>> topologically closest to your Starlink gateway, or risk a potentially much 
>>> longer RTT for the lookup. So you'd need to maintain a list of TLD 
>>> instances on your satellite-based DNS and return the one that corresponds 
>>> to what your gateway-based DNS would get. Sure possible but more complex 
>>> than a bog standard DNS server in a fixed network.
>> 
>> really? I don't think the root and TLD servers do any geolocation, I think 
>> they have fixed answers and rely on anycast addresses to find the closest 
>> one. Adding those anycast addresses to the satellites would be transpoarent 
>> to all users (assuming the satellites are operating at the IP layer, the 
>> old bent-pipe approach did not, but once you have routing in space via the 
>> laser links...)
>
> So what you're suggesting would be a generic anycast-based set of DNS records 
> to be kept on all satellites?
>
> Hm. My terrestrial RTT to the closest 8.8.8.8 and 8.8.4.4 anycast DNS servers 
> is about 28 ms, indicating that they're over in Australia. No big surprise 
> here, but that RTT isn't all too different from what I'd expect from a 
> Starlink connection. That compares to < 1 ms to my local resolver.
>
> Would an anycast-based generic DNS give us better RTT than a gateway-based 
> DNS with full ability to cache local information?

are you going to replicate the root server data to your gateway? what's a fairly 
trivial amount of data for a server (including one in space) can be a 
significant amount of data to store on an AP/gateway. If you have your gateway 
caching it, you probably won't hit the space based servers in any case.

in part it would depend on how much the gateway gets turned off. (some people do 
it for security, people who are mobile power things down to move)

> Even with the laser links, it's worth repeating that most of Starlink's 
> operation is still bent pipe, and likely to continue to be so in future. 
> There is little evidence that the lasers are currently being used for 
> anything but remote location access.
>
> That said, bent pipe isn't the same as bent pipe. Analog telecom GEO sats 
> used to do physical layer bent pipe with the satellite incapable of IP. If 
> you have a satellite capable of IP, you can still call it a bent pipe as long 
> as it downlinks traffic that has come in on the uplink. You could even run an 
> IP-based tunnel between dishy and gateway that makes it appear like a single 
> link for the next network layer up the stack. And do the same for lasers. 
> There'd be a number of advantages in this.

and bent pipe for normal operations doesn't mean that you can't watch for an 
anycast address to serve locally.

>>>>> Practically speaking, we know from various sources that each Starlink 
>>>>> satellite provides - ballpark - a couple of dozen Gb/s in capacity, and 
>>>>> that active users on a "busy" satellite see a couple of dozen Mb/s of 
>>>>> that. "Busy" means most active users, and so we can conclude that the 
>>>>> number of users per satellite who use any site is at most around 1000. 
>>>>> The subset of users navigating to new sites among them is probably in 
>>>>> the low 100's at best. If we're excluding new sites that aren't dynamic, 
>>>>> we're probably down to a couple of dozen new static sites being queried 
>>>>> per satellite pass. How many of these queries will be duplicates? Not a 
>>>>> lot. If we're including sites that are dynamic, we're still not getting 
>>>>> a huge probability of cache entry re-use.
>>>> 
>>>> I think that each user is typically going to use a lot less than the 
>>>> 'couple dozen MB' that is the limits that we see, so the number of users 
>>>> in a cell would be much higher.
>>> Yes, but these users aren't "active" in the sense that they will be firing 
>>> off DNS queries during the pass...
>> 
>> even users who are using the connection aren't going to be using dozens of 
>> MB of bandwidth.
> Yes - but that should reflect as a lower level of DNS usage in most cases, 
> shouldn't it?

not necessarily, if they are browsing pages that are made of small pieces, they 
can generate lots of connections and lots of DNS lookups, but not consume a lot 
of bandwidth. You don't get to the dozens of MB range without some bulk download 
traffic in there.

David Lang

Re: [Starlink] fiber IXPs in space

[Sebastian Moeller]

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

Interesting discussion.

One other thing to keep in mind, some jurisdictions like the EU (in a broader sense, members typically crate their own EU compatible laws) legally mandated DNS blocking of specific addresses is a thing, and our LEO DNS operator likely would ned to honor these when over such regions making the whole thing even more complicated and likely less attractive...

On 17 April 2023 07:01:41 CEST, David Lang via Starlink <starlink@lists.bufferbloat.net> wrote:
>On Mon, 17 Apr 2023, Ulrich Speidel wrote:
>
>> On 17/04/2023 2:34 pm, David Lang wrote:
>>> On Mon, 17 Apr 2023, Ulrich Speidel wrote:
>>> 
>>>> On 17/04/2023 1:04 pm, David Lang wrote:
>>>>> I think it is going to be fairly common, but the beauty of the idea is that you don't have to risk much to try it. Long lived DNS answers (and especially root servers and TLD servers) can trivially be mirrored to the satellites, and you can experiment with caching to see what sort of hit rate you get. Even if you don't cache a lot of the CDN type traffic, it should still be a win to have the longer term stuff there.
>>>> 
>>>> Yes - but root servers and TLD servers also get cached a long time at the clients. If each of your clients needs a root server and a few TLD lookups a day, it's not a huge gain in terms of performance.
>>>> 
>>>> It is however a significant step up in terms of complexity. E.g., your satellite-based DNS would have to point you at the TLD server that is topologically closest to your Starlink gateway, or risk a potentially much longer RTT for the lookup. So you'd need to maintain a list of TLD instances on your satellite-based DNS and return the one that corresponds to what your gateway-based DNS would get. Sure possible but more complex than a bog standard DNS server in a fixed network.
>>> 
>>> really? I don't think the root and TLD servers do any geolocation, I think they have fixed answers and rely on anycast addresses to find the closest one. Adding those anycast addresses to the satellites would be transpoarent to all users (assuming the satellites are operating at the IP layer, the old bent-pipe approach did not, but once you have routing in space via the laser links...)
>> 
>> So what you're suggesting would be a generic anycast-based set of DNS records to be kept on all satellites?
>> 
>> Hm. My terrestrial RTT to the closest 8.8.8.8 and 8.8.4.4 anycast DNS servers is about 28 ms, indicating that they're over in Australia. No big surprise here, but that RTT isn't all too different from what I'd expect from a Starlink connection. That compares to < 1 ms to my local resolver.
>> 
>> Would an anycast-based generic DNS give us better RTT than a gateway-based DNS with full ability to cache local information?
>
>are you going to replicate the root server data to your gateway? what's a fairly trivial amount of data for a server (including one in space) can be a significant amount of data to store on an AP/gateway. If you have your gateway caching it, you probably won't hit the space based servers in any case.
>
>in part it would depend on how much the gateway gets turned off. (some people do it for security, people who are mobile power things down to move)
>
>> Even with the laser links, it's worth repeating that most of Starlink's operation is still bent pipe, and likely to continue to be so in future. There is little evidence that the lasers are currently being used for anything but remote location access.
>> 
>> That said, bent pipe isn't the same as bent pipe. Analog telecom GEO sats used to do physical layer bent pipe with the satellite incapable of IP. If you have a satellite capable of IP, you can still call it a bent pipe as long as it downlinks traffic that has come in on the uplink. You could even run an IP-based tunnel between dishy and gateway that makes it appear like a single link for the next network layer up the stack. And do the same for lasers. There'd be a number of advantages in this.
>
>and bent pipe for normal operations doesn't mean that you can't watch for an anycast address to serve locally.
>
>>>>>> Practically speaking, we know from various sources that each Starlink satellite provides - ballpark - a couple of dozen Gb/s in capacity, and that active users on a "busy" satellite see a couple of dozen Mb/s of that. "Busy" means most active users, and so we can conclude that the number of users per satellite who use any site is at most around 1000. The subset of users navigating to new sites among them is probably in the low 100's at best. If we're excluding new sites that aren't dynamic, we're probably down to a couple of dozen new static sites being queried per satellite pass. How many of these queries will be duplicates? Not a lot. If we're including sites that are dynamic, we're still not getting a huge probability of cache entry re-use.
>>>>> 
>>>>> I think that each user is typically going to use a lot less than the 'couple dozen MB' that is the limits that we see, so the number of users in a cell would be much higher.
>>>> Yes, but these users aren't "active" in the sense that they will be firing off DNS queries during the pass...
>>> 
>>> even users who are using the connection aren't going to be using dozens of MB of bandwidth.
>> Yes - but that should reflect as a lower level of DNS usage in most cases, shouldn't it?
>
>not necessarily, if they are browsing pages that are made of small pieces, they can generate lots of connections and lots of DNS lookups, but not consume a lot of bandwidth. You don't get to the dozens of MB range without some bulk download traffic in there.
>
>David Lang
>_______________________________________________
>Starlink mailing list
>Starlink@lists.bufferbloat.net
>https://lists.bufferbloat.net/listinfo/starlink

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: Type: text/html, Size: 7469 bytes --]

Re: [Starlink] fiber IXPs in space

[David Lang]

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

On Sun, 16 Apr 2023, David Fernández via Starlink wrote:

> The idea would be that the satellite inspects IP packets and when it
> detects a DNS query, instead of forwarding the packet to ground
> station, it just answers back to the sender of the query.

This would be a bad way to implement it. You don't want to override queries to 
other DNS servers, but it would be very easy to create an anycast address that 
is served by the satellites.

David Lang

Re: [Starlink] fiber IXPs in space

[Rodney W. Grimes]

> On Sun, 16 Apr 2023, David Fern?ndez via Starlink wrote:
> 
> > The idea would be that the satellite inspects IP packets and when it
> > detects a DNS query, instead of forwarding the packet to ground
> > station, it just answers back to the sender of the query.
> 
> This would be a bad way to implement it. You don't want to override queries to 
> other DNS servers, but it would be very easy to create an anycast address that 
> is served by the satellites.

Yes, and the later is what I proposed, the idea of intercepting
someone ELSE'S anycast address and processing it would be
wrong in many ways, in effect a Man In the Middle attack
as stated else where.

> David Lang
--
Rod Grimes                                                 rgrimes@freebsd.org

Re: [Starlink] fiber IXPs in space

[David Fernández]

Well, I have some concerns about how you implement an anycast address
in a transparent satellite.

If the pre-requisite for this is that the satellite is a router, I
don't see this happening anytime soon. I am not aware of any system,
not deployed, even designed with satellites being routers, but IRIS2
could be the first, maybe:
https://defence-industry-space.ec.europa.eu/eu-space-policy/eu-space-programme/iriss_en

Bufferbloat will be checked and prevented as much as possible in IRIS2.

Regards,

David

2023-04-17 16:38 GMT+02:00, Rodney W. Grimes <starlink@gndrsh.dnsmgr.net>:
>> On Sun, 16 Apr 2023, David Fern?ndez via Starlink wrote:
>>
>> > The idea would be that the satellite inspects IP packets and when it
>> > detects a DNS query, instead of forwarding the packet to ground
>> > station, it just answers back to the sender of the query.
>>
>> This would be a bad way to implement it. You don't want to override
>> queries to
>> other DNS servers, but it would be very easy to create an anycast address
>> that
>> is served by the satellites.
>
> Yes, and the later is what I proposed, the idea of intercepting
> someone ELSE'S anycast address and processing it would be
> wrong in many ways, in effect a Man In the Middle attack
> as stated else where.
>
>> David Lang
> --
> Rod Grimes
> rgrimes@freebsd.org
>

Re: [Starlink] fiber IXPs in space

[David Lang]

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

if Starlink can route via in-space-lasers and in a dishy-to-dishy way (both have 
been talked about, at least in future tenses) then they could also route to an 
on-satellite IP.

historically 'bent pipe' satellite support meant that the satellite just 
repeated the RF signal back down with no modifications. Starlink was designed to 
do routing of traffic, some to a ground station (possibly more than one), some 
to other satellites (including ones at different altitudes), and some to other 
dishys. It's initial deployment included no routing, just relaying between a 
dishy and a ground station, but we know that it's extended beyond that, at least 
when there are not ground stations in range

David Lang

On Mon, 17 Apr 2023, David Fernández via Starlink wrote:

> Well, I have some concerns about how you implement an anycast address
> in a transparent satellite.
>
> If the pre-requisite for this is that the satellite is a router, I
> don't see this happening anytime soon. I am not aware of any system,
> not deployed, even designed with satellites being routers, but IRIS2
> could be the first, maybe:
> https://defence-industry-space.ec.europa.eu/eu-space-policy/eu-space-programme/iriss_en
>
> Bufferbloat will be checked and prevented as much as possible in IRIS2.
>
> Regards,
>
> David
>
> 2023-04-17 16:38 GMT+02:00, Rodney W. Grimes <starlink@gndrsh.dnsmgr.net>:
>>> On Sun, 16 Apr 2023, David Fern?ndez via Starlink wrote:
>>>
>>> > The idea would be that the satellite inspects IP packets and when it
>>> > detects a DNS query, instead of forwarding the packet to ground
>>> > station, it just answers back to the sender of the query.
>>>
>>> This would be a bad way to implement it. You don't want to override
>>> queries to
>>> other DNS servers, but it would be very easy to create an anycast address
>>> that
>>> is served by the satellites.
>>
>> Yes, and the later is what I proposed, the idea of intercepting
>> someone ELSE'S anycast address and processing it would be
>> wrong in many ways, in effect a Man In the Middle attack
>> as stated else where.
>>
>>> David Lang
>> --
>> Rod Grimes
>> rgrimes@freebsd.org
>>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] fiber IXPs in space

[Ulrich Speidel]

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

For all I can tell, dishy only uses one satellite at a time and so 
routing via dishys to other satellites - while certainly an attractive 
concept - doesn't seem to be happening.

Most modern comms systems - look at your phone - run pretty complicated 
stacks these days, and I'd be very surprised if Starlink didn't. That 
makes it likely that there is an extra network and transport layer 
between dishy and gateway (a term, which I'm incidentally not using for 
the WiFi router that comes with dishy but for the gateways that connect 
the Starlink space network to the terrestrial Internet). Any routing 
between dishy, satellite and gateway (and any lasers along the way) will 
therefore be happening at that extra network layer - the transport layer 
above it has the job to make the path between dishy and gateway look 
like a single data link layer hop. This is why you don't see a satellite 
IP in your traceroute. Quite how that extra network and transport layer 
is implemented is something that probably only Starlink knows. The power 
of layered communication ;-)

P.S.: I'll apologise in advance for upcoming silence over the next few 
days - we're taking Dishy for an outing to get it away from the Clevedon 
gateway, so we can finally get Dave some more data ;-)

On 18/04/2023 7:09 am, David Lang via Starlink wrote:
> if Starlink can route via in-space-lasers and in a dishy-to-dishy way 
> (both have
> been talked about, at least in future tenses) then they could also 
> route to an
> on-satellite IP.
>
> historically 'bent pipe' satellite support meant that the satellite just
> repeated the RF signal back down with no modifications. Starlink was 
> designed to
> do routing of traffic, some to a ground station (possibly more than 
> one), some
> to other satellites (including ones at different altitudes), and some 
> to other
> dishys. It's initial deployment included no routing, just relaying 
> between a
> dishy and a ground station, but we know that it's extended beyond 
> that, at least
> when there are not ground stations in range
>
> David Lang
>
> On Mon, 17 Apr 2023, David Fernández via Starlink wrote:
>
> > Well, I have some concerns about how you implement an anycast address
> > in a transparent satellite.
> >
> > If the pre-requisite for this is that the satellite is a router, I
> > don't see this happening anytime soon. I am not aware of any system,
> > not deployed, even designed with satellites being routers, but IRIS2
> > could be the first, maybe:
> > 
> https://defence-industry-space.ec.europa.eu/eu-space-policy/eu-space-programme/iriss_en 
> <https://defence-industry-space.ec.europa.eu/eu-space-policy/eu-space-programme/iriss_en>
> >
> > Bufferbloat will be checked and prevented as much as possible in IRIS2.
> >
> > Regards,
> >
> > David
> >
> > 2023-04-17 16:38 GMT+02:00, Rodney W. Grimes 
> <starlink@gndrsh.dnsmgr.net>:
> >>> On Sun, 16 Apr 2023, David Fern?ndez via Starlink wrote:
> >>>
> >>> > The idea would be that the satellite inspects IP packets and when it
> >>> > detects a DNS query, instead of forwarding the packet to ground
> >>> > station, it just answers back to the sender of the query.
> >>>
> >>> This would be a bad way to implement it. You don't want to override
> >>> queries to
> >>> other DNS servers, but it would be very easy to create an anycast 
> address
> >>> that
> >>> is served by the satellites.
> >>
> >> Yes, and the later is what I proposed, the idea of intercepting
> >> someone ELSE'S anycast address and processing it would be
> >> wrong in many ways, in effect a Man In the Middle attack
> >> as stated else where.
> >>
> >>> David Lang
> >> --
> >> Rod Grimes
> >> rgrimes@freebsd.org
> >>
> > _______________________________________________
> > Starlink mailing list
> > Starlink@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/starlink 
> <https://lists.bufferbloat.net/listinfo/starlink> 
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>
-- 
****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel@auckland.ac.nz  
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************



[-- Attachment #2: Type: text/html, Size: 6552 bytes --]

Re: [Starlink] fiber IXPs in space

[David Lang]

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

On Tue, 18 Apr 2023, Ulrich Speidel via Starlink wrote:

> For all I can tell, dishy only uses one satellite at a time and so routing 
> via dishys to other satellites - while certainly an attractive concept - 
> doesn't seem to be happening.

the one doesn't prevent the other, if two dishys are talking to the same 
sateelite, or if the satellites relay the data via lasers, the dishies could 
talk without a ground station involved while only talking to one satellite.

> Most modern comms systems - look at your phone - run pretty complicated 
> stacks these days, and I'd be very surprised if Starlink didn't. That makes 
> it likely that there is an extra network and transport layer between dishy 
> and gateway (a term, which I'm incidentally not using for the WiFi router 
> that comes with dishy but for the gateways that connect the Starlink space 
> network to the terrestrial Internet). Any routing between dishy, satellite 
> and gateway (and any lasers along the way) will therefore be happening at 
> that extra network layer - the transport layer above it has the job to make 
> the path between dishy and gateway look like a single data link layer hop. 
> This is why you don't see a satellite IP in your traceroute. Quite how that 
> extra network and transport layer is implemented is something that probably 
> only Starlink knows. The power of layered communication ;-)

Elon Musk has said that dishy-to-dishy communications is a capability that they 
are working towards.

They have also talked about how going NY to London would be faster via starlink 
space relay than via undersea fiber (the gain in speed from light in a vaccum vs 
in a fiber more than makes up for the extra distances involved), but since I 
haven't heard of them doing this yet, I don't think it's possible yet.

I would not be surprised to learn that starlink establishes a preferred gateway 
and creates a virtual circuit to it that can be routed through various 
satellites (it seems like the easiest thing to do, and works well initially)

But I believe that they are working to improve this to meet their stated goals, 
and when they have the ability to send over multiple virtual circuits, or do 
true dynamic routing, it would be straightforward for the dishy to notice that 
the destination is a supported anycast address and handle it differently.

As a side note, I think that anything you try to serve via satellites will need 
to be anycast friendly, just to handle the fact that it will need to be served 
from multiple satellites so that you can get it from one close to you as opposed 
to needing to be relayed to the other side of the earth at times.

>
> P.S.: I'll apologise in advance for upcoming silence over the next few days - 
> we're taking Dishy for an outing to get it away from the Clevedon gateway, so 
> we can finally get Dave some more data ;-)

I just had SpaceX replace my 1st gen dishy with a 2nd gen one, after I do some 
validation, I will move one of them to the mobile plan and be able to test it at 
different places (I'm equipping a van so that it can be a mobile office and will 
test it by driving a ways and trying to work from the van in some odd locations) 
Probably won't get finished until after July.

David Lang

> On 18/04/2023 7:09 am, David Lang via Starlink wrote:
>> if Starlink can route via in-space-lasers and in a dishy-to-dishy way (both 
>> have
>> been talked about, at least in future tenses) then they could also route to 
>> an
>> on-satellite IP.
>> 
>> historically 'bent pipe' satellite support meant that the satellite just
>> repeated the RF signal back down with no modifications. Starlink was 
>> designed to
>> do routing of traffic, some to a ground station (possibly more than one), 
>> some
>> to other satellites (including ones at different altitudes), and some to 
>> other
>> dishys. It's initial deployment included no routing, just relaying between 
>> a
>> dishy and a ground station, but we know that it's extended beyond that, at 
>> least
>> when there are not ground stations in range
>> 
>> David Lang
>> 
>> On Mon, 17 Apr 2023, David Fernández via Starlink wrote:
>> 
>> > Well, I have some concerns about how you implement an anycast address
>> > in a transparent satellite.
>> >
>> > If the pre-requisite for this is that the satellite is a router, I
>> > don't see this happening anytime soon. I am not aware of any system,
>> > not deployed, even designed with satellites being routers, but IRIS2
>> > could be the first, maybe:
>> > 
>> https://defence-industry-space.ec.europa.eu/eu-space-policy/eu-space-programme/iriss_en 
>> <https://defence-industry-space.ec.europa.eu/eu-space-policy/eu-space-programme/iriss_en>
>> >
>> > Bufferbloat will be checked and prevented as much as possible in IRIS2.
>> >
>> > Regards,
>> >
>> > David
>> >
>> > 2023-04-17 16:38 GMT+02:00, Rodney W. Grimes 
>> <starlink@gndrsh.dnsmgr.net>:
>> >>> On Sun, 16 Apr 2023, David Fern?ndez via Starlink wrote:
>> >>>
>> >>> > The idea would be that the satellite inspects IP packets and when it
>> >>> > detects a DNS query, instead of forwarding the packet to ground
>> >>> > station, it just answers back to the sender of the query.
>> >>>
>> >>> This would be a bad way to implement it. You don't want to override
>> >>> queries to
>> >>> other DNS servers, but it would be very easy to create an anycast 
>> address
>> >>> that
>> >>> is served by the satellites.
>> >>
>> >> Yes, and the later is what I proposed, the idea of intercepting
>> >> someone ELSE'S anycast address and processing it would be
>> >> wrong in many ways, in effect a Man In the Middle attack
>> >> as stated else where.
>> >>
>> >>> David Lang
>> >> --
>> >> Rod Grimes
>> >> rgrimes@freebsd.org
>> >>
>> > _______________________________________________
>> > Starlink mailing list
>> > Starlink@lists.bufferbloat.net
>> > https://lists.bufferbloat.net/listinfo/starlink 
>> <https://lists.bufferbloat.net/listinfo/starlink> 
>> 
>> _______________________________________________
>> 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] fiber IXPs in space

[David Lang]

On Mon, 17 Apr 2023, Rodney W. Grimes wrote:

>> On Sun, 16 Apr 2023, David Fern?ndez via Starlink wrote:
>>
>>> The idea would be that the satellite inspects IP packets and when it
>>> detects a DNS query, instead of forwarding the packet to ground
>>> station, it just answers back to the sender of the query.
>>
>> This would be a bad way to implement it. You don't want to override queries to
>> other DNS servers, but it would be very easy to create an anycast address that
>> is served by the satellites.
>
> Yes, and the later is what I proposed, the idea of intercepting
> someone ELSE'S anycast address and processing it would be
> wrong in many ways, in effect a Man In the Middle attack
> as stated else where.

I was assuming that it would be done in coordination with the existing user, not 
as a stealth optimization. I should have made that clear.

David Lang

Re: [Starlink] fiber IXPs in space

[David Fernández]

PEPs have been mentioned as an example of so called stealth optimization.

Another example, I think it is IGMP snooping:
https://en.wikipedia.org/wiki/IGMP_snooping

So, well, maybe this so called DNS stealth optimization is not so bad,
if it really is easy to implement and it brings benefits (RTT by
half), but pros and cons should be carefully evaluated.

Regards,

David

2023-04-17 21:00 GMT+02:00, David Lang <david@lang.hm>:
> On Mon, 17 Apr 2023, Rodney W. Grimes wrote:
>
>>> On Sun, 16 Apr 2023, David Fern?ndez via Starlink wrote:
>>>
>>>> The idea would be that the satellite inspects IP packets and when it
>>>> detects a DNS query, instead of forwarding the packet to ground
>>>> station, it just answers back to the sender of the query.
>>>
>>> This would be a bad way to implement it. You don't want to override
>>> queries to
>>> other DNS servers, but it would be very easy to create an anycast address
>>> that
>>> is served by the satellites.
>>
>> Yes, and the later is what I proposed, the idea of intercepting
>> someone ELSE'S anycast address and processing it would be
>> wrong in many ways, in effect a Man In the Middle attack
>> as stated else where.
>
> I was assuming that it would be done in coordination with the existing user,
> not
> as a stealth optimization. I should have made that clear.
>
> David Lang
>

Re: [Starlink] fiber IXPs in space

[Sebastian Moeller]

Hi David,


> On Apr 18, 2023, at 09:46, David Fernández via Starlink <starlink@lists.bufferbloat.net> wrote:
> 
> PEPs have been mentioned as an example of so called stealth optimization.
> 
> Another example, I think it is IGMP snooping:
> https://en.wikipedia.org/wiki/IGMP_snooping

	I think this is different from "PEPs" (I really dislike the marketing naming... IGMP snooping arguably deals to deal with the fact that IGMP has a different idea of unicast/multicast scoping than is optimal for switched L2 network domains... it is also as far as I can tell opt-in in that one needs to activate it in once's L2.5 devices first. I am not sure whether norrmal geo-stationary internet users can opt-out of the TCP shenanigans played by PEPs?

> So, well, maybe this so called DNS stealth optimization is not so bad,
> if it really is easy to implement and it brings benefits (RTT by
> half), but pros and cons should be carefully evaluated.

	I heartily disagree, stealth DNS "optimization" is not something an ISP should be caught doing behind their users backs. I remember when my former ISPs insisted upon capturing DNS queries to non-existent domains to an advertisement page of their own, I was neither impressed nor happy (even though they did offer an opt-out).
Now, if a hypothetical starlink offer would do that DNS snooping only for DNS queries directed against starlink's own DNS server IP addresses that would be palatable from a who handles the query perspective (starlink in both cases), but from a layering violation perspective this still seems rather vile. If the want to offer DNS forwarders in space, they should simply do so overtly and not high-jack packets directed to a different server.

At least that is my subjective take on this issue.
Regards
	Sebastian

> 
> Regards,
> 
> David
> 
> 2023-04-17 21:00 GMT+02:00, David Lang <david@lang.hm>:
>> On Mon, 17 Apr 2023, Rodney W. Grimes wrote:
>> 
>>>> On Sun, 16 Apr 2023, David Fern?ndez via Starlink wrote:
>>>> 
>>>>> The idea would be that the satellite inspects IP packets and when it
>>>>> detects a DNS query, instead of forwarding the packet to ground
>>>>> station, it just answers back to the sender of the query.
>>>> 
>>>> This would be a bad way to implement it. You don't want to override
>>>> queries to
>>>> other DNS servers, but it would be very easy to create an anycast address
>>>> that
>>>> is served by the satellites.
>>> 
>>> Yes, and the later is what I proposed, the idea of intercepting
>>> someone ELSE'S anycast address and processing it would be
>>> wrong in many ways, in effect a Man In the Middle attack
>>> as stated else where.
>> 
>> I was assuming that it would be done in coordination with the existing user,
>> not
>> as a stealth optimization. I should have made that clear.
>> 
>> David Lang
>> 
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] fiber IXPs in space

[David Fernández]

Hi Sebastian,

AFAIK, you can disable PEPs at satellite terminals web page for
management, just like any other setting such as UPnP or the Wi-Fi
network. Some satellite terminals do not have PEPs embedded, they are
an extra HW accessory you can even remove (like this:
https://www.xiplink.com)

Or you can use a VPN (IPSec, Wireguard, OpenVPN...), or QUIC, instead of TCP.

If the DNS address is anycast, it is an address of a SpaceX DNS server
on their gateways, and the user can configure this DNS or any other
(that would not be captured and answered back by the satellite), is
there really any practical difference between doing it overtly or just
answering back captured DNS packets detected to that anycast
addresses?

Regards,

David

2023-04-18 10:34 GMT+02:00, Sebastian Moeller <moeller0@gmx.de>:
> Hi David,
>
>
>> On Apr 18, 2023, at 09:46, David Fernández via Starlink
>> <starlink@lists.bufferbloat.net> wrote:
>>
>> PEPs have been mentioned as an example of so called stealth optimization.
>>
>> Another example, I think it is IGMP snooping:
>> https://en.wikipedia.org/wiki/IGMP_snooping
>
> 	I think this is different from "PEPs" (I really dislike the marketing
> naming... IGMP snooping arguably deals to deal with the fact that IGMP has a
> different idea of unicast/multicast scoping than is optimal for switched L2
> network domains... it is also as far as I can tell opt-in in that one needs
> to activate it in once's L2.5 devices first. I am not sure whether norrmal
> geo-stationary internet users can opt-out of the TCP shenanigans played by
> PEPs?
>
>> So, well, maybe this so called DNS stealth optimization is not so bad,
>> if it really is easy to implement and it brings benefits (RTT by
>> half), but pros and cons should be carefully evaluated.
>
> 	I heartily disagree, stealth DNS "optimization" is not something an ISP
> should be caught doing behind their users backs. I remember when my former
> ISPs insisted upon capturing DNS queries to non-existent domains to an
> advertisement page of their own, I was neither impressed nor happy (even
> though they did offer an opt-out).
> Now, if a hypothetical starlink offer would do that DNS snooping only for
> DNS queries directed against starlink's own DNS server IP addresses that
> would be palatable from a who handles the query perspective (starlink in
> both cases), but from a layering violation perspective this still seems
> rather vile. If the want to offer DNS forwarders in space, they should
> simply do so overtly and not high-jack packets directed to a different
> server.
>
> At least that is my subjective take on this issue.
> Regards
> 	Sebastian
>
>>
>> Regards,
>>
>> David
>>
>> 2023-04-17 21:00 GMT+02:00, David Lang <david@lang.hm>:
>>> On Mon, 17 Apr 2023, Rodney W. Grimes wrote:
>>>
>>>>> On Sun, 16 Apr 2023, David Fern?ndez via Starlink wrote:
>>>>>
>>>>>> The idea would be that the satellite inspects IP packets and when it
>>>>>> detects a DNS query, instead of forwarding the packet to ground
>>>>>> station, it just answers back to the sender of the query.
>>>>>
>>>>> This would be a bad way to implement it. You don't want to override
>>>>> queries to
>>>>> other DNS servers, but it would be very easy to create an anycast
>>>>> address
>>>>> that
>>>>> is served by the satellites.
>>>>
>>>> Yes, and the later is what I proposed, the idea of intercepting
>>>> someone ELSE'S anycast address and processing it would be
>>>> wrong in many ways, in effect a Man In the Middle attack
>>>> as stated else where.
>>>
>>> I was assuming that it would be done in coordination with the existing
>>> user,
>>> not
>>> as a stealth optimization. I should have made that clear.
>>>
>>> David Lang
>>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>
>

Re: [Starlink] fiber IXPs in space

[David Lang]

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

you are mixing technology here, what is normal for the older satellite systems 
and what is available for starlink have very little in common. The starlink user 
terminal gives you very little control.

I agree with others here that overriding the user's DNS settings is a very bad 
thing to do. But offering a DNS address (and even making it the default) is very 
reasonable to do.

David Lang

On Tue, 18 Apr 2023, David Fernández via Starlink wrote:

> Hi Sebastian,
>
> AFAIK, you can disable PEPs at satellite terminals web page for
> management, just like any other setting such as UPnP or the Wi-Fi
> network. Some satellite terminals do not have PEPs embedded, they are
> an extra HW accessory you can even remove (like this:
> https://www.xiplink.com)
>
> Or you can use a VPN (IPSec, Wireguard, OpenVPN...), or QUIC, instead of TCP.
>
> If the DNS address is anycast, it is an address of a SpaceX DNS server
> on their gateways, and the user can configure this DNS or any other
> (that would not be captured and answered back by the satellite), is
> there really any practical difference between doing it overtly or just
> answering back captured DNS packets detected to that anycast
> addresses?
>
> Regards,
>
> David
>
> 2023-04-18 10:34 GMT+02:00, Sebastian Moeller <moeller0@gmx.de>:
>> Hi David,
>>
>>
>>> On Apr 18, 2023, at 09:46, David Fernández via Starlink
>>> <starlink@lists.bufferbloat.net> wrote:
>>>
>>> PEPs have been mentioned as an example of so called stealth optimization.
>>>
>>> Another example, I think it is IGMP snooping:
>>> https://en.wikipedia.org/wiki/IGMP_snooping
>>
>> 	I think this is different from "PEPs" (I really dislike the marketing
>> naming... IGMP snooping arguably deals to deal with the fact that IGMP has a
>> different idea of unicast/multicast scoping than is optimal for switched L2
>> network domains... it is also as far as I can tell opt-in in that one needs
>> to activate it in once's L2.5 devices first. I am not sure whether norrmal
>> geo-stationary internet users can opt-out of the TCP shenanigans played by
>> PEPs?
>>
>>> So, well, maybe this so called DNS stealth optimization is not so bad,
>>> if it really is easy to implement and it brings benefits (RTT by
>>> half), but pros and cons should be carefully evaluated.
>>
>> 	I heartily disagree, stealth DNS "optimization" is not something an ISP
>> should be caught doing behind their users backs. I remember when my former
>> ISPs insisted upon capturing DNS queries to non-existent domains to an
>> advertisement page of their own, I was neither impressed nor happy (even
>> though they did offer an opt-out).
>> Now, if a hypothetical starlink offer would do that DNS snooping only for
>> DNS queries directed against starlink's own DNS server IP addresses that
>> would be palatable from a who handles the query perspective (starlink in
>> both cases), but from a layering violation perspective this still seems
>> rather vile. If the want to offer DNS forwarders in space, they should
>> simply do so overtly and not high-jack packets directed to a different
>> server.
>>
>> At least that is my subjective take on this issue.
>> Regards
>> 	Sebastian
>>
>>>
>>> Regards,
>>>
>>> David
>>>
>>> 2023-04-17 21:00 GMT+02:00, David Lang <david@lang.hm>:
>>>> On Mon, 17 Apr 2023, Rodney W. Grimes wrote:
>>>>
>>>>>> On Sun, 16 Apr 2023, David Fern?ndez via Starlink wrote:
>>>>>>
>>>>>>> The idea would be that the satellite inspects IP packets and when it
>>>>>>> detects a DNS query, instead of forwarding the packet to ground
>>>>>>> station, it just answers back to the sender of the query.
>>>>>>
>>>>>> This would be a bad way to implement it. You don't want to override
>>>>>> queries to
>>>>>> other DNS servers, but it would be very easy to create an anycast
>>>>>> address
>>>>>> that
>>>>>> is served by the satellites.
>>>>>
>>>>> Yes, and the later is what I proposed, the idea of intercepting
>>>>> someone ELSE'S anycast address and processing it would be
>>>>> wrong in many ways, in effect a Man In the Middle attack
>>>>> as stated else where.
>>>>
>>>> I was assuming that it would be done in coordination with the existing
>>>> user,
>>>> not
>>>> as a stealth optimization. I should have made that clear.
>>>>
>>>> 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

Re: [Starlink] fiber IXPs in space

[Chris J. Ruschmann]

What makes you think each Starlink satellite doesn't have a router on board? Just Curious...

I think they are more complex than most people or you think.

-----Original Message-----
From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf Of David Fernández via Starlink
Sent: Sunday, April 16, 2023 9:54 AM
To: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] fiber IXPs in space

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.



In case you put a DNS server in the satellite, so that it replies instead of a DNS server on ground, the RTT is reduced by half.

The idea would be that the satellite inspects IP packets and when it detects a DNS query, instead of forwarding the packet to ground station, it just answers back to the sender of the query.

Nowadays, satellites (starlink included) are still transparent and are signal repeaters, not routers processing IP packets, so doing this is not immediate at all, but it could bring some benefits.

CDNs or even datacenters (Cloud) in GEO or LEO is even more complex.

Regards,

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

Re: [Starlink] fiber IXPs in space

[David Fernández]

AFAIK, Starlink satellites are Linux machines, so they could be acting
as routers, but they are not routing user data.

I bet they have IP addresses for management purposes in a separate set
of links for satellite platform control.

The decision to make them transparent to user networking is
independent on whether or not the satellites are capable of doing
routing. Clearly, SpaceX does not see any advantage on making the
satellites routers, so they are just link layer data relays. The fact
that they will start having ISLs may not change that, most likely.

Regards,

David

2023-04-18 7:59 GMT+02:00, Chris J. Ruschmann <chris@scsalaska.net>:
> What makes you think each Starlink satellite doesn't have a router on board?
> Just Curious...
>
> I think they are more complex than most people or you think.
>
> -----Original Message-----
> From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf Of David
> Fernández via Starlink
> Sent: Sunday, April 16, 2023 9:54 AM
> To: starlink@lists.bufferbloat.net
> Subject: Re: [Starlink] fiber IXPs in space
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know the
> content is safe.
>
>
>
> In case you put a DNS server in the satellite, so that it replies instead of
> a DNS server on ground, the RTT is reduced by half.
>
> The idea would be that the satellite inspects IP packets and when it detects
> a DNS query, instead of forwarding the packet to ground station, it just
> answers back to the sender of the query.
>
> Nowadays, satellites (starlink included) are still transparent and are
> signal repeaters, not routers processing IP packets, so doing this is not
> immediate at all, but it could bring some benefits.
>
> CDNs or even datacenters (Cloud) in GEO or LEO is even more complex.
>
> Regards,
>
> David
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>

[Starlink] fiber IXPs in space

[Dave Taht]

"The Kepler Network will streamline on-orbit communications with a
network infrastructure designed to act as Internet exchange points
(IXP) for space-to-space data relay. The Internet-ready constellation
will deliver data to and from spacecraft in real time, enabling
high-speed data relay through SDA-standard optical terminals."

https://kepler.space/2023/04/13/kepler-raises-92-million-usd-series-c-to-complete-internet-ready-optical-constellation/

I keep wondering when or if Nasa will find a way to move their DNS
root server "up there" . DNS data is not all that much... it is the
original distributed database...


-- 
AMA March 31: https://www.broadband.io/c/broadband-grant-events/dave-taht
Dave Täht CEO, TekLibre, LLC

Re: [Starlink] fiber IXPs in space

[Rodney W. Grimes]

> "The Kepler Network will streamline on-orbit communications with a
> network infrastructure designed to act as Internet exchange points
> (IXP) for space-to-space data relay. The Internet-ready constellation
> will deliver data to and from spacecraft in real time, enabling
> high-speed data relay through SDA-standard optical terminals."
> 
> https://kepler.space/2023/04/13/kepler-raises-92-million-usd-series-c-to-complete-internet-ready-optical-constellation/
> 
> I keep wondering when or if Nasa will find a way to move their DNS
> root server "up there" . DNS data is not all that much... it is the
> original distributed database...

As others have pointed out a "root server" may not be very advantages,
but what I think would be far better is to put up a couple of anycast
recursive caching resolvers, aka 8.8.8.8/8.8.4.4 and almost anyone
can do that, including starlink itself.

--
Rod Grimes                                                 rgrimes@freebsd.org

Re: [Starlink] fiber IXPs in space

[David Lang]

On Fri, 14 Apr 2023, Rodney W. Grimes via Starlink wrote:

>> I keep wondering when or if Nasa will find a way to move their DNS
>> root server "up there" . DNS data is not all that much... it is the
>> original distributed database...
>
> As others have pointed out a "root server" may not be very advantages,
> but what I think would be far better is to put up a couple of anycast
> recursive caching resolvers, aka 8.8.8.8/8.8.4.4 and almost anyone
> can do that, including starlink itself.

I believe that the root servers are all (or almost all) anycast nowdays.

David Lang

Re: [Starlink] fiber IXPs in space

[Dave Taht]

On Fri, Apr 14, 2023 at 12:36 PM David Lang <david@lang.hm> wrote:
>
> On Fri, 14 Apr 2023, Rodney W. Grimes via Starlink wrote:
>
> >> I keep wondering when or if Nasa will find a way to move their DNS
> >> root server "up there" . DNS data is not all that much... it is the
> >> original distributed database...
> >
> > As others have pointed out a "root server" may not be very advantages,
> > but what I think would be far better is to put up a couple of anycast
> > recursive caching resolvers, aka 8.8.8.8/8.8.4.4 and almost anyone
> > can do that, including starlink itself.
>
> I believe that the root servers are all (or almost all) anycast nowdays.

Anycast is perfect for an orbital DNS.

>
> David Lang



-- 
AMA March 31: https://www.broadband.io/c/broadband-grant-events/dave-taht
Dave Täht CEO, TekLibre, LLC

Re: [Starlink] fiber IXPs in space

[Rodney W. Grimes]

> On Fri, Apr 14, 2023 at 12:36?PM David Lang <david@lang.hm> wrote:
> >
> > On Fri, 14 Apr 2023, Rodney W. Grimes via Starlink wrote:
> >
> > >> I keep wondering when or if Nasa will find a way to move their DNS
> > >> root server "up there" . DNS data is not all that much... it is the
> > >> original distributed database...
> > >
> > > As others have pointed out a "root server" may not be very advantages,
> > > but what I think would be far better is to put up a couple of anycast
> > > recursive caching resolvers, aka 8.8.8.8/8.8.4.4 and almost anyone
> > > can do that, including starlink itself.
> >
> > I believe that the root servers are all (or almost all) anycast nowdays.
> 
> Anycast is perfect for an orbital DNS.

BUTT, root servers are NOT recursive or caching, they serve a very
small limitited set of data that changes at low frequency (I am
not sure of the current rate of updates, but it use to be only
once daily.)

Anyone can bring up there own replicate of a root server locally,
I do, and have for 2 decades, its a rather trivial thing to setup
and maintain.  But unlike a root, I also turn on recursision and
caching.

Again IMHO, a caching recursive any cast server ala 8.8.8.8 would
be far more useful than just a stock "root server."

> -- 
> AMA March 31: https://www.broadband.io/c/broadband-grant-events/dave-taht
> Dave T?ht CEO, TekLibre, LLC
--
Rod Grimes                                                 rgrimes@freebsd.org

Re: [Starlink] fiber IXPs in space

[Ulrich Speidel]

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

Given that clients cache DNS responses (including iterative responses 
from root servers), having DNS in space would be a nice-to-have, but 
it's not the most pressing issue IMHO.

A far bigger problem is that a direct-to-site model like Starlink's 
essentially rules out placing CDN servers in close proximity to web 
clients. For those unfamiliar with them: CDNs (content delivery 
networks, which now carry a huge percentage of Internet content traffic) 
work by redirecting HTTP(S) requests for content to a CDN server that's 
in closer topological (and, by inference, physical) proximity to your 
web browser. That keeps repeated requests for the same content off 
expensive and scarce long-distance bandwidth while allowing for fast TCP 
cwnd growth due to the low RTT in the branch- and (thus collectively) 
bandwidth-rich local ISP networks. But that doesn't work for Starlink: 
There's no way to prevent everyone watching the same cat video via 
Starlink in your area from having to take up scarce space segment 
bandwidth each time the video is viewed. And we're talking serious data 
volumes here, unlike for DNS.

You could, in principle, put CDN servers onto the satellites, but that 
would require the many earthly CDN providers to (a) persuade Elon that 
this is a good idea, (b) buy the service off SpaceX as it's unlikely 
they'll be given rack space on the Starlink fleet, and (c) you'd need a 
lot of storage capacity on each satellite in space, with a much reduced 
probability of a cache hit, since the fact that the satellites move 
across pretty much the whole globe over time, your next cat video 
download for your mates in town might need to come from a different 
satellite, and the satellite you currently talk to needs to cache not 
just stuff you and your neighbours like, but also stuff everyone else 
around the globe likes. So make that Chilean soap operas over Ukraine, 
Danish comedy for Australia, Aussie Rules Footy for the US Midwest, and 
so on... Or maybe quietly can the concept altogether.

On 16/04/2023 11:56 am, Rodney W. Grimes via Starlink wrote:
> > On Fri, Apr 14, 2023 at 12:36?PM David Lang <david@lang.hm> wrote:
> > >
> > > On Fri, 14 Apr 2023, Rodney W. Grimes via Starlink wrote:
> > >
> > > >> I keep wondering when or if Nasa will find a way to move their DNS
> > > >> root server "up there" . DNS data is not all that much... it is the
> > > >> original distributed database...
> > > >
> > > > As others have pointed out a "root server" may not be very 
> advantages,
> > > > but what I think would be far better is to put up a couple of 
> anycast
> > > > recursive caching resolvers, aka 8.8.8.8/8.8.4.4 
> <http://8.8.8.8/8.8.4.4> 
> and almost anyone
> > > > can do that, including starlink itself.
> > >
> > > I believe that the root servers are all (or almost all) anycast 
> nowdays.
> >
> > Anycast is perfect for an orbital DNS.
>
> BUTT, root servers are NOT recursive or caching, they serve a very
> small limitited set of data that changes at low frequency (I am
> not sure of the current rate of updates, but it use to be only
> once daily.)
>
> Anyone can bring up there own replicate of a root server locally,
> I do, and have for 2 decades, its a rather trivial thing to setup
> and maintain. But unlike a root, I also turn on recursision and
> caching.
>
> Again IMHO, a caching recursive any cast server ala 8.8.8.8 
> <http://8.8.8.8> 
> would
> be far more useful than just a stock "root server."
>
> > --
> > AMA March 31: 
> https://www.broadband.io/c/broadband-grant-events/dave-taht 
> <https://www.broadband.io/c/broadband-grant-events/dave-taht>
> > Dave T?ht CEO, TekLibre, LLC
> --
> Rod Grimes rgrimes@freebsd.org
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink 
> <https://lists.bufferbloat.net/listinfo/starlink>

-- 
****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel@auckland.ac.nz  
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************



[-- Attachment #2: Type: text/html, Size: 5874 bytes --]

Re: [Starlink] fiber IXPs in space

[tom]

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

The cdns, at least for streaming, could be higher since response time from them is not critical and the LEOs could serve as relays to earth. Depends whether it’s cheaper to do ISL between the LEOs and the higher satellites than linking down to earth for the stream.

 

From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf Of Ulrich Speidel via Starlink
Sent: Sunday, April 16, 2023 3:04 AM
To: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] fiber IXPs in space

 

Given that clients cache DNS responses (including iterative responses from root servers), having DNS in space would be a nice-to-have, but it's not the most pressing issue IMHO.

A far bigger problem is that a direct-to-site model like Starlink's essentially rules out placing CDN servers in close proximity to web clients. For those unfamiliar with them: CDNs (content delivery networks, which now carry a huge percentage of Internet content traffic) work by redirecting HTTP(S) requests for content to a CDN server that's in closer topological (and, by inference, physical) proximity to your web browser. That keeps repeated requests for the same content off expensive and scarce long-distance bandwidth while allowing for fast TCP cwnd growth due to the low RTT in the branch- and (thus collectively) bandwidth-rich local ISP networks. But that doesn't work for Starlink: There's no way to prevent everyone watching the same cat video via Starlink in your area from having to take up scarce space segment bandwidth each time the video is viewed. And we're talking serious data volumes here, unlike for DNS.

You could, in principle, put CDN servers onto the satellites, but that would require the many earthly CDN providers to (a) persuade Elon that this is a good idea, (b) buy the service off SpaceX as it's unlikely they'll be given rack space on the Starlink fleet, and (c) you'd need a lot of storage capacity on each satellite in space, with a much reduced probability of a cache hit, since the fact that the satellites move across pretty much the whole globe over time, your next cat video download for your mates in town might need to come from a different satellite, and the satellite you currently talk to needs to cache not just stuff you and your neighbours like, but also stuff everyone else around the globe likes. So make that Chilean soap operas over Ukraine, Danish comedy for Australia, Aussie Rules Footy for the US Midwest, and so on... Or maybe quietly can the concept altogether.    

On 16/04/2023 11:56 am, Rodney W. Grimes via Starlink wrote:

> On Fri, Apr 14, 2023 at 12:36?PM David Lang  <mailto:david@lang.hm> <david@lang.hm> wrote:
> >
> > On Fri, 14 Apr 2023, Rodney W. Grimes via Starlink wrote:
> >
> > >> I keep wondering when or if Nasa will find a way to move their DNS
> > >> root server "up there" . DNS data is not all that much... it is the
> > >> original distributed database...
> > >
> > > As others have pointed out a "root server" may not be very advantages,
> > > but what I think would be far better is to put up a couple of anycast
> > > recursive caching resolvers, aka 8.8.8.8/8.8.4.4 <http://8.8.8.8/8.8.4.4>  and almost anyone
> > > can do that, including starlink itself.
> >
> > I believe that the root servers are all (or almost all) anycast nowdays.
> 
> Anycast is perfect for an orbital DNS.

BUTT, root servers are NOT recursive or caching, they serve a very
small limitited set of data that changes at low frequency (I am
not sure of the current rate of updates, but it use to be only
once daily.)

Anyone can bring up there own replicate of a root server locally,
I do, and have for 2 decades, its a rather trivial thing to setup
and maintain. But unlike a root, I also turn on recursision and
caching.

Again IMHO, a caching recursive any cast server ala 8.8.8.8 <http://8.8.8.8>  would
be far more useful than just a stock "root server."

> -- 
> AMA March 31: https://www.broadband.io/c/broadband-grant-events/dave-taht
> Dave T?ht CEO, TekLibre, LLC
--
Rod Grimes rgrimes@freebsd.org <mailto:rgrimes@freebsd.org> 
_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net> 
https://lists.bufferbloat.net/listinfo/starlink

-- 
****************************************************************
Dr. Ulrich Speidel
 
School of Computer Science
 
Room 303S.594 (City Campus)
 
The University of Auckland
u.speidel@auckland.ac.nz <mailto:u.speidel@auckland.ac.nz>  
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************
 
 
 

[-- Attachment #2: Type: text/html, Size: 7533 bytes --]

Re: [Starlink] fiber IXPs in space

[Ulrich Speidel]

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

It doesn't really solve the fundamental problem, though: Every single 
copy of your cat video takes up RF bandwidth from the satellite to the 
ground.

Sure, you can save on uplink bandwidth to the satellite by putting a CDN 
server into space, but that's only a factor of two, when terrestrial 
CDNs already get way more than that on long distance fibre.

Let's do a back-of-the-envelope:

Base scenario: Population in Sampletown: 100,000. Cat video: 100 MB. 
Percentage of users wanting to watch cat video of Sampletown's kindy's 
resident cat making off with a lego piece: 0.1% = 100. 40,000 Starlink 
satellites (looking ahead here). Number of people interested in the 
video outside Sampletown: basically zero.

Variant 0: No CDN server in Sampletown, backhaul to Sampletown via 
fibre, local users on fibre.

  * Video sent to CDN server once: 100 MB = 80 Gb load on fibre.
  * Total spectrum use: zero

Variant 1: CDN server in Sampletown, backhaul to Sampletown via fibre, 
local users on fibre.

  * Video sent to CDN server once: 100 MB = 800 Mb load on fibre.
  * Total spectrum use: zero

Variant 2: Everyone in Sampletown uses Starlink, no CDN in space.

  * Video uplinked 100 times: 80 Gb load on Starlink uplink bandwidth.
  * Video downlinked 100 times: 80 Gb load on Starlink downlink bandwidth.
  * Total spectrum use: 160 Gb

Variant 3: Everyone in Sampletown uses Starlink, some sort of CDN in 
space on the Starlink satellites themselves.

  * Video uplinked only to satellites that don't have a copy. After the
    first view of the video, the probability of the second viewer using
    the same satellite that handled the first view is 1 in 40,000. l.e.,
    almost none of the 100 views will strike a satellite that already
    has a copy. That will only happen for videos with tens of thousands
    of views. So you get : 80 Gb load on Starlink uplink bandwidth.
  * Video downlinked 100 times: 80 Gb load on Starlink downlink bandwidth.
  * Total spectrum use: 160 Gb

Variant 4: Everyone in Sampletown uses Starlink, some CDN in space 
residing on GEO sats, so there's one GEO sat where all cat videos for 
Sampletown end up.

  * Video uplinked to a Starlink sat on first request from CDN on GEO
    sat: 800 Mb. Further uplink to GEO via laser - 800 Mb load on laser.
  * Video downlinked 100 times: 80 Gb load on Starlink downlink
    bandwidth, plus 80 Gb load on laser from GEO sat CDN to Starlink
    satellite below.
  * Total spectrum use: 80.8 Gb, plus a bit of light pollution. That's
    your factor of 2 improvement.

Variant 5: CDN server in Sampletown, backhaul to Sampletown via 
Starlink, local users on fibre.

  * Video sent to CDN server once: 100 MB = 800 Mb load on Starlink
    uplink and downlink to CDN.
  * Total spectrum use: 1.6 Gb. That's a factor of 50-100 over the
    previous three scenarios.
  * But: That's not direct to site. It requires you as an end user not
    to be on Starlink.

It's the downlink to your dishy that spoils the party.

On 17/04/2023 1:01 am, tom@evslin.com wrote:
>
> The cdns, at least for streaming, could be higher since response time 
> from them is not critical and the LEOs could serve as relays to earth. 
> Depends whether it’s cheaper to do ISL between the LEOs and the higher 
> satellites than linking down to earth for the stream.
>
> *From:* Starlink <starlink-bounces@lists.bufferbloat.net> *On Behalf 
> Of *Ulrich Speidel via Starlink
> *Sent:* Sunday, April 16, 2023 3:04 AM
> *To:* starlink@lists.bufferbloat.net
> *Subject:* Re: [Starlink] fiber IXPs in space
>
> Given that clients cache DNS responses (including iterative responses 
> from root servers), having DNS in space would be a nice-to-have, but 
> it's not the most pressing issue IMHO.
>
> A far bigger problem is that a direct-to-site model like Starlink's 
> essentially rules out placing CDN servers in close proximity to web 
> clients. For those unfamiliar with them: CDNs (content delivery 
> networks, which now carry a huge percentage of Internet content 
> traffic) work by redirecting HTTP(S) requests for content to a CDN 
> server that's in closer topological (and, by inference, physical) 
> proximity to your web browser. That keeps repeated requests for the 
> same content off expensive and scarce long-distance bandwidth while 
> allowing for fast TCP cwnd growth due to the low RTT in the branch- 
> and (thus collectively) bandwidth-rich local ISP networks. But that 
> doesn't work for Starlink: There's no way to prevent everyone watching 
> the same cat video via Starlink in your area from having to take up 
> scarce space segment bandwidth each time the video is viewed. And 
> we're talking serious data volumes here, unlike for DNS.
>
> You could, in principle, put CDN servers onto the satellites, but that 
> would require the many earthly CDN providers to (a) persuade Elon that 
> this is a good idea, (b) buy the service off SpaceX as it's unlikely 
> they'll be given rack space on the Starlink fleet, and (c) you'd need 
> a lot of storage capacity on each satellite in space, with a much 
> reduced probability of a cache hit, since the fact that the satellites 
> move across pretty much the whole globe over time, your next cat video 
> download for your mates in town might need to come from a different 
> satellite, and the satellite you currently talk to needs to cache not 
> just stuff you and your neighbours like, but also stuff everyone else 
> around the globe likes. So make that Chilean soap operas over Ukraine, 
> Danish comedy for Australia, Aussie Rules Footy for the US Midwest, 
> and so on... Or maybe quietly can the concept altogether.
>
> On 16/04/2023 11:56 am, Rodney W. Grimes via Starlink wrote:
>
>     > On Fri, Apr 14, 2023 at 12:36?PM David Lang <david@lang.hm>
>     <mailto:david@lang.hm> wrote:
>     > >
>     > > On Fri, 14 Apr 2023, Rodney W. Grimes via Starlink wrote:
>     > >
>     > > >> I keep wondering when or if Nasa will find a way to move
>     their DNS
>     > > >> root server "up there" . DNS data is not all that much...
>     it is the
>     > > >> original distributed database...
>     > > >
>     > > > As others have pointed out a "root server" may not be very
>     advantages,
>     > > > but what I think would be far better is to put up a couple
>     of anycast
>     > > > recursive caching resolvers, aka 8.8.8.8/8.8.4.4
>     <http://8.8.8.8/8.8.4.4>
>     and almost anyone
>     > > > can do that, including starlink itself.
>     > >
>     > > I believe that the root servers are all (or almost all)
>     anycast nowdays.
>     >
>     > Anycast is perfect for an orbital DNS.
>
>     BUTT, root servers are NOT recursive or caching, they serve a very
>     small limitited set of data that changes at low frequency (I am
>     not sure of the current rate of updates, but it use to be only
>     once daily.)
>
>     Anyone can bring up there own replicate of a root server locally,
>     I do, and have for 2 decades, its a rather trivial thing to setup
>     and maintain. But unlike a root, I also turn on recursision and
>     caching.
>
>     Again IMHO, a caching recursive any cast server ala 8.8.8.8
>     <http://8.8.8.8>
>     would
>     be far more useful than just a stock "root server."
>
>     > --
>     > AMA March 31:
>     https://www.broadband.io/c/broadband-grant-events/dave-taht
>     <https://www.broadband.io/c/broadband-grant-events/dave-taht>
>     > Dave T?ht CEO, TekLibre, LLC
>     --
>     Rod Grimes rgrimes@freebsd.org
>     _______________________________________________
>     Starlink mailing list
>     Starlink@lists.bufferbloat.net
>     https://lists.bufferbloat.net/listinfo/starlink
>     <https://lists.bufferbloat.net/listinfo/starlink>
>
> -- 
> ****************************************************************
> Dr. Ulrich Speidel
> School of Computer Science
> Room 303S.594 (City Campus)
> The University of Auckland
> u.speidel@auckland.ac.nz  
> http://www.cs.auckland.ac.nz/~ulrich/  <http://www.cs.auckland.ac.nz/~ulrich/>
> ****************************************************************

-- 
****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel@auckland.ac.nz  
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************



[-- Attachment #2: Type: text/html, Size: 13753 bytes --]