All things related to multicast

[Richard Mavrogeanes <>]

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.

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 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.

Best Regards,

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



> -----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
> 
> 
>