Subject: Confctrl - Template

From: Lakshman K <[email-masked]>
Date: Wed, 24 Mar 1993 16:42:53 EST

Eve,
	The last BOF identified two forms of control: Membership control
and media control. The protocol described in this template focuses on
media control. It could provide some answers to a session layer protocol.

- Lakshman
[email-masked]

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

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

      Multiflow Conversation Protocol (MCP) Suite

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

      Raj Yavatkar, University of Kentucky,
      Dept. of Computer Science
      [email-masked]

3. Target operating environment and key design considerations:

    MCP consists of transport and session layer protocols designed to
    meet floor control and causal synchronization  needs of distributed
    Multimedia Collaborative  Applications.

    It is expected  to be used over LANs and WANs.

    Digital media.
 
    MCP provides two communication abstractions:

    - First, MCP provides a token based mechanism for concurrency control
    among participants of a  multipoint connection. A token  serves as an
    authorization for  transmission in a multipoint connection.
    Applications are free to exchange, replicate, and delete tokens to
    exercise flexible governance over the amount of concurrency control
    desired. 
 
    - Second, MCP includes a communication abstraction called a  multi-flow
    conversation to allow causal and temporal synchronization among
    traffic  over multiple independent streams. 

    Thus, the protocol performs the media control functions listed in the
    last BOF.

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

    MCP enforces and provides the necessary mechanisms to implement
    different conference and floor control styles.

    Control may vary from a strict ``floor-based'' control (useful in
    conventional teleconferencing) at one  extreme, group discussions,
    the chalk-board metaphor, and  no control (as in shared window systems)
    at the other extreme.

4.b Profile of user community: 

    MCP is a protocol, hence to be used by application devolpers
    who need conversations, floor control, and causal synchronization.

5. Architecture assumptions: 

    MCP assumes the availability of an underlying network layer
    that supports  reservation and guarantees for real time data.
    The network layer could be FP (flow protocol), COIP, ST-II, or
    RSVP.

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: 

    Applications can create multipoint flows, specify different token
    passing policies, and  QOS requirements for synchronization purposes.

    The main focus here is on token based floor control and synchronization.
    MCP provides calls to transfer, replicate, distribute, delete
    (capabilities)tokens. The token transfer semantics can be tailored to
    meet the needs of different  floor control policies. 

    The delivery requirements for various token packets are different.
    For instance, requests need to be delivered to all endpoints
    (unreliable multicast) while token transfers to one endpoint
    (reliable unicast).

    A "Conversation" consists of one or more data flows. Flows can be added
    or removed from conversations. The control is distributed.

    Once a conversation is established MCP provides casual synchronization
    among constituent flows.

    Synchronization information and tokens are sent over an out-of-band
    control connection.
    
8. Hardware/software platforms.

   SunOS 4.1.1 kernel implementation and libraries. 

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

    The protocol resides under the socket layer and on top of COIP-k
    (Chuck Cranor, Washington University).

    The token calls and conversations are implemented through setsockopt
    calls.

    Events and exceptions are notified  by using signals and exception
    condition flags.

    A number of Multi-user collaborative applications have been ported
    or written.

    Nevot(Henning Schulzrinne) has been ported on MCP and changes made to
    provide various floor-control styles  to demonstrate usefulness of
    MCP primitives.

9b What was unexpectedly easy or difficult to implement?

    Token passing posed several interesting issues because the semantics
    need to cater to a wide variety of floor control styles such as
    no-control, activity sensing, chalk-board, and other user driven policies.
    The nature of queuing requirements for different policies  differ.
    Providing the right amount of flexibility and maintaining protocol
    simplicity was not simple.

    Creating conversations are easy if all endpoints are participants
    in all flows that constitute a conversation handling imbalances are not
    easy. Currently, MCP assumes the presence of a higher level conference
    control protocol to decide which endpoint initiates a conversation
    request.

    Providing a causal relationship based on the notion of delta-causality
    was hard. 

9.c What might you change as a result?

     The applications have  brought out some of the subtle details involved
     in providing floor control. We are still in the process of evaluating
     our choices.

     We need to consider events such as hosts dying with tokens and provide
     a protocol for regeneration.

     MCP should allow any endpoint to create conversations.

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

Raj Yavatkar,MCP A  Protocol for Coordination and Temporal Synchronization
in Multi-media Collaborative Applications",Proceedings of the 12th
International Conference on Distributed Computing Systems" IEEE,1992,June

Raj Yavatkar "Issues of Coordination and Temporal Synchronization in
Multimedia Communication", Proceedings of Multimedia '92, 4th IEEE COMSOC
International Workshop on Multimedia Communications" 1992 April"

There is also a paper to appear in USENIX'93 that deals with design
and implementation of MCP in the kernel.

			----------------

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