Published: Fri 18 November 2016
internet satellites spacex
Many news services reported already on the SpaceX plan to launch a number of
satellites to provide internet access; for example
Ars, or more specific
discussion at reddit. In short, SpaceX is planning to set up a constellation of
over 4k satellites that provide two directional internet access to ground
radios. Since the satellites don’t work yet and the best real project we can
compare it with is the relatively slow Iridium network, a lot of the comments
I’ve read seem to concentrate on questions you’d ask about a broadband / fiber
network. And I think they largely miss the big picture.
A lot of questions are about standard things we care about now:
What’s the available bandwidth? (23Gbps per satellite)
What’s the total bandwidth of the project? (depends on ground ISPs)
What’s the latency of the communication? (first hop around/under 20ms)
How well is it going to work in cloudy weather? (pretty well - atmosphere and
water don’t affect Ku band / 12-18GHz that much)
And those questions are relevant. And it’s great that the access speed will be
pretty much unified around the world - no more dialup because you live in the
middle of nowhere, or telco exchange run out of available connection ports.
But those questions assume the current model of accessing the internet. And soon
that’s going to be soooooo 2016.
Questions that we should ask
Global satellite internet used all over the world gives us opportunities that
weren’t available before. Multicast and caching will be possible like never
before. Not multicast as specified and available right now, but the idea. The
latency may be actually lower than what we’re used to right now.
We don’t have to be stuck with the current 1:1 connection model. It’s pretty
convenient for simplicity, but it just doesn’t scale that well. Did you watch
all of House of Cards episodes within the first weekend after release? So did
~670,000 others. And that means the whole size of 13 episodes were copied
~670,000 times and transferred to the viewers, every time, all the way from your
nearest Netflix data store. It didn’t just take Netflix’s bandwidth. Your local
ISP’s network probably made an “Ugh…” sound a few times - just as your
neighbours trying to play low-latency games during the same time. Most consumer
networks are oversubscribed and you can see that when the bandwidth goes down in
But that doesn’t have to be the case. We’re not that unique. A lot of what we
do is pretty common and likely fairly area/language-specific. If you’re watching
that new cat video on Facebook, or reading that article in
NYT, you can be
almost certain that someone within 100km of you is doing the same thing right
now. If the data is literally broadcast, it doesn’t matter who requested it if
we can all get it at the same time. Multicasting would stop the data duplication
and actually free up some bandwidth for unique requests.
Let’s go further. You don’t have to start receiving the data after you request
it - you can do it earlier. There’s a limitted number of transmitters on the
satellite, so even if the data is ready to be beamed to you, sometimes you’ll
just have to wait. But let’s assume some transmissions are marked as popular. If
your receiver sees them while waiting for something else, why not grab it anyway
and save to a local disk? It doesn’t matter that you don’t even know what it is
at the moment. It could be the new popular article. It could be a funny video.
It could be a header of a popular page that everyone will visit today. The
knows it’s popular, so save it, even to a cheap but large spinning disk. If the
disk dies, it was just a cache anyway.
Using that free time to cache whatever data is broadcast anyway can result in
effectively 0 latency. It doesn’t matter that the resource you wanted to reach
is 800ms away in total and hammered by broadband users. You already have it on
the disk attached to your radio. And the entity hosting the original content is
happy because they don’t have to serve it again.
The common internet we’re using today is not based on the tools we need for this
new system. We’re accessing specific names, like
expect to do the whole journey - resolve the dns, connect to the host, make
request, receive the bytes in one continuous stream. It’s been around forever
and it’s starting to get old. To use the features described before we need to
make two improvements:
stop caring who sends the data
start accessing content rather than names
This is already possible in some specific cases. For example
a specific content hash and you can get it from anyone. It’s a hash of the
content itself, so you can always verify it, regardless of the source.
tries to get a similar technology available everywhere. For example parts
of the website can be retrieved using IPFS js-ipfs from any IPFS node. That node
could be the cache attached to the radio in your house.
While the change is pretty slow, the foundation of this technology makes its way
into the standard browsers as well. Resources requested by the website may be
annotated with the content hash using
Subresource Integrity. In practice it
means that the browser can be allowed to make a request for a file with that
hash - wherever it happens to be. This ties in nicely with protocols like BT and
If you were paying attention to the internet development lately, you may be
asking “That’s completely incompatible with
HTTPS, why did we do that push for
then?”. And you’d be right in some cases. HTTPS everywhere
HTTPS provides authentication of parties, encryption of traffic, privacy, and
integrity. Sometimes you’ll want all of those for each element of the service.
Sometimes it’s not that critical. For example, when contacting your bank, you
may want to encrypt all the user-specific content, but since that content embeds
“and also download file with hash 0xDEADBEEF that I call helpers.js that’s not
user-specific”, you may choose to do that in public. (yes, multiple caveats
apply here, I’m simplifying) Since the integrity is still verified, encryption
and authentication may not matter.
In other case we’ve got a Netflix movie, which is going to be protected by some
DRM, so encryption is largely meaningless, authentication is available
via other requests, and the privacy can be handled via other channels. You could
easily request the DRM key over standard HTTPS request, but then play the files
which were broadcast over your area a few minutes ago.
There’s still the question of whether this tradeoff is important to you in each
case and how to differentiate between them. But that’s a large topic we won’t
solve straight-away. The important change to the model is that the requests and
responses don’t have to be easily related anymore. You could make a secret
request for data which is broadcast without identifying you. Or use things
downloaded by other users without any communication at all. This is a large
I, for one, welcome our new broadcast internet protocols.