All things related to multicast

[Hitoshi Asaeda <>]

Leonard,

> I think you hit the nail on the head here regarding SAP.  I think what you 
> see here in mcast is similiar to the evolution of unicast content.  In the 
> beginning, there was no tool to find and organize web pages.  Yahoo 
> started out as a few students posting a list of their favorite web pages.  
> This list got too long and unwieldy and gradually evolved a search engine.  
> Today, with portals and tools like Google, we have very efficient ways to 
> discover unicast content.
> 
> I think mcast will eventually have to follow this model.  While SAP is a 
> nice and simple tool to discover content, it simply won't scale to the day 
> when millions of mcast streams are available (yes, this is a very 
> optimistic vision given where we are today, but I still think it's 
> possible).

I agree.

>  We couldn't imagine a web page today that carried a list of 
> all the unicast content available.
> 
> In any event, if we can rely on Google to find unicast content, I see no 
> reason why we couldn't rely on it to find mcast content.

Because multicast applications and services are more "dynamic".
It is in general difficult for such web crawling to look for all
available live streaming contents over the entire Internet within a
very short period (e.g. 1 min or so). (SAP can do for this point.)
In addition, IP multicast needs to define and control "scope", while a
search engine that relies on a central (or logically central) server
cannot.
--
Hitoshi Asaeda