Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/mmusic/mmusic-minutes-93jul.txt

Text File | 1993-09-22 | 19.8 KB | 460 lines

CURRENT_MEETING_REPORT_

Reported by Eve Schooler/ISI

Minutes of the Multiparty Multimedia Session Control Working Group
(MMUSIC)

An on-line copy of the minutes and the accompanying slides may be found
in the directory venera.isi.edu:confctrl/minutes as files ietf.7.93 and
slides.7.93.ps.

The MMUSIC Working Group met officially for the first time in Amsterdam.
We held two sessions that were multicast over the MBONE. The first
meeting was used to set the context and to discuss the progress made
since the BOFs held at the last IETF. During the second session, we
began to lay the groundwork for a strawman MMUSIC protocol.



First Session:  Context and Progress

After review of the modified charter, we discussed proposals for a set
of common terminology, an end-system architecture, the MMUSIC protocol
requirements, implementation considerations and conference styles.  To
narrow the scope of the discussion, we emphasized the need to think in
terms of a ``version 0'' negotiation protocol.



Terminology, Framework, Requirements

Highlights from Lakshman's ([e-mail]) proposed session
control glossary were presented (slides 4-8).  The key points were:


   o The differentiation between a ``session'' (an association of
     members for control) and a ``conference'' (a logical abstraction
     among multiple participants for multimedia real-time communication
     that consists not only of a control session) but also of related
     media associations and conference policies.

   o The identification of the main system components for an end-system
     teleconferencing architecture as being the conference session
     manager, media agents and a resource manager.


Since ``media'' is an overloaded word, we are open to suggestions for a
better term than ``media association,'' which is currently defined as
the encapsulation of the transport (point-to-point or multipoint) in a
single medium.

                                   1





Some clarification was needed for the term ``reflector participant,'' a
participant who neither generates nor terminates data but acts as a
go-between.  It is one of several participant types that arise out of
policy choices.  Julio Escobar commented that it is somewhat of a
misnomer since a reflector implies the ``reflecting back'' of data, and
a reflector participant may be used in a variety of fashions (e.g., it
may translate or combine data).  A reflector might be considered a
service access point.

In a change since last time, we emphasized that the conference session
manager is not necessarily the central system component, as shown in the
slide ``Framework 1,'' but that we think of it more as in the
``Framework 2'' slide.  However, to a large extent the relationship
among the various components is immaterial and implementation-specific.
For instance, a third approach, where the conference session manager is
part of one monolithic application, is equally valid.  The working group
focus is somewhat separate from the specifics of the framework choices,
since we are primarily interested in the interaction between the MMUSIC
negotiation protocol and the conference session manager.

Since the last meeting, we refined the session control protocol
requirements (slide 11).  They encompass several functions:  those for
distributed session management, dynamic membership management, session
policy management, and domain specific tasks (e.g., media associations
and configurations).  These groups of functions reflect the management
of a ``conference'' itself, and the management of its control, policy
and media elements.

In addition, we need to distinguish between the policies that are
carried by the protocol and those understood by the protocol.  Does the
protocol simply carry policy in the same way that it simply carries
media information, as a payload or ``bag of bits''?  While session
policy is not meant as an optional characteristic, since it is what
defines the session type, policy enforcement is probably outside the
scope of the protocol.  However, policy enforcement will impact the
degree to which we can provide session privacy and security.

The idea of advance reservation was a recurring topic, and one which
needs further scrutiny.  We expect the protocol to provide hooks for
pre-scheduling sessions, though the conference session manager has no
direct effect on reservations in the network, nor reservation strategies
(optimistic versus pessimistic).  Ambiguities remain about the
definition of resources, since they occur at a number of levels (e.g.,
people, rooms, hardware devices, workstation capabilities, network
bandwidth), and about how different policies will cause different
outcomes for resource scheduling and contention resolution.  One
suggestion was to create a proper session MIB to assist with end-system
management of configuration, capabilities and policies.

There was also speculation about the interaction between the session
manager and media agents, for instance when the transport for a media
agent fails but the control path is still functioning.  Although the
end-system architecture is somewhat outside the venue of the MMUSIC
protocol, we expect that some system component implementations will

                                   2





enable up-calls from (down-calls to) media agents and that are conveyed
to (from) the session manager either directly or indirectly.  The
session manager (media agents) may issue modifications as a consequence.
Similar mechanisms are needed for a session chair to be able to turn on
and off media agent data flows.


Implementation for the Internet

What are the building blocks needed for implementation and operation of
a MMUSIC protocol in the Internet (slide 12)?  Perhaps the biggest
questions were:


   o What transport platform is needed to support a general purpose
     negotiation service?
   o To what degree do we need reliable multicast?
   o How reliable does reliable have to be?


A critical, near term action item is to find an individual or a
collection of individuals who can advise us on our options and recommend
a solution.  It was noted that INRIA is planning to make a reliable
multicast solution available to the public shortly.  Regardless of the
approach taken, it was agreed that the interface to MMUSIC should be
designed so that the requirements for the underlying service are clearly
stated and that the actual choice may vary.  Different transport
implementations might be differentiated on their port number.  The
requisite comment was made that the goals of reliable delivery and
scalability of sessions conflict with each other.

In addition, it was suggested that we investigate the universal
identifier naming infrastructure already used in the WorldWide Web
(WWW). Another correlation was noted between synchronous and
asynchronous group negotiation, for instance for mailing list
coordination.  Yet the timing characteristics for conferee interactions
differ by an order of magnitude between real-time conference session
control and mailing list management.


Conversation Styles

Pre-IETF, we posted to the mailing list some musings on the relationship
between conversation styles and their requirements on the underlying
communication infrastructure.  It was agreed that a number of other
dimensions, besides size, need to be considered to describe the list of
session types more completely.  The question was raised about whether it
is easier to move from tight to loose or loose to tight schemes when
devising an approach, since the complicated scenarios occur somewhere in
the middle of the continuum (slide 13).

There also was debate about the existence of an upper bound on the

                                   3





number of conferees generating media (actively participating).  The
united-nations model and the distributed simulation model are good
counterexamples to an upper bound.  A criticism about the original
assumption is that we need to be careful not to introduce artifacts of
the capabilities of the current generations of tools into our
interaction model.  Although a preliminary document on the range of
conversation styles has been drafted, further details are needed.



Second Session:  Outline for a Protocol

The foundations for the strawman protocol were discussed (slides 14-20)
and included proposals for the definition of session state and for
naming conference components.  After thorough descriptions were given of
the main protocol assumptions, we delved into the basic message types,
examples of how they might be used and default session policies.  A
lively discussion ensued that helped us compile a list of outstanding
issues and action items (slides 22 and 23).



Session State and Naming

There were no strong opinions about whether or not naming should be
opaque or structured; in other words whether or not names should be
based on arbitrary identifiers, or structured around common identifiers
already in use, such as login ids, host addresses, port numbers and
timestamps.  In any event, the identifiers must be unique.  The
inclusion of a sequence number was felt to be overkill.  There are no
side effects if the session_id is based on the initiator's member_id and
the initiator drops out of the session; the incorporation of the
initiator's member_id is simply a technique to make the session_id
unique.  Aliases were deemed useful from an application standpoint, but
not necessary for the operation of the session control protocol itself.
The idea behind the aliases were to provide RTCP-like support, though
there are other textual pieces of information that RTCP carries in
addition to conferee names and the session name.

However, there are broader privacy concerns if we tie the member_id and
session_id to identifiable naming structures.  Also, should naming be
any different if the conference session manager acts on behalf of a an
individual user, conference room of participants, reflector participant
(the proxy), or an automated service (the virtual user)?

We also need to think about naming for mobility, both at session setup
(to forward requests when you have multiple addresses) and during
long-lived sessions (to allow users to move around), for example, were
individuals equipped with locator badges?  Can we leverage off of the
location services for naming transparency being designed in the MOBILEIP
Working Group?

                                   4





Protocol Assumptions

Questions about looser styles of conferencing came up.  How does someone
simply tune-in in a loose control fashion, given that we're thinking
about requiring the participation of at least one member for a session
to persist?  One idea was to create a virtual member to ``own'' the
session.  This virtual member would not only establish the session, but
also take responsibility to terminate it.  The idea of a virtual member
also could be applied to pre-scheduling sessions (again, this is
different from reserving the network or other resources), since the
virtual member would establish the session ahead of time and only
participate from a control standpoint.  Another suggestion was to view
this as allowing empty membership lists, since the virtual member is not
an active member.



Basic Message Types

The basic message types do not in and of themselves provide a
negotiation service; they are meant as building blocks.  Whether or not
they are delivered reliably is a separate issue.  We proposed a
three-phase commit handshake (Propose-Reply-Announce) for proposals
needing negotiations.  Suggestions about the messages that are under
advisement:


   o Add an optional ``reason'' field to the Reply message to make
     informed decisions about initiating another round of proposals
     after receiving a reject.  This is useful for handling error
     messages when not in the correct state to receive a Proposal.  More
     generally, this optional payload field could be added to both Reply
     and Propose messages:


      -  In the Reply message:  to allow a reject or an accept response
         to include hints that could assist with renegotiation.  This
         results in four types of Replies.
      -  In a Propose message:  to provide enough information up-front
         to reduce the number of negotiated rounds.


   o Differentiate between an Announce message that:


      -  Has been agreed on versus one that a proposer has decided on
         alone.
      -  Includes the delta versus the entire state of the conference.
         If the state is large, one may want to send the hash of the
         state.  Does an Announce send state, operations, or both?

                                   5





   o How to handle/avoid a questionable Announce message?  To cut down
     on false Announces, one option is to multicast all messages to all
     members.


Examples were provided of how the messages might be used, from simple
scenarios (using an Announce to leave a session or to produce keep-alive
messages) to session initiation or modification.  We assumed that a
proposal may be comprised of multiple operations.  Although many hooks
were discussed, version 0 may defer using some of them.

A key open issue is if the protocol requires serializability, i.e., that
all proposals are acted on in the same order at all conference session
managers involved in a session.  We maintained that a sufficient measure
of tight control can be enforced without serializability, and without
requiring absolute global state consistency.  To reduce conflicts,
multicast Propose messages to all others, even if not involved in the
accept phase.



Policies

Slide 20 introduced the main policies we expect to associate with a
session.  Underlined options represent the default choices, should no
policy be chosen.  We clarified that members are always allowed to leave
a session, regardless of the termination policy.  In fact there was a
motion to replace explicit session termination by implicit termination
when the membership count drops to zero, or after some duration beyond
when the membership goes to zero (this would avoid odd behavior caused
by the non-serializability of proposals).  On a similar note, we may
want to support a policy where one member is able to delete all other
members in order to terminate a session.

We discussed the rigidity of session policies and the need to determine
if different session policies conflict with one another, especially with
regard to ``static'' sessions (e.g., unchangeable sessions in terms of
their members, policies and media components).

The concern was that if there are communication failures that prohibit
approval for a session change (e.g., when the policy is that all must
approve), that this would result in a deadlock, a malfunctioning session
that does not terminate, or a scenario where resources are never
returned.  Clearly, in filling in the protocol details we will need to
differentiate between the receipt of a reject reply versus no reply at
all.  We will also need to state how policies will be handled (possibly
become more relaxed) in the event of a communication failure.  The
communication failure may be due to an intermittent lapse in
connectivity, to a person leaving their workstation unattended and not
being able to immediately reply to a query, or to the member having left
the conference at a network failure point and consequently being in the
wrong state.  It was felt that a conference session manager should
behave like TCP reset after a failure and retain no previous state.

                                   6





Even though we proposed an initially small set of policy choices, the
richness and completeness of this set needs further scrutiny.  To decide
where version 0 falls on the session style continuum, we solicit input
on suggested policies and their default values.  Additionally, to what
level of granularity should we institute policies?  Do we need to have
global policies?  Per-operation policies?  Per-initiator policies?  Will
policies be shared with media agents and other system components?

A good deal of discussion centered around policies about who may make
proposals, since non-members may be restricted from initiating
proposals, and in some cases not all members are proposers.  These
policies apply to changes in general, and are separate from who is
needed to approve proposals (e.g., coordinate a vote or approve an
initiation request).  The solution proposed was that a non-member find a
sponsor for a proposal, ensuring the notion of trusted membership.
However, is this approach too stringent?  Because of the premium on
being a member versus a non-member, there is also interest in making
assurances that one person isn't impersonating another.

More specifically, the issue boiled down to the question of joining a
session.  How does one join?  Who does one contact?  Again, the idea is
to assign a ``doorman'' or ``doormen.''  For version 0, to support an
open session in the sd style, a doorman could simply say yes all the
time.  Similarly, is there a more straightforward approach out there?


Outstanding Issues

How does floor control interact with session control?  Is the notion of
floor control its own protocol?  With its own messages?  We are looking
to other projects, such as MiCE, to advise us on this.

Could the negotiation protocol be used for other purposes, such as a
calendar scheduler, booking service, or even to measure agreement over
topics during an ongoing conference?  We are interested in someone
studying the range of related applications for the MMUSIC protocol.


Attendees

George Abe               [e-mail]
Chris Adie               [e-mail]
Axel Belinfante          [e-mail]
Lou Berger               [e-mail]
Jim Binkley              [e-mail]
Carsten Bormann          [e-mail]
Robert Braden            [e-mail]
Stefan Braun             [e-mail]
Michael Brescia
Les Clyne                [e-mail]
Walid Dabbous            [e-mail]
Steve DeJarnett          [e-mail]

                                   7





Ed Ellesson              [e-mail]
Hans Eriksson            [e-mail]
Julio Escobar            [e-mail]
Deborah Estrin           [e-mail]
Osten Franberg           [e-mail]
David Ginsburg           [e-mail]
Ron Greve                [e-mail]
Mark Handley             [e-mail]
Geert Heijenk            [e-mail]
Rune Hjelsvold           [e-mail]
Frank Hoffmann           [e-mail]
Xinli Hou                [e-mail]
Sascha Ignjatovic        [e-mail]
Phil Irey                [e-mail]
John Johnston            [e-mail]
Thomas Kaeppner          [e-mail]
Peter Kirstein           [e-mail]
Jim Knowles              [e-mail]
John Larson              [e-mail]
Mark Laubach             [e-mail]
Allison Mankin           [e-mail]
David Marlow             [e-mail]
Shehzad Merchant         [e-mail]
Donald Merritt           [e-mail]
Topi Miettinen           [e-mail]
Paul Milazzo             [e-mail]
Ronny Nilsen             [e-mail]
Zbigniew Opalka          [e-mail]
Jorg Ott                 [e-mail]
Mark Prior               [e-mail]
J. Mark Pullen           [e-mail]
Eve Schooler             [e-mail]
Henk Sennema             [e-mail]
A. Velu Sinha            [e-mail]
Kenneth Smith            [e-mail]
Kamlesh Tewani           [e-mail]
Claudio Topolcic         [e-mail]
Antoine Trannoy          [e-mail]
Thierry Turletti         [e-mail]
Guido van Rossum         [e-mail]
Dono van-Mierop          [e-mail]
Mario Vecchi             [e-mail]
Abel Weinrib             [e-mail]



                                   8