[Starlink] fiber IXPs in space

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

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

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

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]

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

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

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

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

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

[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

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

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

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

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

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

[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

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

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

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

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

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
>