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

[Jonathan C. Humfrey]

Thanks Jay,

Our issue here is that we would like to create a node that is
portable.  We know we can do this with two machines but would like to
rackmount everything, do you know if the Dells can be rackmounted? 

Jonathan

On Thu, 29 Aug 2002, Jay Beavers wrote:

> We're just using standard tower workstations -- a Dell Precision 530 for
> instance.  For smaller environments, I'm using the smaller form factor
> PCs like the mini configuration Precision 340.  The holdup there has
> been the lack of a good half height AGP video card with multiple video
> outs.
> 
> I've finally got a hold of a half height AGP NVIDIA Quadro4 NVS 200
> which drives two displays.  If you're doing small nodes (1-3 cameras,
> 1-2 displays), the combination of a Precision 340 with the Quadro4 would
> be great -- 2'x2'x4".  For most AG node scenarios though, I'd stick with
> the Precision 530.
> 
> We've been trying out laptop portable nodes, but we're still faced with
> three problems:
> 
>  * Laptops come with 1394, but without power so a clunky external 1394
> powered hub with power adapter is needed, or we have to stick with 1 USB
> camera (Logitech QuickCam Pro 3000)
>  * Pushing large amounts of multicast over wireless 802.11a has failed
> on our first set of 802.11a equipment (Proxim Harmony).  802.11b is
> working OK, but isn't a scalable solution.
>  * A Gentner XAP-400 et al is a little hard to move around ;-) and the
> ClearOne didn't work well enough to replace it.
> 
> The first two aren't showstoppers for laptop deployments, but the third
> is.
> 
>  - jcb
> 
> -----Original Message-----
> From: Jonathan C. Humfrey [mailto:jch at cs.ucsb.edu] 
> Sent: Thursday, August 29, 2002 9:02 AM
> To: Jay Beavers
> Cc: Osland, CD (Chris) ; ag-tech at mcs.anl.gov
> Subject: RE: [AG-TECH] FW: [AVT] Multiple IP address scenarios in a
> multicast environment 
> 
> 
> 
> Jay,
> 
> Can you tell me what the exact setup of your display machine is?  Are
> they
> rackmount?  I have had a real problem with our display machine which
> uses
> a SuperMicro motherboard made for a server and we end up getting a lot
> of
> loss in the rendering process... we're looking for a rackmount dual
> processor machine that will render much more effectively.  Any
> suggestions?
> 
> Jonathan
> 
> On Thu, 29 Aug 2002, Jay Beavers wrote:
> 
> > 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
> > 
> 
>