Re: S.Korea broadband firm sues Netflix after traffic surge

[Owen DeLong via NANOG <nanog () nanog org>]

> 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