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

[Osland, CD (Chris)]

It may not be relevant (I'm not in any sense a network type person)
but I foresee a requirement for more than one capture computer to
be regarded as part of a single node.  There are already times when
I would like to put out more than 4 video streams, and I also want
to start to use higher bandwidth links (e.g. 640x480, 800x600 and
1024x768 off computers).  There aren't many motherboards with more
than 6 PCI slots, and with one gone on networking, a second video
capture computer that appeared seamlessly in the venue would be a
bonus.

I don't know whether this requires what you are discussing; if it
doesn't, please ignore!

Cheers

Chris Osland

____________________________________________________________________
Chris Osland                         Office tel: +44 (0) 1235 446565
Digital Media and Access Grid      Medialab tel: +44 (0) 1235 446459
BIT Department             Access Grid room tel: +44 (0) 1235 445666
e-mail:   C.D.Osland at rl.ac.uk               Fax: +44 (0) 1235 445597

CLRC Rutherford Appleton Laboratory (Bldg. R18)
Chilton, DIDCOT, Oxon OX11 0QX, UK

[The contents of this email are confidential and 
are for the use of the intended recipient only.
If you are not the intended recipient do not take 
any action on it or show it to anyone else,
but return this email to the sender and delete your copy of it.]





-----Original Message-----
From: Jay Beavers [mailto:jbeavers at microsoft.com]
Sent: 29 August 2002 06:19
To: ag-tech at mcs.anl.gov
Subject: [AG-TECH] FW: [AVT] Multiple IP address scenarios in a
multicast environment 


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

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
environment 

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

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

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

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

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

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