Subject: Template for confctrl BOF

From: schooler
Date: Fri, 12 Mar 1993 19:08:33 -0800

As discussed earlier, 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 the 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 
filled 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.

All feedback and opinions are welcome.

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

5. Architecture assumptions: 

   - distributed vs centralized model
   - system component(s) responsible for conference control
   - degree of homogeneity in end-system capabilities 
   - multicast integration
   - directory services
   - support for quality of service
   - ???

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, a couple of 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
	- 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 a design goal.
	
10. Papers.

	[To be provided in confctrl bibliography compilation]

---

From: schooler
Date: Wed, 24 Mar 1993 09:58:35 -0800

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

---

From: Fengmin Gong <[email-masked]>
Date: Tue, 23 Mar 1993 17:27:04 -0500 (EST)

Eve,

First a few comments on the WG description.

* You explicitly mentioned  the scalability goal, what about the
ineroperability goal.  I think to the degree that conference sites
/participants should be able to talk about their conferencing
capability using a standard "alphabet", interoperability needs to
be a goal and is relevant to confctrl.

* You did indicate the relevant WG's to confctrl, but I wonder where
should the work of specifying the multimedia conferencing architecture
go?  I think we by default have an understanding of what pieces are
there, but a clear definition of their functions and interfaces is
needed to coordinate the whole development well.  Is the architectural
steering group a regular WG and going to address this issue? What is 
your thought on this?

Thanks,
Fengmin

CONCERT Video Network Migration
MCNC project

Fengmin Gong
MCNC Center for Communications
3021 Cornwallis Road
RTP, NC 27709

Email: [email-masked]
Phone: 919 248-9214
FAX:   919 248-1405

   - WAN vs LAN 

	CONCERT is a state-wide WAN,
	North Carolina has plan to deploy ATM state wide
	MCNC has currently an ATM LAN and an FDDI LAN

	Existing analog video network
	Digital video uses CLI Rembrandt II (H.261) over dedicated link
	Packet video development uses:
	* Rembrandt II
	* XVideo (JPEG)
	* Bart (Sun's prototype capture board) & software compression
	* SPARCstation built-in audio

	* real-time audio & video
	* shared computer-supported working space

	Packet switching using "enhanced" IP and IP/ATM.

	Support both room-based and desktop conference and
	allow participants with desktop capability and the
	conference-room facility to be in one conference
	session.

	Consider minimum styles:

	* Lecture style (such as teleclass in CONCERT)
	* Organized presentation type such as a small workshop,
	  the key is the presence of a chair for floor control
	* Brain storming session, absent of explicit chair

   - expertise level 
	mixture of computer experts and novices
   - formality of meetings
	mostly formal, people who used to the CONCERT video conf.
   - demand for quality of service
	the overall QoS should be comparable to the current
	CONCERT net:
	* support color
	* at least close to 10 fps (CIF equivalent size image)

   - distributed vs centralized model
	* Early on centralized control (switching) due to the
	underlying link configuration
	* Goal is to provide decentralized control.

   - degree of homogeneity in end-system capabilities 
	* short-term allows H.261 based hardware & software
	compression capabilities
	* JPEG compression capability
	* long-term supports for negotiating among many, eg,
	H.261, NV, and cellB (used in Bart).

   - multicast integration

	Interface will be in place to use multicast service
	from "enhaced" IP when available.

   - directory services

	Look to X.500 based directory service to support remote
	conferencing as one type of services.

	Mechanisms will be in place for processing QOS request,
	there will be no guarantee until the underlying network
	provides resource reservation and management.

	Conference control is the function that coordinates among
	the conference users, multimedia agents (including
	hardware and software), directory servers, and underlying
	networks (maybe transport mechanism) to provide a set of
	conferencing services.

6.b through 10 are not applicable.

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