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, [email protected] 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 <[email protected]> *On Behalf
Of *Ulrich Speidel via Starlink
*Sent:* Sunday, April 16, 2023 3:04 AM
*To:* [email protected]
*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 <[email protected]>
<mailto:[email protected]> 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 [email protected]
_______________________________________________
Starlink mailing list
[email protected]
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
[email protected]
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
[email protected]
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************
_______________________________________________
Starlink mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/starlink
