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

[Jay Beavers]

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
>