Re: Verizon Public Policy on Netflix

[Matthew Petach <mpetach () netflight com>]

On Sun, Jul 13, 2014 at 10:17 AM, Todd Lyons <tlyons () ivenue com> wrote:

> On Sun, Jul 13, 2014 at 9:53 AM, Matthew Petach <mpetach () netflight com>
> wrote:
> > > > How would "4U of rent" and 500W($50) electricity *not* save money?
> > > Because, on top of that, we'd have huge bandwidth expenses.
> >
> > I know I'm just a dumb troll, but
> > don't you have the same bandwidth
> > demands already from your users
> > pulling down netflix content today?
>
> This is an interesting conversation to watch as a non-important,
> non-influential outsider.
>
> Brett's calculation is the cost of:
>
> (BW of preloading X new shows a week in multiple formats)
>   is greater than
> (BW of Z % of his user base watching Y streams a week)
>
> It's not been clearly stated whether X is 100% of new shows, but I
> suspect it's more along the lines of mostly what Netflix expects to be
> popular.
>
> Because that Netflix box is not an on-demand cache, it gets a bunch of
> shows pushed to it that may or may not be watched by any of Brett's
> customers.  Then the bandwidth he must use to preload that box is
> large, much larger than the sum of the streams his customers do watch.

Thank you for clarifying that; I thought what
Brett was concerned about was traffic in
the downstream direction, not traffic for
populating the appliance.


> Brett touched on this in the Security Now episode, but I don't think
> he was clear so I want to explore the realities of these options.
> IMHO two solutions exist that would make small people like Brett much
> happier with this Netflix box:
>
> 1) Make the box an on-demand cache: the first customer who watches a
> show causes the episode to stream/push_high_bw to the box, and from
> the box out to the customer.  Any subsequent customer gets it directly
> from the box, even if the initial stream is still ongoing.
> Complications do arise if the second (or third) customer tries to move
> beyond the current location of the initial stream.
>
> 2) My suggestion is probably less popular because it requires a person
> with (maybe more than) a few minutes, but give the list of shows
> desired to be pre-pushed to the box to $ISP and give them a couple
> hours to uncheck certain things that they know or suspect their users
> won't watch, allowing them to reduce their bandwidth usage.  And
> conversely, provide a checkbox of shows that the ISP wants to never be
> cached on the box.

What if Netflix provided a third option; give
the ISP a small UI through which they could
set a "not-to-exceed" traffic rate on the
appliance; the appliance would then seek
to fill itself with content according to its
priority-ranked listing by popularity, with
the rsync (or whatever underlying technology
it utilizes) set to rate limit itself to the value
set by the ISP.  It's already clear that netflix
can handle streaming content that is *not*
within the openconnect appliances, as that's
what they do for the rest of their long tail
content; this would simply shift where in the
list of content the "long tail" began for users
of this ISP.  This would allow the ISP to gain
the benefit of localized content sourcing for
the historically highly popular content, while
controlling the infeed volume to an acceptable
rate for their network.   Even setting a relatively
small infeed rate of 100mb/sec would allow the
appliance to populate 1TB/day of content, which
would account for 30 DVD-sized titles/day--and
I'm sure netflix compresses its data sources down
considerably better than a 4GB DVD image file.

I think that approach would help keep both
sides happier; Netflix keeps control over the
content in its appliance, and the smaller ISPs
get the traffic offload benefit without having
to sacrifice a huge volume of the upstream
bandwidth to the appliance.



> I did agree with the comment later in the email that making content
> freely cached is a non-starter because that content could be copied
> too easily.  However, if the Netflix box is what does all of the
> on-demand caching in #1, then it leaves the power in Netflix's hands,
> while not requiring the ISP to download multiple copies of shows that
> its users will never watch.
>
> A lot of this is dependent upon:
> 1) How many different copies of a single show are pushed to the box.
> Does that number vary per show.
> 2) How many shows are pushed/pre-pushed to the box per week.  How
> frequently.
>
> ...Todd
> --
> The total budget at all receivers for solving senders' problems is $0.
> If you want them to accept your mail and manage it the way you want,
> send it the way the spec says to. --John Levine
Yup--I think fundamentally the challenge here
is how to give the ISP some level of control over
the bandwidth consumption.  Solving that, whether
by changing to a pure on-demand model, or by giving
a knob to change the infeed rate, would I think make
netflix considerably more popular with the smaller
sized ISPs.

Thanks!

Matt