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

[Darin Oman]

Jonathan,

We currently have custom-built rack-mounted machines that we are about 
to upgrade. We ran into the same problem - only being able to find 
rack-mountable servers. Our solution is to buy regular workstations (in 
our case, Dell Precision 530's and 340's) and place them on 
rack-mountable shelves purchased through racksolutions.com.

Darin


Jonathan C. Humfrey wrote:

>
>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
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/ag-tech/attachments/20020829/10660a4a/attachment-0001.htm>