From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp108.iad3a.emailsrvr.com (smtp108.iad3a.emailsrvr.com [173.203.187.108]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 3129B3B2A4 for ; Sun, 16 Apr 2023 09:01:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=evslin.com; s=20220608-p431o605; t=1681650072; bh=4YBwdt0JjF6MyhUPN4Tv/S0HbT4oWdrhWSm7P9/xIzQ=; h=From:To:Subject:Date:From; b=PgHhBV7VZYtP0e5Wcha31uFIxUkz6j1jXIUwHrAjFw9nzw7B55IHbI7dis5bnnYRU g8c1jeQevjXZyovQ0nr7gWD0YgxA3g8LhRWCI/tfPXxKaBLo2lRW5tjkciOTx4pS44 Fh7PsPGPV8WahrnD089V+GV8C7sg8/MXhC4lgb+s= X-Auth-ID: tom@evslin.com Received: by smtp22.relay.iad3a.emailsrvr.com (Authenticated sender: tom-AT-evslin.com) with ESMTPSA id 545D645CC; Sun, 16 Apr 2023 09:01:12 -0400 (EDT) From: To: "'Ulrich Speidel'" , References: <202304152356.33FNuD8m049509@gndrsh.dnsmgr.net> <7ed253a9-15d2-d0fd-af59-c5996687ab5b@auckland.ac.nz> In-Reply-To: <7ed253a9-15d2-d0fd-af59-c5996687ab5b@auckland.ac.nz> Date: Sun, 16 Apr 2023 09:01:11 -0400 Message-ID: <1c03701d97063$85436500$8fca2f00$@evslin.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1C038_01D97041.FE32AF60" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGPpgzzXrUaLizMQKsvFES5yrEBNwGU1kCYr7TStlA= Content-Language: en-us X-Classification-ID: 2f52d2d2-772d-447e-8f39-8b629238b39f-1-1 Subject: Re: [Starlink] fiber IXPs in space X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Apr 2023 13:01:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_1C038_01D97041.FE32AF60 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=99s cheaper to do ISL between the LEOs and the = higher satellites than linking down to earth for the stream. =20 From: Starlink 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 =20 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. =20 On 16/04/2023 11:56 am, Rodney W. Grimes via Starlink wrote: > On Fri, Apr 14, 2023 at 12:36?PM David Lang = 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. >=20 > 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." > --=20 > AMA March 31: = https://www.broadband.io/c/broadband-grant-events/dave-taht > Dave T?ht CEO, TekLibre, LLC -- Rod Grimes rgrimes@freebsd.org =20 _______________________________________________ Starlink mailing list Starlink@lists.bufferbloat.net =20 https://lists.bufferbloat.net/listinfo/starlink --=20 **************************************************************** Dr. Ulrich Speidel =20 School of Computer Science =20 Room 303S.594 (City Campus) =20 The University of Auckland u.speidel@auckland.ac.nz =20 http://www.cs.auckland.ac.nz/~ulrich/ **************************************************************** =20 =20 =20 ------=_NextPart_000_1C038_01D97041.FE32AF60 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

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=E2=80=99s 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> 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: http= s://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.bu= fferbloat.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/
************************************=
****************************
 
= 
 
 
------=_NextPart_000_1C038_01D97041.FE32AF60--