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

Thu Aug 29 12:15:04 CDT 2002

I get excellent image quality from the Logitech.  However, I'm using
Windows XP, Directshow capture interfaces, and Windows Media
compressors/decompressors with the ConferenceXP software, so there's a
lot of variance between software implementations.

-----Original Message-----
From: Darin Oman [mailto:darin at ucar.edu] 
Sent: Thursday, August 29, 2002 10:02 AM
To: Jay Beavers
Cc: ag-tech at mcs.anl.gov
Subject: Re: [AG-TECH] FW: [AVT] Multiple IP address scenarios in a
multicast environment

Jay,

Just curious - on your PIG with the USB camera, are you having the
problem that I and others have been having with the bluish tint?

Darin Oman
NCAR

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 SuperM
icro 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 <mailto:ag-tech at mcs.anl.gov> 
	-tech at mcs.anl.gov <mailto: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/cb080898/attachment-0001.htm>