Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: <tom@evslin.com>
To: "'Ulrich Speidel'" <u.speidel@auckland.ac.nz>,
	<starlink@lists.bufferbloat.net>
Subject: Re: [Starlink] fiber IXPs in space
Date: Sun, 16 Apr 2023 09:01:11 -0400	[thread overview]
Message-ID: <1c03701d97063$85436500$8fca2f00$@evslin.com> (raw)
In-Reply-To: <7ed253a9-15d2-d0fd-af59-c5996687ab5b@auckland.ac.nz>

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

  reply	other threads:[~2023-04-16 13:01 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-13 15:57 Dave Taht
2023-04-14 14:47 ` Rodney W. Grimes
2023-04-14 19:36   ` David Lang
2023-04-14 19:50     ` Dave Taht
2023-04-15 23:56       ` Rodney W. Grimes
2023-04-16  7:03         ` Ulrich Speidel
2023-04-16 13:01           ` tom [this message]
2023-04-16 13:48             ` Ulrich Speidel
2023-04-13 16:34 David Fernández
2023-04-13 17:22 ` Michael Richardson
2023-04-13 18:54   ` David Fernández
2023-04-13 20:01     ` Michael Richardson
2023-04-13 20:06       ` Tom Evslin
2023-04-16 17:54 David Fernández
2023-04-16 21:22 ` Ulrich Speidel
2023-04-16 22:03   ` David Lang
2023-04-16 22:42     ` Ulrich Speidel
2023-04-16 23:22       ` David Lang
2023-04-17  0:51         ` Ulrich Speidel
2023-04-17  1:04           ` David Lang
2023-04-17  2:08             ` Ulrich Speidel
2023-04-17  2:34               ` David Lang
2023-04-17  3:21                 ` Ulrich Speidel
2023-04-17  5:01                   ` David Lang
2023-04-17  5:50                     ` Sebastian Moeller
2023-04-16 21:58 ` David Lang
2023-04-17 14:38   ` Rodney W. Grimes
2023-04-17 14:47     ` David Fernández
2023-04-17 19:09       ` David Lang
2023-04-17 20:09         ` Ulrich Speidel
2023-04-17 20:37           ` David Lang
2023-04-17 19:00     ` David Lang
2023-04-18  7:46       ` David Fernández
2023-04-18  8:34         ` Sebastian Moeller
2023-04-18 13:30           ` David Fernández
2023-04-18 17:55             ` David Lang
2023-04-18  5:59 ` Chris J. Ruschmann
2023-04-18 13:01   ` David Fernández

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/starlink.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='1c03701d97063$85436500$8fca2f00$@evslin.com' \
    --to=tom@evslin.com \
    --cc=starlink@lists.bufferbloat.net \
    --cc=u.speidel@auckland.ac.nz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox