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

[Jonathan C. Humfrey]

Yes I'm very interested.  Please let me know if you can track down the
info.  In the meantime I am waiting to hear back from our Dell rep.

Thanks,
Jonathan

On Thu, 29 Aug 2002, Matthew Wolf wrote:

> Dell pointed me at a company that makes a special rack-mountable drawer
> for their mini-tower 340's.  I can dig up the reference if you're
> interested.  The company evidently does most of the add-ons for Dell
> racks -- the same people made the shelves that I was buying.  So you may
> be able to get the info from your local Dell rep, too.
> 
> Matt
> 
> "Jonathan C. Humfrey" wrote:
> > 
> > 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
> > > >
> > >
> > >
> 
> -- 
>                                         
>         -- Matthew Wolf 
>         -- Research Scientist, IHPC Laboratory
>         -- College of Computing, Georgia Tech
>         -- mwolf at cc.gatech.edu
>