It would do little good; my hit rate on such a cache would be unlikely to
be high enough to merit the traffic to keep it charged.
Cheers,
-- jra
"allow my customers as an ISP to cache the content at their home".
Do you *mean* "their home" -- an end-user residence?
Yes, I do *mean* that.
As in you, Jay, should be allowed to run your own cache server in your
home (Traffic Server is the one that I'm using in the TLMC concept).Wouldn't you like that?
It would do little good; my hit rate on such a cache would be unlikely to
be high enough to merit the traffic to keep it charged.
(Children watching a movie only once? Not a chance. It's more like unlimited number of times and then some more...).
So don't set-up an cache server at your home/residence.
From: "fredrik danerklint" <fredan-nanog@fredan.se>
> It would do little good; my hit rate on such a cache would be
> unlikely to be high enough to merit the traffic to keep it charged.(Children watching a movie only once? Not a chance. It's more like
unlimited number of times and then some more...).
"DVD's."
"MythTV"
So don't set-up an cache server at your home/residence.
I probably won't.
But it has become unclear what your fundamental premise and argument are,
by this point in the game.
Is it: "it is bad that content providers choose a business and technical
model wherein local in-home transparent caching proxies won't work?"
Cause that's a non-starter.
Cheers,
-- jra
How about buy the movies in question, convert them to MP4, install a media server on a local box and configure Xbox, tablet, smart-phone, whatever to access the media server? That is how my 3 year old grandson watches the Bubble Guppies movie umpteen million times during a 4 day stay. Just a thought. Oh, it also affords my wife and I the luxury of having our entire movie collection available for on demand viewing. No searching through cases or disc binders. Just a thought.
How about buy the movies in question, convert them to MP4, install a media server on a local box and configure Xbox, tablet, smart-phone, whatever to access the media server?
No. Streaming from services, like Netflix, HBO, etc..., is what's
coming. We need to prepare for the bandwidth they are going to be
using.
Oh, it also affords my wife and I the luxury of having our entire movie collection available for on demand viewing. No searching through cases or disc binders. Just a thought.
You do have one point with this, though. Being able to watch movies
when the Internet connection is down.
But it has become unclear what your fundamental premise and argument are,
by this point in the game.
See the subject of this thread?
Is it: "it is bad that content providers choose a business and technical
model wherein local in-home transparent caching proxies won't work?"
No, it's not.
Then work on your HTTP caching infrastructure. All these services already use a proprietary form of HTTP adaptive streaming, either MSFT, Adobe, or Apple. These technologies are being unified by DASH in the MPEG/ISO standards bodies.
Adaptive HTTP chunk streaming gives you the best of multicast-like and cached VoD behavior, exploiting the temporal locality of popularity in content while not requiring multicast.
As a content publisher, I must say it works wonders for us so far, even with just two bitrates. There is a huge HTTP caching infrastructure out there in businesses, schools, and other orgs that is unused by other video transports; even plain HTTP downloads usually overrun cache object size limits.
The Olympic streaming in particular showed how well HTTP chunk video can scale; dozen of screens in my org showed the same content all day from local cache, with no noticeable spikes on our transit links.
Is HTTP as efficient a protocol as possible for transporting video? No, but 1K of headers per 1M of content chunk
puts it within 0.1% of netcat. And "working now with widely deployed infrastructure" beats "stuck in Internet Draft forever".
These technologies are being unified by DASH in the MPEG/ISO standards bodies.
Then we have to hope that we will see this implemented in
Traffic Server, Squid, Varnish, so that everybody can benefit
from this.
You're missing the entire point: all web caches *already* work with
DASH and the proprietary HTTP chunking flavors. It's just HTTP request/response
data.
My employer's statistics show this to be true; we do video for
compliance training
and we see massive benefit from local caches in our customer's
networks. We send a cache-enabled customer site each video chunk just
about once on average, and their cache takes care of distribution to
up to thousands of internal viewers.
HTTP chunk streaming works today with Silverlight/Flash/Quicktime
plugins, and there is a working prototype of the standardized DASH
that use only an modern web browser and JavaScript with no plug-ins:
http://dash-mse-test.appspot.com/dash-player.html
That's not the general case, however. That's a set of specialized videos where
you know you will have a large number of consumers at each site viewing the
same video content.
Owen
That's not the general case, however. That's a set of specialized videos =
where
you know you will have a large number of consumers at each site viewing =
the
same video content.
Kind of like the special cases you need in order for multicast to
work out, hey?
So it looks like the Internet noticed we had broken its multicast
and found a way to work around that damage. 
... JG
A good example of (growing!) corner-case wide-area multicast is real-time remote sensor networking, although that does not tend to natively cross ISPs due to the breakage previously identified. The traffic flows there are basically backwards from the IPTV / video flows, so they don't contribute bandwidth problems nearly as much as they do (s,g) state problems.
David Barak
Need Geek Rock? Try The Franchise:
http://www.listentothefranchise.com