All things related to multicast

[Marshall Eubanks <>]

Hello;

Doron Rajwan wrote:
> 
> Joel,
> 
> >> A server should be prepared to serve any sessions it advertises ...
> Is this true for unicast today?  Can I access ALL the pages in a website,
> and hope that it won't crash?
> 

Things like this should be left to the server...

> Suppose a radio content provider can deliver 100 unicast streams today.
> Using multicast, it can deliver 100 different streams, that can serve a
> large number of audience. Using MSNIP-like protocol, it can select the
> preferred 100 stations to deliver at any given time, from a larger set of
> stations.
> 
> The MSNIP-like protocol, at least in theory, can estimate the number of
> concurrent users. This will allow the content provider to select the optimal

This is not how I read the protocol. It estimates the existence of users, not 
their
number.

We use RTCP receiver reports to estimate audience size. I see no reason
for a _transport layer_ protocol to do this.

Marshall

> streams, or serve these streams in higher quality. Although current
> PIM-SM/SSM does not support it, I suggest to add this capability to the
> MSNIP protocol.
> 
> Doron.
> 
> -----Original Message-----
> From: Joel Jaeggli 
> [mailto:]
> Sent: Saturday, April 07, 2001 12:09 AM
> To: Doron Rajwan
> Cc: Bill Nickless; 
> ;
> ;
>  
> 
> Subject: RE: IPv4 multicast best current practice I-D
> 
> On Wed, 4 Apr 2001, Doron Rajwan wrote:
> 
> >
> > Good work!
> >
> > I would add that in current multicast service model a source cannot know
> if
> > it has listeners or not. This is needed, because it will allow to
> implement
> > sources that advertise, say, all the radio stations in the world, but,
> > transmitting each station only when there are receivers. Such a protocol
> > will save bandwidth from the server to the first hop router, and more
> > important, computing resources inside the server itself.
> 
> With regard to the issue of the first hop router won't an igmp enabled
> device (such as switch) prevent you from hogging the router if there
> aren't any joiners on the other side?
> 
> A server should be prepared to serve any and sessions it advertizes, if
> you have an application which has such low concurency that you're concered
> about cpu use when no-one's joined, I sorta wonder why bother using
> multicast at all.
> 
> > Jon Crowcroft presented this vision a long time ago, and I presented it in
> > the Pittsburgh IETF. Since then, there is a work on two protocols that do
> > it. One of them is draft-ietf-idmr-msnip-00, and the second was not
> > presented yet (Ask Dave Thaler for more information).
> >
> > thanks,
> >   Doron.
> >
> > ____________________________________________________
> > Doron Rajwan, Chief Technology Officer, Bandwiz Inc.
> > 11 Bareket St. Herzlia 46511 Israel
> > mailto:
> > Office: +972-(9)-9515116, ext. 122
> > Fax:    +972-(9)-9515117
> > Cell:   +972-(56)-507799
> > Home:   +972-(3)-6736614

-- 



   Multicast Technologies, Inc.
   10301 Democracy Lane, Suite 410
   Fairfax, Virginia 22030
   Phone : 703-293-9624          Fax     : 703-293-9609     
   e-mail : 

     http://www.on-the-i.com         

 Test your network for multicast : http://www.multicasttech.com/mt/