I think the Multicast discussion should continue, however it is a different topic than mobility. Therefore and because I once launched "MIP in a future routing architecture" I suggest to continue the discussion using above headline. Also: the MIP- discussion might go on by using the unmodified headline Heiner In einer eMail vom 29.11.2009 21:05:57 Westeuropäische Normalzeit schreibt [email protected]:
Hi Shane, > for 'live' content, given the inherent efficiency of multicast. I am not questioning the efficiency of multicast. In fact I am looking at peercasting and can't find it's inefficiencies either provided it is deployed in a proper manner. I am not talking about residential hosts replicating the live content. But if you place your peercasting servers in the key network locations I could argue that peercasting can be as efficient as multicast both in core as well as distribution levels. The difference between the two is just the way such distribution tree is constructed. In multicast you have protocol which in most cases (not talking about p2mp te) follows the unicast routing to reach the src. On the other hand in peercasting you can use many other elements like RTT, feedback from ALTO servers, routing proximity, sources load etc ... for the tree building decision which may be hard to do by multicast. While you are right that for live streaming multicast may be the winner there is IMHO much bigger market for on demand file, video,audio streaming where caching may be of huge importance. And I guess this is very clear that hosts/servers are much better in content caching then routers. Cheers, R. > Robert, > > On Nov 29, 2009, at 03:48 MST, Robert Raszuk wrote: >> Tony, >> >> Isn't it a case that multicasting has been already obsoleted in the >> quite significant degree by peercasting ? >> >> http://www.viswiki.com/en/Peercasting > > IMHO, I think it's rather difficult to predict that peercasting > has/will obsolete multicast, at least in the U.S. and, specifically, > for truly "live" content, e.g.: sports, news broadcasts, etc. > Unfortunately, the usual chicken-and-egg problem exists: no widely > appealing, legitimate content exists, therefore there is no demand, > hence very few SP's set-up their infrastructure to provide multicast > down to CE devices. However, with the dearth of *unicast* > time/place-shifted video content coming online by the major players > (cf: Hulu, Apple, Netflix, Blockbuster, etc.), it may be a matter of > time, before we start to see a growing demand for *multicast* video > for 'live' content, given the inherent efficiency of multicast. > > Furthermore, while peercasting is an intriguing application-level > form of multicast, (therefore, allowing a content owner/distributor > more control over when & how they distribute their content w/out > having to wait for the network to be ready), it's not without it's > "challenges", specifically: - asymmetric BW on residential access > circuits, making it difficult to hairpin/push content back up into > the network; - lack of some form of CoS on lower bit-rate residential > lines to either: a) assist with pushing hair-pinned content back up > into the network; and/or, b) avoid interfering with other legitimate > apps on the access circuit, (e.g.: VoIP, etc.) - etc. > > I guess time will tell. > > -shane > > > >> And I am not that convinced that replication at network >> router/switch level is that much more efficient then replication at >> the network host level. I think it is just a matter of efficiently >> determining the optimal replication points. >> >> Cheers, R. >> >>> Dino Farinacci wrote: >>>> Well if multicast proper is not on the requirements for scaling >>>> the routing architecture, how can we set our sights higher? >>>> >>>> Do you expect multicast route scaling to be solved in some >>>> other forum like perhaps SAMRG? >>> I think you can just work on it. No permission is required. But >>> first you should take this up with the guys who have been working >>> on multicast for the last 17 years. ;-) Seriously tho, if that's >>> a useful work item, the RG can take it up after this work item >>> is complete. Tony _______________________________________________ >>> rrg mailing list [email protected] >>> http://www.irtf.org/mailman/listinfo/rrg >> _______________________________________________ rrg mailing list >> [email protected] http://www.irtf.org/mailman/listinfo/rrg > > > _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
