Virtual Venue Address Plan

Michael E. Papka papka at mcs.anl.gov
Mon Feb 10 14:25:24 CST 2003


Ok there is several typo's below, sorry ....

Typo in my correction to Ivan ..... "are neither"

And the summary of my view on address allocation is that it should be the
users choice static or dynamic .....

 Mike

-----Original Message-----
From: owner-ag-dev at mcs.anl.gov [mailto:owner-ag-dev at mcs.anl.gov] On Behalf
Of Michael E. Papka
Sent: Monday, February 10, 2003 2:22 PM
To: judson at mcs.anl.gov; 'AG Dev'
Subject: RE: Virtual Venue Address Plan


I think "and events like SCGlobal aren't either hindered, or" should be "and
events like SCGlobal aren't neither hindered, nor"

Technically this seems like a bandaid at first glance, should a venue have
its choice on how to manage its multicast addresses? If a site hosting a
venue wants to statically allocate from its pool of addresses its their
choice. Seems like we should offer both in the system. My two cents.


Mike

-----Original Message-----
From: owner-ag-dev at mcs.anl.gov [mailto:owner-ag-dev at mcs.anl.gov] On Behalf
Of Ivan R. Judson
Sent: Monday, February 10, 2003 1:58 PM
To: 'AG Dev'
Subject: Virtual Venue Address Plan



Howdy all,

I promised a plan, but here is a bit more than that.  I'm going to describe
the problems and put forth a solution. 

The problem we have is the following:

- AG 1.0 used statically assigned multicast addresses for the media (e.g.
one address for video and one address for audio).

- There has been some work at making sure this set of addresses work,
including various firewall, bridge, and tunneling solutions.

- AG 2.0 uses dynamically assigned addresses for media. We'd like to keep
the 2.0 toolkit from being overly burdened by the design constraints in 1.0.

- We can't support infinite backwards compatibility , but want to backward
compatibility enough for users to comfortably transition (we don't want to
abandon the community!)

- We're moving to dynamic addressing, but before we can do entirely dynamic
address allocation we need to ensure the basic services are fault tolerant
and robust enough to handle the problems associated with network brokenness.

- During the transition we need the right solution so the community can
transition comfortably from AG1.0 to AG2.0 and events like SCGlobal aren't
either hindered, or have success threatened by the software evolution.

So, what do we do?  Other folks with ideas should feel free to contribute
them, but I recognize it might be hard to contribute an idea after only a
week of alpha --

1) AG2 will incorporate functionality to statically configure a Virtual
Venue with audio and video media streams. These statically configured
streams are AG1 compliant streams (ie, H.261 video or 16bit, 16KHz
uncompressed audio). This will be available as soon as we (or someone else)
has time to implement it.

2) We will host a transitional AG2 Venue Server that is initialized with the
AG1 venues (same name, description, and media streams) so that AG2 users can
collaborate with AG1 users. We will not transition venues that have *never*
been used.

3) We will transition over time, along the following event timeline:
	- On or near September 15th we'll turn off the existing Virtual
Venue Server
	- On or near November 31st, we'll stop supporting the transitional
server.

If there are any questions or concerns, please don't hesitate to send email
to ag-tech.

--Ivan




More information about the ag-dev mailing list