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