Subject: Re: Template and bibliography for confctrl BOF

From: schooler
Date: Tue, 23 Mar 1993 00:20:31 -0800

To foster wider discussion, I am forwarding to rem-conf some ideas
that already have been posted to the confctrl mailing list.

The first session of the Conference Control BOF at the upcoming IETF
will be used for several presentations on different confctrl schemes.
The emphasis will be on fleshing out design assumptions, tradeoffs,
complexity, scalability etc.

Below is a draft template to be used as a guideline for these 
presentations.  Answers to the template are intended to help define what 
confctrl is and to help understand the functional requirements of a generic 
confctrl protocol.  I would like us to end up with a healthy cross
section of confctrl approaches, plus specifics on design choices.

Please comment on the template.  Are there questions that should be 
reworded, added, removed?   

If you have implemented an existing teleconferencing system, 
application or protocol, I would especially appreciate it if you
would fill in the template (or your improved version of the template);  
short of that, please suggest a couple papers that capture the essence 
of your work -- as it relates to conference control.

I am also interested in identifying projects that have been
influential or seminal in this area.  Please forward me any ideas you
might have, otherwise you will end up with my own biased opinions :-)
On a related note, I have started a bibliography/recommended reading
list on confctrl, so I am interested in references to your favorite
readings.

Eve

~~~~~~~~~~~~~~~~~~~

		    Conference Control BOF Template
		    -------------------------------

1. Name of project, program and/or protocol.

2. Contact person, affiliation and e-mail address.

3. Target operating environment and key design considerations:

   - WAN vs LAN 
   - digital vs analog media
   - the kinds of collaborative media used in your system 
     (e.g., real-time audio, video, animations, landsat images) 
   - packet technology vs ISDN
   - room-to-room vs desktop conferencing
   - ???

4.a Type of conference styles supported by your system/protocol.

4.b Profile of user community: 

   - expertise level 
   - formality of meetings
   - demand for quality of service
   - mechanisms for scheduling/reservation of system

5. Architecture assumptions: 

   - distributed vs centralized model vs hierarchical
   - system component(s) responsible for conference control
   - degree of homogeneity in end-system capabilities 
   - multicast integration
   - directory services
   - support for quality of service
   - open vs closed membership (e.g., only preregistered users)
   - ???

6.a How do you define conference control?  

6.b Conference control functionality supported.

6.c Other control functions you would like to support.

7. Conference control protocol details: 

  - explicit vs implicit setup
  - interconnectivity of participants
  - state sharing
  - robustness
  - scaling properties
  - ???

8. Hardware/software platforms.  

9.a What specifically has or has not been implemented?

9.b What was unexpectedly easy or difficult to implement?

9.c What might you change as a result?

10. If available, suggested readings about your work on confctrl.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Example ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1. Name of project, program and/or protocol.

	Multimedia Conference Control program (MMCC),
	Conference Control Protocol (CCP)

2. Contact person, affiliation and e-mail address.

	Eve Schooler, USC/Information Sciences Institute, 
	Multimedia Conferencing Project,
	[email-masked]

3. Target operating environment and key design considerations:

	Focus has been on WAN teleconferencing.  All media packetized; 
	couples digital packet audio and video with shared workspaces.  
	Originally used in room-to-room conferencing over DSInet, more 
	recently re-oriented for personal desktop conferencing across 
	DARTnet and MBONE.  Operational testbeds, thus high premium 
	on reliability and fault tolerance.  

4.a Type of conference styles supported by your system/protocol.

	Supports small-sized conferences (ideal for 2-5 members, but
	the control model probably suitable for 10's of members).

4.b Profile of user community: 

	Novice user community over DSInet; conference operators
	typically orchestrate sessions via remote control.  Tends toward
	more formal meetings, ever since became more production-
	oriented.  Concern about system robustness and quality (resolution) 
	of media.  Probably some concern over openness or security 
	of system.

	DARTnet and MBONE comprised of users who are researchers and 
	willing to use software in a more impromptu fashion.  Extremely
	informal usage.  Happy to have access to whatever software and 
	bandwidth available.

5. Architecture assumptions: 

	Distributed, peer-to-peer model.  A single connection manager
	or conference control element resides at each end system.  It
	is responsible for a particular user, at a particular machine
	and port number.  It interacts with underlying media agents
	that handle the specifics for the various media types (e.g.,
	realtime data processing).  The peer connection managers use the
	CCP to communicate conference-related requests to each other.

	Heterogeneous end-system capabilities in terms of encoding
	schemes and data rates.  All end systems' must match
	at conference setup.  Connection manager has the task of
	synchronizing configurations to initiator's request.

	Currently the control protocol relies on a group interface
	in order to be able send to multiple participants at once; 
	it is not tied to the use of IP multicast.  The control protocol
	is used however to share multicast addresses of underlying tools
	with peer connection managers.

	No global directory services available.  This has led to
	well-contained naming, where each site maintains a static
	configuration file of its favorite remote sites and their
	addresses.  More recently, allowing on-the-fly additions to 
	each site's local cache of user aliases.

	Depending on the testbed and mode of software, bandwidth 
	reservations are provided by ST, or not at all when using
	IP-Multicast.  Looking to experiment with other QoS schemes 
	in the near term.

6.a How do you define conference control?  

	The managment and coordination of multiple sessions, and
	their multiple users in muliple media.  

6.b Conference control functionality supported.

	- session:
		- pre-scheduling, status, exclusive sessions
	- membership: connect, invite, join, disconnect
	- configuration: (only at set up) 
		- set of media (or underlying tools) to include
		- parameters for each media

	- control-related:
		- remote camera switching
		- video "floor selection"
			- sender selected (for limited bandwidth scenarios)
			- receiver selected (for personal preferences)
		- "autopilot", where one site can auto control another site

6.c Other control functions you would like to support.

	- modification of media set and parameters of ongoing sessions
	- session archiving
	- include combination nodes, or reflectors, in the control path
	  to perform encoding translations, mixing functions (4-to-1),
	  etc.
	- interface for security and qos preferences
	- merge conferences
	- side chats
	
7. Conference control protocol details: 

	Tightly-controlled session model, entailing explicit setup
	and tear down.  By default, there is nway connectivity among
	participants.  Each participant stores state information such as the
	membership list and each member's current state (involved, 
	used-to-be-involved).  All participants are appraised of 
	conference state at initiation and when any new members join 
	or old members leave.  Can opt to maintain global state more 
	rigidly through stricter synchronization methods, if desired.  

	CCP is sensitive to WAN operation; it attempts to provide
	reliable messaging among peers and is able to repair state 
	information in the event of temporary network outages.

	Scale is an issue.  Membership changes (at setup time and
	throughout the session) result in 1-to-n communication.
	Rigorous global state maintenance requires n-to-n communication.

8. Hardware/software platforms.  

	Sunview and X-based GUIs.  Moving toward Tk/tcl.

	UNIX-oriented system code and libraries; currently runs on 
	Sun workstations.

	CCP is built on top of a reliable, group messaging service that
	in turn uses UDP sockets.  Expect to replace the group messaging
	service with other schemes (e.g., ISIS) as they become more readily 
	accepted or are in widespread use.

	RPC-based control of servers designed for local hardware control 
	(crossbar switches, video codecs, cameras, monitors).

9.a What specifically has or has not been implemented?

	The MMCC program, the GUI to the system, lags behind the
	capabilities of the CCP protocol.  Now working on GUI support for
	multiple sessions at once, more formalized interface between
	connection manager and media agents, and additional configuration 
	language detail for capability choices.

9.b What was unexpectedly easy or difficult to implement?

	Maintaining rigid global state and resynchronization are
	difficult.  The CCP spec calls for a variety of policies, only
	some of which are reflected in in the GUI of MMCC.  Too much
	flexibility in the protocol leads to complicated state
	transitions.  From an implementor's point of view, the original
	CCP spec was too complicated; as a consequence only the most
	common functions have been realized in the latest version of
	code. The follow-on spec needs to be simpler, and should also
	distinguish between recommendations about core functionality and 
	provisions for special services.  Separation of confctrl into smaller
	units made problem clearer (session management vs membership
	management vs configuration management).

9.c What might you change as a result?

	Begin with scaling as design goal.
	
10. Papers.

	FTP venera.isi.edu:pub/hpcc-papers/mmc/README.txt for details
	on further readings.

---

From: schooler
Date: Wed, 24 Mar 1993 10:01:51 -0800

----- Begin Included Message -----

---

From: [email-masked]
Date: Tue, 23 Mar 93 19:04:36 -0800

1. Name of project, program and/or protocol.
	ZAPT - Zoned Analog Personal Teleconferencing
	(extension of Bellcore's Touring Machine system)

2. Contact person, affiliation and e-mail address.
	Joe Touch
	USC/Information Sciences Institute
	[email-masked]

3. Target operating environment and key design considerations:
	LAN focus (can extend to MAN)
	analog media
	personal teleconferencing (live video), also ASCII text ('talk')
	uses UDP messages for control
	desktop teleconferencing
	supports 1:1 and M:M (M<=4) teleconferencing, and 1:N broadcast
	uses passive analog hardware for bridging and mixing
	uses Bellcore's Touring Machine (V 2), with custom extensions
	developed for the NeXT workstation
	Main design consideration was to implement desktop video
	teleconferencing quickly, using existing software, for the NeXT.

4.a Type of conference styles supported by your system/protocol.
	supports 1:1 and M:M (M<=4) teleconferencing, and 1:N broadcast
	supports only small conferences or medium-sized broadcasts.
	requires group consensus (all-or-nothing behavior)
	supports explicit response or automatic-accept authorization

	Novice users supported via simple GUI, but expert system maintenance
		required at this time.
	Meetings informal (telephone model - call, and see if they answer)
	No reservations.
	Quality-of-service demand is high, but trivially supported in analog.

	Centralized system - one database, one resource manager, etc.
	Conference control performed by components at all levels, but
	orchestrated by a single module dynamically created for each session. 

	Assumes end-system homogeneity (i.e., analog A/V, UDP packets).
	No multicast (analog bussing of A/V performs signal 'multicast')
	All users are currently preregistered, but dynamic reg. allowed.
	Current directory does not 'advertise' sessions, or call-back on
	database entry changes. Bellcore's version 3 implements both these
	services using Oracle.
	No quality-of-service supported.

	Multiparty multilayer protocol management, i.e., the control of
	N-way extensions of 1:1 connections in the number-of-participants
	domain and the number-of-connections domain. 

6.b Conference control functionality supported.
	sessions config. is broadcast or multipoint (latter includes 1:1)
	session config. can limit to any subset of audio, video, data (ASCII)
	membership controlled by session members - add, delete, hangup
	member joins supported at ISI by 'callback'
	members can suspend/resume a session (receiver control only)
	members can be in many sessions, but active in only 1 at a time

6.c Other control functions you would like to support.
	- join (supported in Touring Machine V3)
	- best-effort setup (v.s. all-or-nobody)
	- merge conferences
	- multidomain capability (embeddable/recursive/heirarchical control)

	Tightly-controlled model, implicit setup and teardown.
	A user selects among a preregistered set to call.
	Call setup is all-or-nothing; if any user is not active, or
	refuses the request, the call aborts.
	Control is managed by a dynamically created module, that acts 

	on behalf of the session once created. There is no distinguished
	owner/creator once a session is active. The module disappears when
	the session disappears. 

	State information is broadcast to the members of a conference, 

	when a member enters or leaves, or even activates or deactivates
	a session.
	State information is kept in various places; no synchroization of
	state (or resynchronization) is available.
	The control does not scale, and does not embed (support recursion, 

	i.e., conference within a conference, or conference control 

	maintained by a set of control modules).
	Participants are assumed to have N:N interconnection in the control
	path. 

	The system is not robust. It performs timeout-failsafe on UDP message
	loss, but does not retry. System components do not support 

	warm-restart.

	Bellcore's system developed for Sun-3, Sun-SPARC.
	Currently ported to NeXT OS 3.0.
	X11R4 GUI's.
	U**x BSD compatability required.
	NeXT implementation requires X11 emulation (co-Xist software).
	Requires analog audio and video I/O (camera, monitor, speaker, mic)
	 - only monitor function is performed by NeXT computer (NeXTDimension
	   board displaying NTSC 24-bit video).
	Uses analog crossbar audio and video switch (with serial control)
	Uses passive analog video bridge (Panasonic).
	Uses passive analog audio bridge (TEAC TASCAM).

9.a What specifically has or has not been implemented?
	We have implemented non-proprietary bridging (multiparty support) via 

	a modification of the Touring Machine model. We have also developed
	a radio client (broadcast with remote join), even though joins are 

	not implemented in our version of the base software. The radio
	client is implemented as a call-back - a user calls the radio,
	it refuses the call, and the radio adds the user to its existing
	(continuous) broadcast session.
	We are also implementing a remote proxy feature, supporting 

	internal or external bridging. This is performed by intercepting
	UDP packets, and modifying their contents, so as to give the 

	Touring Machine the impression of single-domain operation.

9.b What was unexpectedly easy or difficult to implement?
	Reimplementing bridging (multiparty) was easy. Bellcore's 

	implementation used an underlying preexisting testbed for
	intelligent bridging control. Instead of emulating that
	environment, we implemented bridging by rewriting the bridge
	control module as a 'null' control device, and changing the
	model definition of a 'bridge'. Instead of considering a
	bridge (a combination/distribution entity) as a special case
	of a LINK, we considered it a NODE.
	This experience emphasizes how something difficult can be
	easy if the abstraction is changed, and emphasizes my
	interest in a complete and general abstract model of
	multiparty multimedia communication, regardless of whether
	it's first version is VERY abstract.
	Similarly, developing a remote proxy originally entailed 

	rewriting the resource manager and control system. Instead,
	we decided to implement a method of virtualizing the environment,
	so that the end components were aware of the names across the
	domain barriers, but the control components were not. The result
	requires only simple packet translators.

9.c What might you change as a result?
	We ported and extended Bellcore's Touring Machine, and used
	the event as an opportunity to learn about different
	conference control schemes. One thing that was apparent was that
	the notion of a multiparty multimedia conference was ill-defined.
	Another was that the models of the implementations were incompatable.
	We are currently developing an abstract model that reduces to MMCC
	and the Touring Machine (with ISI extensions or without) as specific
	cases
	The model, currently coined "M3" (a Multiparty, Multilayer Model), 

	will take the following issues as design goals:
		simplicity
		generalizability
		reducibility to existing models and implementations
		self-similarity (embeddability, i.e., supporting recursion)

10. If available, suggested readings about your work on confctrl.
	A description of the M3 model is currently under development.	

----- End Included Message -----