All things related to multicast

["Marshall Eubanks" <>]

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