nanog mailing list archives

Re: The scale of streaming video on the Internet.


From: William Herrin <bill () herrin us>
Date: Fri, 3 Dec 2010 11:38:07 -0500

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


Current thread: