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

[Ivan R. Judson]

While I agree with Jay that Moore's Law means we're going to get more
and more cool stuff in less space, I have to voice a different opinion:

I foresee people wanting to any number of things with AG Nodes and they
shouldn't be constrained by *any* assumptions we make now about # of
computers or # of streams, or capabilities.

That being said, I don't necessarily see anything that Jay says below
concretely disallowing that, just a premonition of disallowing it :-)

--Ivan

..........
Ivan R. Judson .~. http://www.mcs.anl.gov/~judson
Futures Laboratory .~.  630 252 0920
Argonne National Laboratory .~. 630 252 6424 Fax
 

> -----Original Message-----
> From: owner-ag-tech at mcs.anl.gov 
> [mailto:owner-ag-tech at mcs.anl.gov] On Behalf Of Jay Beavers
> Sent: Thursday, August 29, 2002 10:47 AM
> To: Osland, CD (Chris) ; ag-tech at mcs.anl.gov
> Subject: RE: [AG-TECH] FW: [AVT] Multiple IP address 
> scenarios in a multicast environment 
> 
> 
> 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 rendering.
> 
> 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 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
>