[AG-TECH] FW: [AVT] Multiple IP address scenarios in a multicast environment

Jay Beavers jbeavers at microsoft.com
Thu Aug 29 00:18:46 CDT 2002

FYI, thought I would forward over this discussion I started on the IETF
AVT mailing list (AVT owns RTP, the transport of AG).

We're looking into enabling browsing of active participants in Venues
that you're interested in but not joined to, as well as thinking about
tiering multicast traffic between 'important' and 'less important'

If anyone on AG-Tech has thoughts in this area, I'd love to hear them.

 - jcb

-----Original Message-----
From: Colin Perkins [mailto:csp at isi.edu] 
Sent: Tuesday, August 27, 2002 12:10 PM
To: Jay Beavers
Cc: avt at ietf.org
Subject: Re: [AVT] Multiple IP address scenarios in a multicast

Comments inline...

--> "Jay Beavers" writes:
>Scenario 1, Who's Talking?
>An application is using RTP over multicast UDP on an IPv4, IGMPv2
>network.  When a client subscribes to a multicast group address using
>IGMPv2, the client receives all traffic on that multicast group
>including all RTP and RTCP traffic, regardless of sender or port.
>The client application can join any one of 30 available multicast group
>addresses.  The list of possible multicast group addresses and their
>associated details is obtained via a unicast query once at the start of
>the client application.  The client wants to get some information about
>who is in each multicast group, preferably by receiving the RTCP SDES
>traffic from each multicast group on port 5005.
>For discussion sake, there are five clients in each multicast group,
>each client sending 1 Mb/s of RTP traffic.  Each client is assumed to
>have at least 10 Mb/s of quality connectivity to an unloaded network
>Problem 1:
>If the client application sends a multicast group address join request
>for all 30 multicast group addresses, they will receive the RTCP SDES
>traffic, but also the RTP traffic from each multicast group.  This
>out to 30 * 5 * 1 Mb/s = 150 Mb/s of aggregate traffic, vastly
>the 10 Mb/s client network capacity.
>Potential Solution 1:
>Are there any thoughts about how to approach this?  I hesitate to load
>group membership state on a server due to scalability, reliability, and
>stale data concerns.

Valid concerns. If you did choose this approach, a well connected group
member could listen to the RTCP and allow SNMP queries (the RTP MIB can
provide SDES information).

>Source Specific Multicast wouldn't solve this, as I would need to
>subscribe to all sources to receive their RTCP traffic which would also
>bring down their RTP traffic unless RTP and RTCP were separated onto
>separate IP addresses.  I've also wondered if RTCP SDES traffic could
>duplicated to one shared multicast group address, the problem being
>knowing which SSRCs are associated with which multicast group addresses
>(associated by a RTCP APP packet perhaps?)

Or use two multicast groups per session, one for the data and one for

>Scenario 2, We're All Equal, But Some Are More Equal Than Others:
>The same application is running, but the number of participants has
>increased, perhaps because the conversations are using a lecture or
>panel discussion model.  Now we have a few (5?) important clients and
>less important clients.
>It's decided that the important clients should continue sending the 1
>Mb/s of data.  Less important clients can send an occasional (every 30
>seconds) high resolution snapshot as well as 100 kb/s of A/V streams.
>If all data is sent over one multicast group address, the aggregate
>network bandwidth is 5 * 1 Mb/s + 50 * 100 kb/s = 10 Mb/s, severely
>stretching the network capacity of the clients.  The clients would
>prefer to receive the streams for important clients and the snapshots
>for less important clients.  Optionally, the 100 kb/s streams from the
>less important clients would be enabled on a stream by stream basis.
>Problem 2:
>Source Specific Multicast has some relevance here, as it could be used
>to subscribe to a subset of the less important client A/V streams.
>However, the client would still want to receive RTCP and snapshot
>information from all clients.
>Potential Solution 2:
>Traffic could be broken into two multicast group addresses again, with
>unfiltered traffic (RTCP, RTP snapshots) being on one address and
>filtered traffic (RTP A/V streams) being on a separate address.  This
>would also allow IGMPv2 networks to work, as clients on that network
>could subscribe to only the traffic on the unfiltered multicast group
>address and lose only the capacity to see A/V streams from the less
>important clients.

You could also run two RTP sessions, one for the "important" clients,
one for the rest, each with their own RTCP. The CNAME fields would let
relate participants between the sessions.

>In both these cases, the solution involves sending RTCP on a separate
>address from its associated RTP streams, which certainly isn't
>in RFC 1889 anywhere.  Any other thoughts on how to approach these

See above. I don't have strong objections to sending RTCP on a separate
multicast group to the associated RTP, in the first example.


More information about the ag-tech mailing list