[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