On Sun, Jul 13, 2014 at 10:17 AM, Todd Lyons <tly...@ivenue.com> wrote:
> On Sun, Jul 13, 2014 at 9:53 AM, Matthew Petach <mpet...@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
