On Oct 11, 2021, at 13:05 , Matthew Petach <mpetach@netflight.com> wrote:
On Mon, Oct 11, 2021 at 1:01 AM Mark Tinka <mark@tinka.africa> wrote: However, in an era where content is making a push to get as close to the eyeballs as possible, kit getting cheaper and faster because of merchant silicon, and abundance of aggregated capacity at exchange points, can we leverage the shorter, faster links to change the model?
Mark.
I think it would be absolutely *stunning* for content providers to turn the model on its head; use a bittorrent like model for caching and serving content out of subscribers homes at recalcitrant ISPs, so that data doesn't come from outside, it comes out of the mesh within the eyeball network, with no clear place for the ISP to stick a $$$ bill to.
I worked for a company that tried this model several years back. It did not go well. Users were not happy. Eyeball ISPs were very not happy (and started actively mitigating users who participated through a variety of nefarious means), and content providers got a bit hot under the collar about it (the experiment was a content aggregator for lack of a better term).
Imagine you've got a movie; you slice it into 1,000 encrypted chunks; you make part of your license agreement for customers a requirement that they will allow you to use up to 20GB of disk space on their computer and to serve up data chunks into the network in return for a slightly cheaper monthly subscription cost to your service. You put 1 slice of that movie on each of 1,000 customers in a network; then you replicate that across the next thousand customers, and again for the next thousand, until you've got enough replicas of each shard to handle a particular household going offline. Your library is still safe from piracy, no household has more than 1/1000th of a movie locally, and they don't have the key to decrypt it anyhow; but they've got 1/1000th of 4,0000 different movies, and when someone in that ISP wants to watch the movie, the chunks are being fetched from other households within the eyeball network. The content provider would have shard servers in region, able to serve up any missing shards that can't be fetched locally within the ISP--but the idea would be that as the number of subscribers within an ISP goes up, instead of the ISP seeing a large, single-point-source increase in traffic, what they see is an overall increase in east-west traffic among their users.
That’s a pretty close description of exactly what we did.
Because the "serving of shards to others" happens primarily while the user is actively streaming content, you have a natural bell curve; during peak streaming times, you have more nodes active to serve up shards, handling the increased demand; at lower demand times, when fewer people are active, and there's fewer home-nodes to serve shards, the content network's shard servers can pick up the slack...but that'll generally only happen during lower traffic times, when the traffic won't be competing and potentially causing pain for the ISP.
It’s a beautiful theory. We expected this to be the case, too. Turns out, not so much. There’s an awful lot of long tail out there that is poorly accounted for in this. Yes, it does help with some of the most popular content, but there are pitfalls there, too.
Really, it seems like a win-win scenario.
We thought so too, until we learned otherwise. Today, with more symmetrical connections and larger uplinks, it might be more feasible. Back then (Around 2005), it was a good idea on paper.
I'm confident we'll see a content network come out with a model like this within the next 5 years, at which point the notion of blackmailing content networks for additional $$$s will be a moot point, because the content will be distributed and embedded within every major eyeball network already, whether they like it or not, on their customer's devices.
You’d be surprised at the number of different ways eyeball providers have to denature such an effort. I’m sorry to rain on your parade, but it’s not a new idea. I was brought in as the operations guy once the software engineers realized that they needed someone who could, you know, keep stuff running and not just write code and test it in production. This model resulted in a frank and uncomfortable conversation between me and the developer of what was internally being called the “overlay network” code. We went through a number of different scenarios where he had made incorrect assumptions about how the internet worked, especially at the eyeball end and there were a dozen or so that we simply couldn’t find ways to work around. Networks are a bit different now and some content providers have people far more clever than I working on things like this, so who knows… It might succeed by 2026, but when we tried it in 2005, we couldn’t make it work well enough to avoid annoying anyone involved.
Let's check back in 2026, and see if someone's become fantastically successful doing this or not. ;)
I’ll look forward to it. Owen