[AG-TECH] Multicast beacon questions

Bill Nickless nickless at mcs.anl.gov
Fri Oct 26 11:55:17 CDT 2001


In practice I actually do rely on the 10 pps for debugging.  When I run 
this command on my router:

   show ip mroute 233.2.171.1 count

I get output like this (truncated for readability)

   Source: 207.75.164.88/32, Forwarding: 3153078/9/91/6, Other: 12/0/0
   Source: 210.25.130.194/32, Forwarding: 0/0/0/0, Other: 0/0/0
   Source: 210.25.133.24/32, Forwarding: 402942/7/88/5, Other: 11/0/0
   Source: 216.47.159.225/32, Forwarding: 147026/6/89/5, Other: 2/0/0

The second item in the Forwarding: section is the packets per second.  As 
you can immediately see in the example above, the 207.75.164.88 source is 
being received at 9 pps, which is a good sign.  Source 210.25.130.194 is 
broken, not receiving anything.  Sources 210.25.133.24 and 216.47.159.225 
are showing less than 9 pps, which tell me that there is loss in the path.

The RTCP aggregate bandwidth management schemes assume that all sources can 
receive traffic from all other sources so as to properly scale their own 
bandwidth usage.  In theory this is a good idea.  Take a look at the beacon 
webpage to see if that's a good idea in practice (at this time).

At 09:06 AM 10/26/2001 +0100, Chris Greenhalgh wrote:
>I gather there are at least three candidate mechanisms for RTCP
>aggregate bandwidth management (scaling each sender's rate so
>that the total of all senders is bounded; in RTP/RTCP this is to some
>fraction of the total data traffic). This would seem an obvious place to
>look, as long as noone is relying on '10pps' as a magic number
>
>Chris Greenhalgh

===
Bill Nickless    http://www.mcs.anl.gov/people/nickless      +1 630 252 7390
PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7     nickless at mcs.anl.gov




More information about the ag-tech mailing list