nanog mailing list archives
Re: The scale of streaming video on the Internet.
From: William Herrin <bill () herrin us>
Date: Fri, 3 Dec 2010 10:47:44 -0500
On Thu, Dec 2, 2010 at 3:28 PM, Owen DeLong <owen () delong com> wrote:
On Dec 2, 2010, at 12:21 PM, Leo Bicknell wrote:Sunday Night Football at the top last week, with 7.1% of US homes watching. That's over 23 times as many folks watching as the 0.3% in our previous math! Ok, 23 times 150Gbps. 3.45Tb/s. Yowzer. That's a lot of data. 345 10GE ports for a SINGLE TV show.You are assuming the absence of any of the following optimizations: 1. Multicast 2. Overlay networks using P2P services (get parts of your stream from some of your neighbors).
Leo and Owen: Thank you for reminding us to look at the other side of the problem. If the instant problem is that the character of eyeball-level Internet service has shifted to include a major component of data which is more or less broadcast in nature (some with time shifting, some without). There's a purely technical approach that can resolve it: deeply deployed content caches. Multicasting presents some difficult issues even with live broadcasts and it doesn't work at all for timeshifted delivery (someone else starts watching the same movie 5 minutes later). As for P2P... seriously? I know a couple companies have tinkered with the idea but even if you could get good algorithms for identifying the least consumptive source, it still seems like granting random strangers the use of your computer as a condition of service would get real old real fast. But there's a third mechanism worth considering as well: the caching proxy. 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. Maybe even make that a type of open peering: we'll give all comers any sized port they want, but address-constrained so it can only talk to our content caches. Technology like web proxies has some obvious deficiencies. Implemented transparently they reduce the reliability of your web access. Implemented by configuration, finding the best proxy is a hassle. 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. But with a content cache designed to implement a near-real-time caching protocol from the ground up, 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. So, build a content caching system that gives you a multiplier effect reducing bandwidth aggregates to a reasonable level. And then organize your peering process so when technically possible, it's always more convenient to to use your caching system than request a bigger pipe. You'll still have to eventually address the fairness issues associated with Network Neutrality. But having provided a reasonable technical solution you can do it without the bugaboo of network video breathing down your neck. And oh by the way you can deny your competitors Netflix's business since they'll no longer need quite such huge bandwidths after employing your technology. Here's hoping nobody offers me a refund on my two cents... 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:
- Re: The scale of streaming video on the Internet., (continued)
- Re: The scale of streaming video on the Internet. david raistrick (Dec 02)
- Re: The scale of streaming video on the Internet. Jack Bates (Dec 02)
- Re: The scale of streaming video on the Internet. Antonio Querubin (Dec 02)
- Re: The scale of streaming video on the Internet. david raistrick (Dec 02)
- Re: The scale of streaming video on the Internet. Owen DeLong (Dec 02)
- Re: The scale of streaming video on the Internet. Jared Mauch (Dec 03)
- CAP / WARN / iPAWS Jay Ashworth (Dec 02)
- Re: CAP / WARN / iPAWS Richard Barnes (Dec 02)
- Re: CAP / WARN / iPAWS Dobbins, Roland (Dec 02)
- Re: The scale of streaming video on the Internet. Antonio Querubin (Dec 02)
- Re: The scale of streaming video on the Internet. Christopher Morrow (Dec 03)
- Re: The scale of streaming video on the Internet. Leo Bicknell (Dec 03)
- Re: The scale of streaming video on the Internet. Christopher Morrow (Dec 03)
- Re: The scale of streaming video on the Internet. Leo Bicknell (Dec 03)
- Re: The scale of streaming video on the Internet. Bill Stewart (Dec 04)
- Re: The scale of streaming video on the Internet. Jay Ashworth (Dec 04)
- Re: The scale of streaming video on the Internet. Scott Morris (Dec 04)
- Re: The scale of streaming video on the Internet. bmanning (Dec 04)
- Re: The scale of streaming video on the Internet. Lyndon Nerenberg (VE6BBM/VE7TFX) (Dec 05)