Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×

Comment Re:why? (Score 1) 346

Yes, in the case of Gmail, the property in which the letter is stored (your inbox) is owned by the deliveryman, who does have legal access to that inbox. That's the difference.

Not that they should be allowed to; and it seems they know this, which is why they're insisting upon a court order.

Comment Re:Everybody is wrong... (Score 1) 270

What's the miss rate on an ISP-side cache of the entire Netflix library? I'm guessing it's 0 or some such, since it's oh, uh... the entire library? And you, like everyone else, are still failing to address streaming devices, which have no local storage and, therefore, can't cache gigabytes or terabytes of data (so that'd be what, a 100% miss rate?); and ISP-side cache covers these, as well.

Yes, keeping the cache as close to its point of use as possible is ideal. For the devices most people are streaming to, that's the ISP. Yes, Netflix could sell a cache device their users could install on their networks, but that incurs support costs for millions of users, many, if not most, of whom wouldn't have the first clue how to plug in a network cable, so no, it's not a viable solution, where an ISP-side cache is not only a viable solution, it's one Netflix has been working with ISPs to implement for a while now; Comcast, Verizon, and AT&T are really the only ones refusing to accept the free equipment at this point.

Comment Re: Everybody is wrong... (Score 1) 270

For several months, Netflix offered Comcast the hardware (and support for such) for ISP-side caching, for free, and Comcast's response was to demand payment from Netflix in order to host these servers that work to save Comcast money, then, when Netflix didn't cave, move Level3's (Netflix's provider) peering to lower quality interfaces until they agreed to pay.

Furthermore, how, exactly, would a customer cache work in the way you are describing when the most popular package Comcast sells is barely capable of streaming a single HD stream from Netflix while browsing the web and has about 1/10 as much upstream as it does downstream? How is the second user going to stream from the first when the first, even under ideal conditions, can only provide 1/10 of the required throughput? And Netflix caching servers? You realize that Netflix has a CDN, right? If your ISP doesn't have a local Netflix cache (again, Netflix will provide the hardware and support for free), then you're hitting the Netflix CDN, which will have a node near you. Of course, that node sits on the other side of a backbone provider that your ISP can throttle if they want to extort money from Netflix. That's why both of those solutions fail hard.

Comment Re: Everybody is wrong... (Score 1) 270

Precisely. The entire concept of an end-user-side cache of a several-petabyte library relies on knowing in advance exactly which part(s) of that library the user will want, far enough in advance to cache them, while requiring the user to have available storage for the cache. Since, by definition, streaming services are on-demand, there is no way to know this in advance, so even more storage is required. And still, nobody has addressed the issue of streaming devices (perhaps because those who might be able to address it don't know them by that term -- not likely, but hey -- I'm talking about AppleTV and the like) which have no local storage for such a cache.

I get this, my non-techie wife gets this, my project manager gets this, you seem to get this; why does it seem that nobody else does?

Comment Re:Everybody is wrong... (Score 1) 270

That is exactly the "fast lane" concept, where you are paying Netflix to pay Comcast ...

No, paying the USPS *at all* to deliver to China is akin to me paying Netflix to pay Comcast. Paying the USPS *more* to deliver faster is akin to... what, exactly, in this case? There's no analogue.

Furthermore, "Postage Due" has no analogue here, and is, as I said previously, therefore irrelevant to this discussion; Comcast is delivering the packets, just more slowly, whereas USPS will simply hold a "Postage Due" package until that postage has been paid, or will return it to the sender. You also failed to point out how COD, which you mentioned previously, is relevant, most probably because you realized it's actually not.

The whole "I pay for my post office box" analogy falls apart when you realize that Comcast is actually delaying packets based on their point of origin, rather than which of their peers passed them along. The analog for that would be USPS delaying packages shipped by you, but only if you shipped them via FedEx using SmartPost (google it if you're not familiar) because, even though FedEx is paying them to carry the package for the last leg of the delivery, because you aren't also paying them. This would land the USPS in hot water, as well, which is why people seem to have a problem when Comcast does it.

UPS' service is irrelevant because it cones down to the recipient redirecting the delivery, something the sender has no control over. Keep trying to muddy the waters, though; you ought to be able to get something to stick eventually, right? And the discussion about pricing? Really? I guess, if you really want me to agree with you on something, I'll give you that; not as though I'm conceding on any point I was actually arguing, though.

Comment Re:Everybody is wrong... (Score 1) 270

I pay USPS; if some of what I pay USPS is passed off, by them, to China Post, that is inconsequential to me. Paying extra for special delivery options is an interesting point I hadn't thought of previously; that being said, there is no analogy for that here, as there is no means by which to pay a provider extra to make them maky your ISP deliver the packets faster; you pay your ISP extra for that. As for COD/Postage Due, that's a specific shipping option that some carriers make available to the sender, which, again, has no analogue here. If I'm missing something, please correct me, but I won't hold my breath.

Comment Re:Everybody is wrong... (Score 1) 270

But you have to know *WHAT* to cache. Will I watch Family Guy tonight? Or will I watch American Dad? Or maybe something else entirely? Hell, I might watch anything from the Netflix catalog, so I guess I need to cache all of it. You're totally missing the boat when Netflix is willing and able to colocate their hardware in ISP datacenters and, even in some cases, willing to pay to be allowed to do so; and we're talking about hardware that caches 100% of their catalog. You also fail to address streaming devices which have no local storage (and, therefore, no means by which to cache anything). You're also glossing over the fact that, with an end-user-side cache, each video being cached (whether it's ever watched or not) is yet more data being pushed through external links, which cost both Netflix and the ISP more money, while a colo solution means pushing each piece of content through those links exactly once, after which it's in the ISP-local cache and only has to traverse the ISP's "only as congested as we allow it to be" network.

Seriously, give this a bit of thought before you start mashing keys.

Comment Re:Everybody is wrong... (Score 1) 270

And how, exactly, would implementing an end-user-side cache make things any better? All of that data would have to traverse the ISP network still; in fact, in order to address the issues caused by congestion (e.g. frequent pauses and breaks in the video stream), *more* data would have to traverse the ISP network, in order fo that data to already be in the user's cache before they requested it; since we can't know what the user is going to request before they do so, we have to send a little bit of everything. Were you planning on increasing the system requirements for using Netflix to gigabytes or terrabytes of disk space? And what about streaming devices that don't have local storage at all?

Methinks your solution wasn't very well thought out, my friend.

Slashdot Top Deals

"God is a comedian playing to an audience too afraid to laugh." - Voltaire

Working...