Subject: Confctrl - Template for SRI's CECED

From: Ruth Lang <[email-masked]>
Date: Wed, 24 Mar 93 18:15:27 PST

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

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

Collaborative Environment for Concurrent Engineering Design (CECED)

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

Earl Craighill or Ruth Lang
SRI International
[email-masked] or [email-masked]

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
   - ???

CECED provides shared workspace (programs and database) collaboration
over unmodified single-user X applications, and audio conversations.
It supports concurrent use of a mix of shared and private
applications.  It presently allows only one conference at a time, but
in the future will support multiple simultaneous conferences.  Audio
is presently implemented through the use of vat.  We have no near-term
plans for inclusion of digital video, although it could be added as
easily as vat has been.

A Session Manager component coordinates all conference related actions
by providing access to the user interfaces for collaboration-enabling
processes such as vat and the shared-workspace program.

A Connection Collaboration Management Agent provides support for
connection-oriented conference control capabilities.  Future
capabilities will include support for resource-oriented control and
negotiation.

CECED has been designed to operate in both WAN (high speed digital and
low-speed analog) and LAN IP networks.  The current implementation
(alpha version) has been well-tested only in LAN environments
including less than 10 participants. Some WAN testing has been done.
We intend to begin implementation of a more robust WAN version
including testing and user studies this year.

CECED has been demonstrated cross-platform between/among Sun
SPARCstations and Macs.  Room-to-room testing has been done among
Suns.  A heterogeneous Sun/Mac configuration has been used as part of
within-room demonstrations. We will do more room-to-room Mac/Sun
testing when an audio capability between Suns and Macs has been
developed; this development will occur during 1993.

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

CECED was designed to support a general class of applications,
including distance learning and VLSI concurrent engineering design and
redesign activities.  It is intended to support small working groups
(up to 10s of individuals, but typically less than 10) whose
activities are problem-solving or learning oriented.  Typical
interaction styles may include novice/expert, peer-to-peer (e.g.,
designers or students), and designer/customer.

CECED will be deployed in the near future for the purpose of
conducting user studies in VLSI design seminar class at a University.
In the future (within the next two years) it will be deployed in more
commercial-oriented VLSI design environments which will include use
over a WAN.

4.b Profile of user community: 

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

The users are assumed to be computer-literate with expertise in their
own domains (e.g., VLSI design).  They are not expected to be computer
scientists/researchers or computer/network administrators.

CECED is intended to support informal interactions such as the
problem-solving activities that occur among novices and experts,
learners and mentors, peer designers, or the interaction which occurs
between designer and customer during the design process itself.

Currently, CECED requires a low-delay network environment to ensure
good audio quality and relative synchronization of the shared
workspaces.  Future developments are intended to relax this
requirement, but we will not expect to be able to operate in a general
Internet "datagram" service environment.  Reliability as well as
low-delay is key in ensuring the integrity of the shared workspaces.
High bandwidth is not a requirement.

Our wish list include having QOS mechanisms which support acquisition
of transport services and the ability to obtain feedback on
transport-level performance.

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)
   - ???

CECED employs a distributed, peer-to-peer model.  The shared workspace
process utilizes a closed membership model.

Multicasting is used by vat; TCP is used as the transport mechanism to
support shared workspace interaction since reliability is a
requirement.  If a reliable transaction protocol was widely-available
and used, it would be used to replace TCP as the transport mechanism
in CECED.

A process named the Connection Collaboration Management Agent (CCMA)
is responsible for providing conference control services for CECED.
It was designed to employ a distributed, peer-to-peer model as well,
but the current implementation (considered pre-alpha) is centralized
and thus does not yet employ a peer-to-peer connection control
protocol such as Schooler's CCP.  A near-future version will employ
such a protocol; it is intended that the CCMA will adopt the
connection control protocol that results from the activities of this
working group or use Schooler's CCP as a prototype.

The CCMA does implement a general protocol to be used between it and
its "agents" for the conveyance of conference configuration (and later
to include resource) information.  This protocol has been named the
Collaboration Agent Control Protocol.

We are using X and its property mechanism as a means of providing a
distributed registry of conference information.  "Agents" are
responsible for registering their collaboration-oriented properties.
The CCMA accesses the distributed set of registries to provide a
composite connection picture to its agents.  X.500 will be considered
as a replacement for the X-based registry in future versions of CECED.

6.a How do you define conference control?  

The definition and management of the components which comprise a
conference, and the provision of aggregate views of the conference.
Conference components include both the participants of a conference
and the means by which they participate (the programs they employ to
collaborate).

Conference control should facilitate information flow about the anatomy
and state of a conference, but not be directly (rather indirectly)
involved in the management of individual components.  Both abstract
and detailed specification and definition of components should be
supported.

6.b Conference control functionality supported.

Conference control in CECED presently includes participant membership
for single conferences at a time.  No latecomer admission or resource
management or negotiation is yet supported.

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

That which was mentioned as unimplemented in 6b.

7. Conference control protocol details: 

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

No conference control protocol between Connection Collaboration
Management Agent (CCMA) processes is yet implemented.

The protocol used between the CCMA and its agents (e.g., the shared
workspace support process) -- Collaboration Agent Control Protocol --
uses explicit means to establish and convey information about the
conference view for that agent.  Successive exchange of protocol
messages and updates establish a common view of the state of the agent
and its peers both within the CCMA and the agent itself.  This
protocol is intended to be used among processes on one workstation
thus reliability is assumed.

8. Hardware/software platforms.  

CECED has been implemented on Sun SPARCstations running UNIX and X,
but the shared workspace component has also been demonstrated on Macs
running MacX.

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

Two CECED components are yet to be implemented: 1) a process trace
manager providing inobtrusive process history capture which will
augment use of a cut-and-paste capability that facilitates minimally
intrusive capture of VLSI design history, and 2) a information storage
collaboration management agent which will arbitrate between a database
and a groups of conferees to enable access for the group with the same
privileges, protection, and integrity as access for an individual

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

No component has been surprisingly easy or difficult to implement.
User testing will help reveal problems and thus point out difficulties

9.c What might you change as a result?

No significant changes have been identified to date.  User studies to
be conducted in the near future will help reveal directions in which
users feel our system must go in order to be truly useful.

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

General readings about CECED are available:

Earl Craighill, Ruth Lang, and Jose Joaquin Garcia-Luna, "Environments
to Enable Informal Collaborative Design Processes," Proceedings of the
CE & CALS Conference, Washington, D.C., June, 1992.

Earl Craighill, Ruth Lang, Keith Skinner, and Martin Fong, "CECED: A
System for Informal Multimedia Collaboration," to be published in
the MULTIMEDIA '93.