[AG-TECH] Venue, what art thou? (was: Mapping IP addresses to Venues)

[Jay Beavers]

Sounds good.  In my mind, this works out to a clean separatation between the 'virtual space' and the 'community of people and associated content'.
 
If you think of venues as simply 'the place we get together to meet', then the 'permanent' mapping of IP addresses to them is reasonable and efficient because a community can choose any one of a number of venues to meet in at a given time based on the availability of the venue.
 
In physical implementation, this breaks down pretty well into the technology that exists today:
 
Virtual Venue:

*	Statically allocated multicast IP address
*	Dedicated 'chat' space
*	Some 'color' (AKA name, maybe even a 'background' graphic)
*	Calendar of availability / ability to schedule for use by a community

Community:

*	A set of shared persistent content that has events, lists, documents, discussions, contacts, etc.
*	A group of people and some way to determine their online/availability status to facilitate ad hoc discussions between scheduled events

This breaks down effectively into how the 'real world' works, whether it's my team at Microsoft who works around a web portal with IM most of the time but who 'gets together' in a conference room / phone conference / virtual meeting every once in a while or whether it's a class at the local university that has a web site for class information that meets in 412 Sieg Hall on a scheduled basis.

---

Based on this approach, I don't see an issue with statically allocating multicast addresses to venues as long as we keep separated the concept that venues (shared temporal resource) and communities (private persistent resource) are different ducks.  We even have implementations of these two things today in the AG Virtual Venue server and a plethora of web portal / group interaction solutions.  What we haven't done to date is implement any links or logic between them to make the use of these different technologies coherent.  One advantage to this approach is that with decent published APIs at the Virtual Venue layer, groups can improve their Community implementation (AKA portal software, online messaging) independently of the venue implementation.

An interesting argument could be made that based on this definition, Venues are 'trivial' and could be simplified to 'just an IP address' and some form of dynamic allocation similar to how DHCP hands out unicast IPs could be used (a protocol even exists for this, MADCAP).  The dedicated chat space could be associated with Communities, the 'color' isn't needed, and an availability calendar wouldn't be necessary assuming dynamic allocation and sufficient static IP addresses that you never have to worry about being 'all out'.

I've thought about this a while myself and am heavily leaning towards leaving Venues as 'more than an IP address, but not a Community' because it is analogous to our 'real world' interactions.  It also provides us a building place to innovate on advanced collaboration concepts such as representing virtual avatars in 3D, spatializing audio, etc. that would be that much harder to implement if we had to drag along all the 'traditional' persistent content into the 3D world.  We can continue to think of a Venue as a place where we optimize group synchronous interaction, whereas a Community continues to be a place where people are working to optimize the asynchronous interaction / workflow of teams.  Besides, it just feels 'more right' to say 'let's meet in the Sporkin room at 10 AM' rather than to say 'let's get together for a virtual team meeting at 10 AM' ;-)

This also leaves us a 'unique AG feature' that other group interaction projects don't have, giving us an ability to distinguish AG as the best in synchronous collaboration while still taking advantage of the Community implementations like Groove or Sharepoint or Notes, etc.  If we combine the two, yes we'll have a much better synchronous interaction than any of the web portal applications, but we'll undoubtably have a poorer asynchronous interaction, casting a pall upon the project and limiting its widespread adoption potential.

	-----Original Message----- 
	From: Ivan Judson [mailto:judson at mcs.anl.gov] 
	Sent: Thu 3/21/2002 11:05 PM 
	To: Robert Olson 
	Cc: Jay Beavers; ag-tech at mcs.anl.gov 
	Subject: RE: [AG-TECH] Mapping IP addresses to Venues
	
	


	I think what this conversation leads to is the requirement that address
	allocation have a well defined interface.  We need to define it now, and
	use it to shield ourselves from the coming wave of new technology
	that might tempt us into implementing new functionality that gives us
	greater freedom (why does that sound so good? :-).
	
	One scheme involves not binding data to addresses permanently, but rather
	allocating addresses on a "as needed" basis.  Venues persist, the stuff in
	them persist, but the paths for data between peers are created when there
	are peers and destroyed when peers are not present.
	
	Then a virtual network layer (we don't care how it does it, just that it
	does it well) provides connectivity among peers.  This leads to some very
	interesting possibilities for network solutions to things like bridging,
	asymmetric network paths, multicast issues, etc.
	
	--Ivan
	
	
	On Thu, 21 Mar 2002, Robert Olson wrote:
	
	> At 08:31 PM 3/21/2002 -0800, Jay Beavers wrote:
	> >An example would be the deployment of AG nodes for virtual classrooms
	> >throughout a major state university system.  This could add up to hundreds
	> >of venues in use simultaneously fairly easily.
	>
	> Each school with an AS number has 256 GLOP addresses at its disposal; that
	> alone will probably suit their needs for some time, if carefully allocated.
	>
	> Tho we gotta wonder what's up with 225/4 thru 231/4 and 234/4 thru 238/4...
	> marked "reserved" in rfc 3171.No lack of addresses in there.. :-)
	>
	> --bob