All things related to multicast

[Marshall Eubanks <>]

Dear Richard;

Richard Mavrogeanes wrote:

> Folks,
>
> The VBrick can be configured to join its own multicast, and this
> is the default configuration.  This is because certain poorly designed
> switches flood (cgmp) if there is not at least one client listening to
> the multicast.  The feature can be disabled.
>

But it should not cause problems if properly implemented.


>
> I believe Tuesday's event was one of the largest multicast events, and
> there were many people showing our video on the floor at N+I in Atlanta
> via I2 multicast.
>

I agree that Tuesday was one of the largest multicast events, and in a sad 
way a
real plus for multicast. See
http://imj.ucsb.edu/mantra/session-mon/session-mon.html
for evidence of the size of the audience increases this weekend.

However, we also had a big burst in audience, and only one was from
interop.net. I think that the traffic burst was from  people from all over
the place wanting news once conventional websites and streaming sites melted 
down.



>
> I would certainly like to receive some evidence that this is true, and
> if anyone can assist me in this regard, please feel free to contact me.
>

I think that the Mantra plots are pretty powerful evidence in that regard.


>
> Best Regards,
>
> Rich Mavrogeanes
> Founder/President
> VBrick Systems, Inc.
> 1-203-303-0200
>

                                 Regards
                                 Marshall Eubanks



T.M. Eubanks
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/
 Check the status of multicast in real time :
 http://www.multicasttech.com/status/index.html



>
> > -----Original Message-----
> > From: Marshall Eubanks 
> > [mailto:]
> > Sent: Tuesday, September 11, 2001 9:41 PM
> > To: 
> > ;
> >  
> > ;
> > ;
> > ;
> >  
> > ;
> > 
> > Subject: Re: your mail
> >
> >
> > >> assumption: these floods were in fact result of 
> > >> cnn@nwu
> > >>  session.
> > >>
> > >> open problem: what shall be a valid threshold (relative or
> > absolute) that
> >
> > >> can distinguish genuine SA's from malicious/erroneous
> > floods? is using
> > >> threshold as a flood-diagnosis mechanism good approach at all?
> > >>
> > >> observation #1: unlike msdp-storm that was induced by
> > ramen worm, the SA's
> >
> > >> were being generated for multiple sources today. however,
> > all these SA's
> >
> > >> were for the same multicast 
> > >> group--cnn@nwu
> > >>  session.
> > >>
> > >> observation #2: all these SA's were for participant-hosts
> > that were not
> > >> sending data at a rate greater than 4kbps. thus, it seems,
> > all the traffic
> >
> > >> that they were sourcing was control traffic (RTCP??).
> > >
> > >yes, it would appear to be so. i didn't realize that the
> > vbrick clients
> > >would become sources (albeit small) on the session. i'm not even sure
> > >what the clients are doing, but we'll definitely be asking
> > vbrick about
> > >it. however, i found them to be handy to track the number of viewers
> > >at any given point in time. (i haven't processed that data fully yet,
> > >but there were approximately ~300 clients at one given point
> > during the day.)
> >
> >
> > If so, then this was one of the bigger simultaneous multicast
> > audiences so far.
> >
> >
> > This sounds to me like that things are actually working
> > correctly. The MSDP
> > messages are presumably being generated by the Receiver
> > Reports (RR) being sent
> > by receivers.
> >
> > The normal procedure of course would be for each receiver to
> > send RTCP RR messages,
> > at a rate based on the size of the group.
> > (Apple Quicktime does this correctly in OS 9, but apparently
> > not in OS X, for example. Cisco IPTV also does this correctly.)
> > Each receiver serves as a source, which will cause the
> > generation of MSDP messages.
> > (Another good reason to move to SSM, which gets rid of all of this.)
> >
> > Note that the MSDP rate is NOT dependent of the rate of
> > Receiver Reports, which
> > is limited by the protocol.
> >
> > I will have to look through our logs and see if this
> > explaination holds up.
> >
> > Marshall
> >
> > >
> > >
> >
> > Marshall Eubanks
> >
> > 
> >




--