Peer-to-peer streaming

Josh Coates jcoates at archive.org
Tue Jan 10 08:48:29 MST 2006


> We would 
> do better to focus on overlay networks that implement such 
> features than on these myriad random one-off projects that 
> really constitute a technologically inferior solution (a 
> "hack" or a "kludge").

maybe.  or not.

the last time i did anything with multicast over the wide area was watching
things on the mbone http://en.wikipedia.org/wiki/Mbone back in 1998, but it
was pretty lame (though it was probably useful to the research folks.)  

steve mccane from berkeley went off an did a startup in 1998 based on this
idea.  iirc, the idea was to basically create a bunch of 'bridges' that
tunneled multicast traffic over networks that were unable (or unwilling) to
route multicast traffic themselves.

the vision was cheap (as in economic use of bandwidth) broadcasting over the
current internet.

so they built some cool stuff, generated some hype, had a good demo and then
got bought out for $1.3B by inktomi, but then it sort of spiraled down (the
stock price) by a factor of 1000.  the product never went anywhere.

okay, so what..?

so i think the future of internet streaming/broadcasting is something closer
to what move networks is doing (one of drew majors companies:
http://www.movenetworks.com/)

i know this sounds weird, and stupid - but with his protocol you can
actually watch tv over the internet over a standard dsl line.  

yes, saying "i can watch tv on the internet" sounds weird and stupid - but
i've never seen anything like this, and i'm not easily impressed.  check out
the beta: http://byu.tv/  (it requires: windows, iexplorer and a few hundred
kbs of bw)

if you take a few minutes to see the live demo, you'll see the highest
quality broadcast you've ever seen over the internet.  iirc, it's been test
with tens of thousands of concurrent connections, pushing many, many
gigabits of bandwith - so it's not an "oh, that's easy with no load" kind of
thing.

so p2p streaming? (an aside- why p2p? isn't this just bandwidth theft?)
fancy tree structures?  multicast?   not sure about all that...but this is
an existence proof - it works now, and it's just an ingenius, but relatively
simple protocol.

i suppose adding multicast to cooperate networks would enhance it, but the
real problem appears to be in the actual streaming protocol, not improving
the economics of the packets (eg. multicast.)

just sharing. ;-)

-josh


> -----Original Message-----
> From: plug-bounces at plug.org [mailto:plug-bounces at plug.org] On 
> Behalf Of Michael Halcrow
> Sent: Tuesday, January 10, 2006 7:35 AM
> To: Provo Linux Users Group Mailing List
> Subject: Re: Peer-to-peer streaming
> 
> On Mon, Jan 09, 2006 at 04:34:11PM -0700, Michael L Torrie wrote:
> > Months ago there was discussion about peer-to-peer 
> streaming.  I know 
> > Michael Halcrow and others were participating in this discussion.
> 
> After having spent some time reading research papers in a 
> graduate-level networking protocols class, I am absolutely 
> convinced that multicast routing is the best answer to the 
> problem that P2P streaming is attempting to solve. We would 
> do better to focus on overlay networks that implement such 
> features than on these myriad random one-off projects that 
> really constitute a technologically inferior solution (a 
> "hack" or a "kludge").
> 
> For some examples of what you can do with multicast technology, read
> these:
> 
> http://www.acm.org/sigcomm/sigcomm98/tp/paper05.pdf
> http://www.cs.utexas.edu/users/lam/Vita/IEEE/WongLam99.pdf
> http://www.cs.utexas.edu/users/lam/Vita/ACM/WGL98.pdf
> 
> That last paper has been superseded by another scheme that 
> operates more on an subtree-exclusionary basis; I'll have to 
> see if I can't dig up the paper for that. And if you're 
> wondering just how it can be feasible to deploy such sweeping 
> changes on non-overlay networks:
> 
> http://www.acm.org/sigs/sigcomm/sigcomm2005/paper-RatShe.pdf
> 
> Mike
> .___________________________________________________________________.
>                          Michael A. Halcrow                          
>        Security Software Engineer, IBM Linux Technology Center       
> GnuPG Fingerprint: 419C 5B1E 948A FA73 A54C  20F5 DB40 8531 6DCA 8769
> 
> The observation of change is not empirical evidence for a time       
> dimension. It is evidence for change. 
> 




More information about the PLUG mailing list