[AG-TECH] FW: [AVT] Multiple IP address scenarios in a multicast environment
Matthew Wolf
mwolf at cc.gatech.edu
Thu Aug 29 19:49:26 CDT 2002
Ah, Ivan beat me to it, and he said it more sucinctly than I probably
would have managed.
But here's a particular usage scenario that I think is relevant. Sony's
already come out with a version of their PTZ camera which has an
embedded processor that does http out the back end. I think we may be
fast approaching the day where we can do vic straight off the camera,
which means we can skip the capture computer entirely.
This opens up all sorts of intersting applications and makes
installation and setup much friendlier. (No more XLR cables!!!) But
it definitely stretches the node definition to more than just a fixed 3
IP addresses.
Just my two cents...
Matt
"Ivan R. Judson" wrote:
>
> 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
> >
--
-- Matthew Wolf
-- Research Scientist, IHPC Laboratory
-- College of Computing, Georgia Tech
-- mwolf at cc.gatech.edu
More information about the ag-tech
mailing list