All things related to multicast

["Hugo Santos" <>]

Hi Tim,

  (Sorry to be replying again, this time we'll see if my mail reaches
wg-multicast).

On 9/29/07, Tim Chown 
<>
 wrote:
> One thing I noticed with dbeacon is that it does generate a lot of
> traffic, and thus a big matrix might not be prudent.   I've been meaning
> to dig a little deeper into that but not had time, perhaps someone
> else can comment from experience on dbeacon's scalability?

 Someone was asking in the m6bone mailing whether 3gb of dbeacon data
per month is expected. I replied the following:

  ``Whether it is expected or not is hard for me to say. Dbeacon
currently scales the report/probe sending events based on incoming
traffic, but it does so logarithmically. If we have a lot of sources,
a lot of traffic is generated.

 3 Gbytes = 3,000,000,000 bytes
 for 60 * 60 * 24 * 30 = 2592000 seconds per month.

 That's 1157.4 bytes/s. If we have 30 sources, that's each source
generating an average of 38.6 bytes/s, or 304 bits/s.

 Maybe it is too much. The dbeacon scaling function could be tuned.
Right now the interval between probes (a burst of 10 probes) is on
average:

 (4 * log(bytesReceived * 8 / 10000) / 1.38) seconds.

 Where bytesReceived is the number of bytes processed by dbeacon in
the last 10 seconds.''

  Another thing that could be tuned is the probe burst length (which
is right 10 packets). The decision behind that was to try and measure
the loss and jitter at that point in time. This could also be reduced
to a single probe.

  I hope this helps understanding dbeacon's scalability better.

  Hugo