All things related to multicast

["Marshall Eubanks" <>]

On Tue, 11 Oct 2005 19:40:27 -0400
 "Richard Mavrogeanes" 
<>
 wrote:
> I continue to think that widespread multicast will occur when it solves an 
> obvious, current
> problem and not a future "if you build it they will come" problem. Most 
> ISP's don't yet suffer
> from the problem multicast can solve, and local IT staff simply don't see 
> the issue. You know,
> "when you are a hammer, the whole world looks like a nail" and they 
> engineer unicast solutions
> (or filters!) to control popular traffic.
>  
> You can do virtually everthing multicast can do via conventional 
> unicast...but you can't get
> unicast to scale the way you can with multicast...but you don't need 
> multicast scale until it is
> obvious that you need it (unfortunately).
>  
> I think the unicast rollover described in the attached has value and that 
> it can address the
> issue of dependable service to drive the bandwidth consumption that 
> multicast can ultimately
> solve.  I can see the ISP and/or IT staff saying "we've got to do something 
> about all these
> idential packets going to 1,000 users", and I wonder if rollover with 
> multicast bias is at least
> "an" answer.

I think that this is the power behind AMT and similar auto-tunnel works. This 
will be
provide transparent roll-over. However, it's not just AMT, it's

SSM / IGMPv3 support in OS kernels
SSM / IGMPv3 support in video players and other edge receivers
SSM / IGMPv3 support in snooping switches
a really robust interdomain multicast routing infrastructure, that, once you 
get it working, stays
that way 

I could use this right now, today. Unfortunately, I think  we are looking at 
2-5 years.

Regards
Marshall

>  
> Please don't flame me...I don't offer this as an advertisement but for the 
> opinion and thoughts
> of this august body :)  Rollover thas been around for awhile but I don't 
> recall seeing a
> discussion here...
>  
> rich
>