Subject: [AVT] Multiple IP address scenarios in a multicast environment

From: "Jay Beavers" <[email-masked]>
Date: Thu, 15 Aug 2002 23:10:34 -0700

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 address,
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
backbone.

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 works
out to 30 * 5 * 1 Mb/s = 150 Mb/s of aggregate traffic, vastly exceeding
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.

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 be
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?)

---

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 50
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 source
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.

---

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

 - jcb

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Tue, 27 Aug 2002 15:09:40 -0400

Comments inline...

>group membership state on a server due to scalability, reliability, and

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

>(associated by a RTCP APP packet perhaps?)

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

>address and lose only the capacity to see A/V streams from the less

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

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

Colin