S.Korea broadband firm sues Netflix after traffic surge

Tue Oct 12 21:00:43 UTC 2021

>
> 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'm familiar with some work and ideas that have gone into such a thing, and
I'm personally very much against it for non-technical reasons.

Given how far the law lags behind technology, the last thing anyone should
be ok with is a 3rd party storing bits on ANYTHING in their house, or
transmitting those bits from a network connection that is registered to
them.

On Mon, Oct 11, 2021 at 4:06 PM Matthew Petach <mpetach at netflight.com>
wrote:

>
>
> On Mon, Oct 11, 2021 at 1:01 AM Mark Tinka <mark at 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.
>
> 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.
>
> 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.
>
> Really, it seems like a win-win scenario.
>
> 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.
>
> Let's check back in 2026, and see if someone's become fantastically
> successful doing this or not.  ;)
>
> Thanks!
>
> Matt
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20211012/ba957842/attachment.html>