[Starlink] CDNs in space!

["David P. Reed" <dpreed@deepplum.com>]

[-- Attachment #1: Type: text/plain, Size: 4081 bytes --]


Having looked into this a lot, CDNs don't account for very much Internet traffic. There's a lot of marketing propaganda out there that suggests this might be true, but when you try to track down the source, it's almost always from an old slide deck presented by a company that sells CDN servers.
 
That doesn't mean that CDN servers don't help a fair bit, but no, today's Internet wouldn't fall apart if we didn't have CDN servers withint 2 msec. of the edge.
 
Also, CDN's need to be BIG to hold all the videos that people might choose to watch at any particular time.
 
So I'm just pointing out that the business case for CDN's in space to merely solve Starlink's potential issues is probably not great. Maybe 10 years from now. Maybe never. The idea that everyone watches TV and the same few seconds of content of a few shows that are extraordinarily popular - well, that dog don't hunt. It doesn't justify multicast either.
 
So let's improve the discussion here. The Internet, for the forseeable future, at the edge, is unicast.
 
CDN's reduce costs for big companies like Netflix, not because they are "close to the watcher" but because it is easier to not have everything centralized in a single point of failure and needing a huge pipe because all customers aggregate demand into their central HQ.
 
There are some advantages at the top level peering in distributing CDN sites into the networks of various access providers (like Comcast) because you can get cheaper pricing.
 
But lets think about CDNs in space. They don't deal with the actual bottleneck in each satellite to ground. The uplink from central ground stations has LOTS of capacity, it won't be the bottleneck if Starlink or any other satellite service for that matter balances its design.
 
And if they get inter-sat links (laser or maybe RF, if the interference problem with other satellites is resolved at the WRC or other international body that regulates RF in space) working, where are the CDNs going to maintain state? The reachable ones for any satellite in the constellation will be moving relative to the user's dishy, unless it the CDN is in geosync orbit).
 
Starlink isn't a media company. It doesn't want to own all the content, or even host all the content.
 
So I'm pretty darn skeptical!
 
At the moment, Starlink is a "last mile" service in a virtual sense. It connects from the public internet at some pretty high performance point of presence, hopefully has a pretty good latency, and doesn't let its users saturate any satellite (lest huge queueing delay build up). Given that, anywhere there is a ground station the public fiber backbone can reach all the CDNs.
 
It's hard to capitalize a last mile fiber service. Each home passed costs about $2000, if we want to connect up (that includes almost all actual rural residences, but not all the uninhabited parts of the planet). For whatever reason, the telcos want no one else to put in fiber, but also don't see much profit in extending their coverage, either, because they aren't allowed to charge for all the content like they used to. Fiber's great advantage is that it has extremely low operational expense.
 
This is what Starlink fills in for. It has lower capex, but HUGE opex. It can't perform or scale very well compared to the asymptotic fiber solution. So it has a pretty good short-term competitive position. And they've gotten very smart in finding early customers who are eager to buy in.
 
However, it's important to realize that what drives this all is how the Internet is used and who needs it where, and how much they are willing to pay.
 
One thing is clear - Starlink isn't the Internet of the future. It's filling a niche (a large one, but a niche).
 
The mistake Motorola made with Iridium was in not realizing that cellular telephony was in all respects a better answer, and would be cheaper, too. People did talk about putting CDNs in space with Iridium, too.
 
But one needs to understand what CDNs are useful for, and really understand what part of the problem that is.
 
 

[-- Attachment #2: Type: text/html, Size: 7835 bytes --]