Subject: MMUSIC Working Group minutes for July 1994 IETF

From: [email-masked] (Abel Weinrib)
Date: Fri, 12 Aug 1994 10:02:02 -0500

These notes were prepared by Abel Weinrib ([email-masked]).  An on-line
copy of the minutes and the accompanying slides are available in the
directory ftp.isi.edu:confctrl/minutes as files "ietf.7.94" and
"slides.7.94.tar" (which contains "slides.7.94.[a-d].ps").

      Multiparty Multimedia Session Control WG (MMusic)
                Minutes from the 30th IETF
                    Toronto, Canada
                     July 27, 1994

               Eve Schooler, [email-masked]
               Abel Weinrib, [email-masked]

The Multiparty Multimedia Session Control (MMUSIC) Working Group held one
session at the IETF meeting in Toronto.  This session focused on reports
from implementors of a range of multimedia conferencing applications.
The goal was to identify common ground for interoperability.  The agenda
included Dick Cogger who talked about architectural issues in CUSeeMe, a
Macintosh-based conferencing tool.  Ron Frederick spoke about the Jupiter
project that is providing audio, video and shared windows for MOO systems.
Carsten Bormann presented a reliable multicast protocol similar to MTP
that they have designed and implemented to support their Xy shared window
system.  Ian Wakeman gave an update on the CCCP communication and control
protocol being developed to support conference control.  Joerg Ott described
the ITU T.gcc standardization efforts.  Abel Weinrib provided an update
on an implementation of the agreement algorithm being developed by Ted Ko
at Bellcore as a Masters project.  Finally, Eve Schooler spoke about
interoperability, defining the various interfaces that, if standardized,
would facilitate interoperation of different applications and media agents.

1.  Architectural Issues in CUSeeMe, Dick Cogger, Cornell University

In this talk, Dick Cogger argued for having an integrated user
interface (UI) that is connected to conference control and central
bandwidth management.  The major components of the CUSeeMe system
include the user interface, conference control, and a bandwidth
manager, along with modules for audio, video and a window for
displaying slides; it also provides a plug-in interface that allows
for the addition of other add-on applications.

The CUSeeMe system uses a reflector running on a Unix system that
simulates multicast.  It has been tempting to add additional
functionality to the reflector.  Currently, the reflector prunes a
stream back to its source to conserve bandwidth when no one wants to
receive the stream, which is particularly valuable on low-bandwidth
links.

Dick argued that the UI and conference control should interact so that
the control status information can be used to control elements in the
UI that indicate what other users are doing and what they are capable
of.  They have not yet come up with a clean separation that would
decide whether this information should be sent in RTCP messages or as
part of general session control.

Bandwidth management in CUSeeMe is based on a bandwidth cap that is
adapted based on loss reports from receivers.  This approach may be
problematic if there are heterogeneous receivers that have differing
amounts of available bandwidth.  Audio is given priority (if anyone
wants to hear you) and sending of video is subject to the cap (if
anyone wants to see you).

2.  Jupiter Video Protocol, Ron Frederick, Xerox PARC (slides.7.94.a)

The goal of the Jupiter project is to extend a MOO system (text-based
social virtual realities) to include audio, video and shared windows.
They are developing a local client that speaks RTP, HTTP, etc.   Each
client is controlled by a TCP connection to the central MOO server.
Currently, the client is running under UNIX and Window; a Macintosh
version will be done soon.

The MOO server plays a coordinating role.  It provides permanent
storage of information, key management, multicast address
management, and sharing of window state (whiteboard, etc.).  The
central server also prunes media streams back to their sources if no
one wants to receive them, and allows control of bandwidth.  Their
longer term plan is to do a distributed server implementation to avoid
the single point of failure and performance bottlenecks of the central
server and to better cope with user communities spread across
administrative domains.

The Jupiter client is really a media agent, having no inherent UI.
Rather, the server downloads a window layout into the client, and
widget events are sent back to the server for action.  The video client
supports a "videosend" protocol that allows the server to request a
list of available video sources, set the ttl, start a video stream from
a source to a destination, stop a video stream (to a particular
destination, or to all), and to set video attributes.  Video reception
is supported by a "videoPane" widget that shows one video source of any
size.

3.  Reliable Multicast and Groupware Applications,
        Carsten Bormann, U. of Bremen (slides.7.94.b)

Carsten spoke about a reliable multicast protocol that they have
developed.  The goal was to develop a multicast protocol built on top
of IP multicast that is optimized for groupware applications.  In
particular, their objectives included:  scalability (not linear
algorithm), efficiency, robustness (perhaps more important than strict
"reliability"), and message ordering (to make the application
programmer's life easier).

Their protocol, MTP2, is based on MTP (RFC 1301).  It has one master
and many producers and consumers of messages.  Global ordering is
sequenced by the master with use of a token, and the master can control
the message rate by limiting the transmission of the token.  The
protocol also supports atomicity, and addresses scalability with the
use of unicast negative acknowledgments.  The protocol has a
"heartbeat;" after some number of heartbeats the sender discards the
message.  Additional features of the MTP2 protocol includes request of
message retransmission from anyone, not just the sender; allowing
unsequenced messages as well as sequenced ones; and master loss
recovery and migration.

The MTP2 protocol has been used for the Xy window sharing system, which
is based on multicast from the Xy server to agents on each workstation.
It also underlies the Sharekit application replication toolkit that
allows the creation of cooperation-aware applications by layering
Sharekit between the GUI and the application engine of applications
structured in that way.

4.  CCCP Prototype, Ian Wakeman, UCL (slides.7.94.c)

Ian gave an update on the CCCP protocol that was talked about at length
during the Seattle IETF.  There is an implementation of CCCP, and it has
been used to create a floor control agent.  They plan to release the
implementation in mid-August.

5.  ITU GCC Work, Joerg Ott, Technical U. of Berlin

Joerg talked about the work to standardize "Generic Conference Control"
within the ITU.  It should be released as a standard by early next
year.  GCC coordinates membership and integrates applications,
including functions to establish conferences, provide a conference
roster and an application roster and registry, and manage conductorship.
It does not support floor control.

GCC relies on BMCS, an underlying multicast communication service that
offers reliability, optional global ordering, admission control,
multiplexing, and token management.  BMCS is realized with reliable
flow-controlled transport on point-to-point links on a hierarchy of
multipoint control units; the top MCU controls membership, etc.

Despite the considerable overlap in interests, the people working on GCC do
not know what is going on at IETF, and we know little of what they are
doing.  We are exploring the possibility of developing a liaison with this
effort.

6.  Agreement Service Update, Abel Weinrib, Bellcore

Abel briefly discussed the work being done at Bellcore to create an
"agreement engine" that implements the agreement algorithm which has been
discussed at previous MMusic meetings.  Ted Ko from M.I.T is doing his
Masters thesis on this topic at Bellcore.  It is envisioned that the
agreement algorithm will form the foundation for a general session
control protocol.

7.  Interoperability Report, Eve Schooler, ISI (slides.7.94.d)

Eve discussed work being started to demonstrate interoperability between
existing conferencing implementations.  There is a commonality in the
architectures of many of these implementations, with some sort of session
manager function doing coordination "horizontally" (peer to peer) between
session managers, and "vertically" controlling the media agents that
provide the media transport for the conferences.  An open question is
whether the vertical and horizontal interfaces should use the same
underlying communication mechanism.

There are many session orchestration approaches (sd, mmcc, maven, ivs, dvc,
comet on WWW, mmphone over e-mail).  One goal is to create a common session
description that they can all use.

There are many ways to communicate with media agents, including CCCP,
Tk-send and multicast with ttl=0.  It would be good to choose one, and to
come up with a common control interface to be used by all media agents.
Such a control interface should include at least "on/off" control for
multi-agent muting, channel surfing, channel selection, and floor
moderation, as well as up-calls from the media agents to support
video-to-follow-audio, adaptive QoS tradeoffs, inter-agent synchronization,
and the like.

The overall goal is to create a  "plug and play" environment in which
applications' developers can choose between a variety of session control
agents and media agents.  What is needed now is the documentation of
control interfaces to existing media agents, and of session agent
protocols.

8.  Discussion

In the ensuing discussions, several implementors agreed to document the
protocols that are presently in use, to outline improvements planned
for future releases, and in some cases actually to work on interoperation.
There were at least two reasons for promoting documentation efforts.
First, it would be useful to provide informational RFCs for many of the
publicly available applications.  Second, writeups would go a long way
towards motivating production of a shared protocol or protocols.  It was
also suggested that it might be useful to hold a workshop to bring
together people interested in these problems around the same time as
the next IETF meeting in San Jose, possibly hosted by SRI.