[Starlink] fiber IXPs in space
Ulrich Speidel
u.speidel at auckland.ac.nz
Sun Apr 16 09:48:26 EDT 2023
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 at 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 at lists.bufferbloat.net> *On Behalf
> Of *Ulrich Speidel via Starlink
> *Sent:* Sunday, April 16, 2023 3:04 AM
> *To:* starlink at 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 at lang.hm>
> <mailto:david at 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 at freebsd.org
> _______________________________________________
> Starlink mailing list
> Starlink at 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 at 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 at auckland.ac.nz
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20230417/31183265/attachment-0001.html>
More information about the Starlink
mailing list