Re: [Starlink] fiber IXPs in space

[Ulrich Speidel <u.speidel@auckland.ac.nz>]

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