Subject: SRI's Session Control Protocol Survey Response

From: Ruth Lang <[email-masked]>
Date: Fri, 11 Nov 1994 17:13:52 -0800

For both information and an example, the survey describing SRI's
Session Control Protocol is included below.

Thane J. Frivold
Ruth E. Lang
----------------------------------------------

Session Control Protocol Survey
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Protocol Name:    None currently
Point of Contact: Thane Frivold -- [email-masked]
                  Ruth Lang -- [email-masked]
                  SRI International
                  Augmented Collaborative Environments Group

General Description
-------------------

1) Between what components is the protocol used? 

	The protocol primarily flows between session managers. A
limited amount of control information flows between the session
manager and our shared workspace agents (XCPS).  All other media agent
control is limited to command line configuration.

2) Describe, at a fairly high level, the characteristics of session
   control that are key to your protocol.

	The protocol was originally implemented with an eye toward
process management as well as reconciling resource requirements and
capabilities in a heterogeneous environment.

3) Describe, at a fairly high level, the characteristics of session
   control that you do not care about or have (un)intentionally ignored. 

	Because we have not ever had a cross media agent requirement
for synchronized floor control, the protocol does not manage floor
control.  It is assumed to be a function of the media agents.

	Also, the session control protocol does not provide its own
transport reliability; that is assumed to be provided by a lower level
protocol.

General Protocol Characteristics
--------------------------------

4) Is the representation ASCII or binary?

	The protocol is ASCII.

5) Is the paradigm request/response (client/server model),
   peer-to-peer, or other?

	The model is peer-to-peer.  

6) Is it asymmetric or symmetric (e.g. do initiator's have special
   privileges or state information)?  Are all messages sent to all
   participants or are some sent to a subset?

	All peers are, at the protocol level, considered equal.  In
the future, we envision any asymmetry to occur because of an imposed
or negotiated "policy" for the session.  Operationally, most messages
are sent to all peers, but the protocol allows directing messages to
an arbitrary subset of peers.

7) What transport protocol is used (TCP, UDP, multicast)?  Does it
   make use of other protocols such as RTCP?

	The protocol currently uses TCP.

8) Does your session control protocol rely on that protocol's model of
   transmission?  E.g., does it require reliable, ordered
   transmission or is multiparty state synchronization not a concern?

	The protocol relies upon both the ordered and reliable
delivery of messages provided by TCP.

9) Briefly describe the addressing model, if any.  I.e., how are
   messages routed to peers?  Are they sent directly, are multicast
   groups used, is message content/registration used, or other?

	Messages are sent directly to peers, and thus can be addressed
by destination only.

Session Control Characteristics
-------------------------------

10) How are sessions are described?  What does a session description
    specify -- people, resources, scheduling information, etc.?
    Optionally, include an example session description.

	The current description format consists of a series of peer
(session manager hosts), participants (human usrs and their display
and execution hosts), and processes (media agents and/or
applications).  The basic format of each of these directives is:

  confConfig <conf ID> [add|delete] [peer|participant|process|cma] <arguments>

	A sample session description is:

  confConfig exampleConf add peers foo.com bar.com
  confConfig exampleConf add participant joe foo.com foo.com foo.com:0.0
  confConfig exampleConf add participant sue bar.com bar.com bar.com:0.0
  confConfig exampleConf add process audio vat -C "exampleconf" 224.23.45.67
  confConfig exampleConf add process textEdit emacs
  confConfig exampleConf add cma XCPS xcps -server unix:0.0

11) Is the session description available and used outside of the
    context of the session control protocol?  If so, how
    (pre-scheduling, email-based initiation, etc.)?

	The protocol is currently used to describe preconfigured
sessions which are stored and accessed through an HTTP server.
Current development includes incorporating MIME based initiation and,
eventually, general session and participant registration.

12) How is a session identified?  I.e., what is the session "handle"
    and to what extent is it globally unique?

	The session ID is currently a text string and is globally
unique only by virtue of global coordination.

13) Briefly describe the membership model and range of models
    supported.  Is the model open (potentially unknown participation
    and attendance -- lecture hall style), closed (well known and
    limited -- invitation only style), or other?

	The environment assumes closed membership (often by invitation
only) sessions, at least as far as our shared workspace agent (XCPS)
goes.  The session manager can initiate arbitrary processes, so MBONE
style tools that support open membership can also be used.

14) How are members named and/or identified?  Are email-style
    addresses used, numeric identifiers, etc.?

	Participants are currently identified by a user name and an
X11 display; participant data is publically stored as properties on
each X11 display, thus creating a distributed database of information.
Current development is moving toward a "globally distributed, locally
centralized" model (a la DNS) so that email style addresses could
indicate both the individual and the administrative domain to contact
for the information.

15) Briefly describe "what" is being controlled within a session.
    Does the protocol control routing, data flow (e.g., floor
    control, channel selection), reflectors, end-user applications,
    etc.?  Are these entities controlled in a centralized or
    distributed manner?

	The protocol is basically centered around controlling processes
(configuration, invocation, and termination) and controlling our
shared workspace agent (configuring participants).  The processes are
all controlled in a distributed manner, although, through session
manager communication, certain user actions may be sent from a single
session manager to synchronize effects on the others.

16) How is consensus achieved among parties exchanging this protocol?
    E.g., does initiator dictate policy, does a mismatch lead to
    failure, does negotiation occur when agreement can not be
    achieved?

	Currently, a mismatch will lead to failure.

17) What aspects of the conference are negotiable?  Members,
    protocols, data formats, resources, scheduling, policy, etc.?

	At present, none.

18) What policies are implemented explicitly or implicitly (e.g., no
    latecomers permitted, only one video flow at a time, etc.)?  Is
    the choice of policy driven by system requirements, implementation
    constraints, resource limitations, etc?  Are the policies
    configurable?

	No explicit policy support is implemented; all peers are
considered equal and floor control is assumed to be handled by media
agents.  Also, because the session managers communicate under a closed
model, the protocol implicitly enforces a closed model policy on
membership.

Session Control Protocol Specifics
----------------------------------

19) What is the implementation status of the protocol (paper design,
    partially or fully implemented)?  What language was used to
    implement the protocol and how is it packaged (in a library,
    embedded in an application)?  Is the implementation freely
    available?

	The protocol is alive and kicking, albeit currently under
continued development.  The session manager is implemented in C, but
the ASCII protocol is written and interpreted by Tcl.  Most of the
"protocol" is implemented in Tcl, but certain low level primitives
have been added to extend the Tcl vocabulary, so the Tcl code is not
completely separable from the session manager.  The implementation is
not currently available

20) Describe, at a fairly high level, the basic directives of the
    protocol.  I.e., What are the protocol "commands" and what
    parameters are required?  If protocol uses a request-response model,
    indicate these pairs.  (If this information is contained in a
    publically-available paper or report, please provide a reference
    rather than detail here).

	The "logical" directives include the following commands:

#
# Usage: invite <from> <to> <conference> [<message>]
#

#
# Usage: decline <from> <to> <conference> [<excuse>]
#

#
# Usage: confDelete <conf>
#

#
# Usage: confExists <conf>
#

#
# Usage: confConfig <conf> <action> <type> <args>
#
# <action> = "add" | "delete"
# <type>   = "cma" | "process" | "participant" | "peers"
#
# <type>   = "cma" | "process"
#	     arg1 = <name>
#	     arg2 = <command>
#      NOTE: should also have indication of one/multiple instance/invocation
#
# <type>   = "participant"
#	     arg1 = <name>
#	     arg2 = <execution host>
#	     arg3 = <display host>
#	     arg4 = <X11 display>
#
# <type>   = "peers"
#	     arg1 .. argN = <ccmad peer list>
#

#
# Usage: confExec <conf> <type> <name>
#
# <type> = "cma" | "process"
# <name> = <name> (as defined in previous call to confConfig)
#

#
# Usage: confKill <conf> <type> <name>
#
# <type> = "cma" | "process"
# <name> = <name> (as defined in previous call to confConfig)
#

#
# Usage: confStopped <conf>
#

#
# Usage: confStart <conf> <type> <name> <initiator>
#
# <type> = "cma" | "process" 
# 

#
# Usage: confStop <conf> <type> <name> <terminator>
#
# <type> = "cma" | "process" 
#