Subject: Reply to Session Control Protocol Survey

From: [email-masked] (Brian Coan)
Date: Thu, 1 Dec 1994 18:41:50 -0500

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

Name of the Protocol (if any)

The protocol is part of the Touring Machine system (Touring Machine is a
trademark of Bellcore).  The protocol itself does not have a name.

Technical point(s) of contact including email address(es)
and organization affiliation

R. C. Sekar  [email-masked]  Bellcore
Brian Coan   [email-masked]  Bellcore

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

1) Between what components is the protocol used?  I.e., between media
   agents, between session managers, session manager to media agent,
   or other.

The protocol operates between conference session managers and network-resident
session control software.

2) Describe, at a fairly high level, the characteristics of session
   control that are key to your protocol.  I.e., what is the protocol
   trying to achieve and what special problems does it solve.  E.g.,
   process coordination, resource negotiation, media synchronization,
   floor control, topology management, etc.

The protocol enables the conference session managers for a collection of
prospective conferees to negotiate and reach an agreement for the sharing
of resources for a conference.  Topics of negotiation include session
membership, resources to be allocated to the session, and policies for
future session changes.  The network-resident session control software
mediates the negotiation and enforces the agreement.

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

None.

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

4) Is the representation ASCII or binary?

In the present implementation, communication between conference session
managers and the network-resident session control software is in Lisp-like
ascii messages.  This choice of representation is not fundamental.

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

In the present implementation, communication is via asynchronous messages.
We have a paper design for the same protocol using binary RPCs.  In this
design RPCs are initiated at some times by conference session managers and
at other times by the network-resident session control software.

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?

Whether it's symmetric or asymmetric is determined by the policy for the
current session.  Similarly, which participants get certain messages is
determined by policy.  The policy is one of the things that is the subject
of negotiation.  The initial negotiation at session establishment is symmetric.

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

The present implementation uses customized messaging software that operates
on top of either TCP or UDP.  Currently TCP is used for the session control
protocol.

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 session control protocol relies on reliable message delivery.

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?

A directory service is used to map prospective participants to IP addresses.

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

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

Sessions are described as Lisp-like S-expressions.  The description includes
participants, policies, and resources.  Session scheduling is not directly
supported as a part of the session control protocol.

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

A summary description of the session may be registered in a directory server,
allowing new participants to request to join.
		  
12) How is a session identified?  I.e., what is the session "handle"
    and to what extent is it globally unique?

In the present implementation an ad hoc session name is used.

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?

How open the membership model is depends on policy.  Current policies include
public and private sessions.  If the session is private, then the membership
is closed (the members know each other and joining is by invitation only).
If the session is public, then the membership is partially open
(the members still know each other but anyone can request to join).

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

Within the session protocol members are known by email-style addresses.
At the user interface members are known by the person's real name.

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 session protocol controls the allocation of shared resources and it
controls session policies which in turn control how session changes are
made.  In general routing is not explicitly controlled.  Floor control
is not a session control primitive, but a variety of floor-control policies
are expressible using the general policy mechanism.  The network-resident
session control software is logically centralized but could have either a
centralized or distributed implementation.  The current implementation is
centralized.

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?

The initiator of the session or the proposer of a session change makes
a proposal.  Should the proposal be agreed to by a sufficient collection
of session participants it is implemented; otherwise it is abandoned.
In the present implementation unanimity is required for a session change
to be adopted.  We have a paper design in which session policy determines
the requirement for a session change to be adopted.

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

Membership, resources, and policy are negotiable.  Data formats and
scheduling are not presently negotiable.

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?

New members can be added at any time.  In private sessions the proposal
to add a new member must be made by an existing member.  In public sessions
the proposal to add a new member may be made either by an existing member
or by the new member.

New members must consent before they are added to a session.

Session policies are negotiated by session members.

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 session control protocol is implemented in a research prototype and
has been in daily use by a community of over 100 researchers at Bellcore
for 4 years.

The session control protocol and the Touring Machine system that
uses it are implemented in C as a collection of communicating processes
(software objects with well-defined interfaces).

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
    publicly-available paper or report, please provide a reference
    rather than detail here).

The Touring Machine system and and its session control protocol, including
examples are described in "Touring Machine System," Communications of the
ACM, vol 36, no 1, pp. 68-77, January 1993.