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

Jay Beavers jbeavers at microsoft.com
Thu Aug 29 10:46:55 CDT 2002

We're using 1394 cameras in addition to analog PCI based capture cards.
1394 cameras have many advantages (integrated power, control, and data
cables; higher quality all-digital signal; lower CPU utilization) and
one of them is that realistically you can fit 3 cameras per PCI slot.
In other work at MSResearch that involve camera arrays, they use 5+ 1394
cameras running at 640x480 and software to create one very large, highly
detailed image that appears as one virtual large video source.  You can
see this in the papers on the 'Ring Camera'.  This isn't ready for
AG-like scenario trials yet, as it's still in early prototype stage.

With the continuing march upwards in PC capacity, I don't foresee
multi-node computers as being required by number or quality of video
streams.  We're quite happy doing multiple capture and multiple render
streams on our dual P-IV workstations today, and we could easily go up
in capacity over 50% by moving from our 1.7 GHz CPUs to 2.8 GHz CPUs
that are now available (and go from 400 MHz dual channel RD-RAM to 533
MHz dual channel RD-RAM at the same time).  We take advantage of the CPU
assist provided by cards like the NVIDIA GeForce and the DirectX Video
Acceleration architecture that is part of DirectShow which allows the
graphics card to offload significant portions of the decoding and

We are using multiple computers per node now for pure logistical
reasons.  We're using one computer to handle all the A/V traffic, a
wireless Tablet PC to drive PowerPoint with ink, and a laptop as the
administrative/diagnostic console.  Our hope is to make the
administrative console needed only for occasional onsite diagnostics
(like adjusting the microphone gain/gating settings for the room) as
operations continues to get simpler.  Our admin console used to be on
the A/V node, but we found it is too disruptive to use to have the
operator run over to the A/V node whenever any adjustments need to be
made ;-)  We're looking at other solutions, like moving the A/V node to
an operations closet or using Mira devices (LCD monitors with Remote
Desktop logic built in) or providing a web-based admin interface
directly on the A/V node to keep the Admin functions integrated on the
A/V node.

We can make signals from multiple computers 'appear' to be from one
logical place by sending signals from the same CName, at least until we
start using SSM and then the IP address becomes important.  I don't have
a clear concept of whether we would ever use the same CName among more
than one computer.  In our scenario, education, we generally give a
'room' CName to the A/V workstation (E.G. MSR-113-1021 at Microsoft.Com)
and use a 'professor' CName (E.G. DrBob at Washington.Edu) for the Tablet
PC and an 'operator' CName (E.G. JBeavers at Microsoft.Com) for the
operator's console.  Strictly speaking, what's a "node" in that design
and what are just "personal" devices?

 - jcb

-----Original Message-----
From: Osland, CD (Chris) [mailto:C.D.Osland at rl.ac.uk] 
Sent: Thursday, August 29, 2002 7:21 AM
To: Jay Beavers; ag-tech at mcs.anl.gov
Subject: RE: [AG-TECH] FW: [AVT] Multiple IP address scenarios in a
multicast environment 

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

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


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'

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