On Fri, Dec 3, 2010 at 11:08 AM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Fri, Dec 3, 2010 at 10:47 AM, William Herrin <bill@herrin.us> wrote:
Perhaps the eyeball networks should build, standardize and deploy a content caching system so that the popular Netflix streams (and the live broadcast streams) can usually get their traffic from a local source. Deploy a cache to the neighborhood box and a bigger one to the local backend. Then organize your peering so that it's _less convenient_ to request large bandwidths than to write your software so it employs the content caches.
This brings with it an unsaid complication, the content-owner (netflix in this example) now depends upon some 'service' in the network (comcast in this example) to be up/operational/provisioned-properly for a service to the end-user (comcast customer in this example), even though NetFlix/Comcast may have no actual relationship.
Actually, there was nothing particularly "unsaid" about the complication:
Technology like web proxies has some obvious deficiencies. [...] Either way no real thought has been put in to how to determine that a proxy is misbehaving and bypass it in a timely manner. It just isn't as resilient as a bare Internet connection to the remote server.
[...] these are all solvable problems. Use anycast to find the nearest cache and unicast to talk to it. Use UDP to communicate and escalate lost, delayed or corrupted packets to a higher level cache or even the remote server. Trade auth and decryption keys with the remote server before fetching from the local cache. And so on.
You put some basic intelligence in the app: if local cache != working, try regional cache. If regional cache != working, go direct to main server. There's no SLA issue... if the ISP doesn't maintain the caching proxy (or doesn't deploy one at all) then they take the bandwidth hit instead with the same protocol served by a CDN or the originating company.
Oh, how do you deconflict situations where two content owners are using the 'service' in Comcast, but one is "abusing" the service? Should the content owners expect 'equal share'? or how does that work?
What conflict? If the cache isn't working to the app's standard, the app simply requests past it, straight to Netflix's servers if need be. The point is to produce a protocol and system for video and other broadcast delivery that can -opportunistically- reduce the long haul bandwidth consumption (and therefore cost) borne by the eyeball network. What would be the point in building something that critfails because one guy doesn't want to play and another has minor broken component in the middle? Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004