Subject: MMusic Minutes from Amsterdam IETF

From: schooler
Date: Thu, 29 Jul 1993 12:24:03 -0700

Here are the latest notes from the meetings in Amsterdam.
As we still have a day to make modifications, your comments on 
the accuracy of these minutes are encouraged.  

Thanks,
Eve and Abel

~~~~~~~~~~~~~

These notes were prepared by Eve Schooler, [email-masked], and
accompany the slides, venera.isi.edu:confctrl/minutes/slides.7.93.ps 
(there are six slides to a page).

      Multiparty Multimedia Session Control WG (mmusic)
                Minutes from the 27th IETF
                  Amsterdam, Netherlands
                   July 12 and 13, 1993

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

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.

1. 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.

1.1 Terminology, Framework, Requirements.

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

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

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

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 3rd approach, where the conference session manager is part
of one monolithic application, is equally valid.  The WG 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 affect on reservations in the network, nor reservation
strategies (optimistic vs 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
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/off media agent data flows.

1.2 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:

 - what transport platform is needed to support a general purpose
   negotiation service? 
 - to what degree do we need reliable multicast?
 - 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.

1.3 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
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.

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

2.1 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
mobile-ip WG?

2.2 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.

2.3 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:

- Add an optional reason field to the Reply message: to make informed 
  decisions about initiating another round of proposals after receiving
  a reject.  Useful for handling error messages when not in correct
  state to receive 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.  

- Differentiate between an Announce message that:

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

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

2.4 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 theirs 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.

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?

2.5 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.

3. Attendees.

George Abe		[email-masked]
Chris Adie		[email-masked]
Axel Belinfante		[email-masked]
Lou Berger		[email-masked]
Jim Binkley		[email-masked]
Carsten Bormann		[email-masked]
Bob Braden		[email-masked]
Stefan Braun		[email-masked]
Mike Brescia		[email-masked]
Stuart Clayman		[email-masked]
Les Clyne		[email-masked]
Walid Daboous		[email-masked]
Steve DeJarnett		[email-masked]
Ed Ellesson		[email-masked]
Hans Eriksson		[email-masked]
Julio Escobar		[email-masked]
Deborah Estrin		[email-masked]
Osten Franberg		[email-masked]
Robert Franberg		[email-masked]
David Ginsburg		[email-masked]
Ronald Greve		[email-masked]
Mark Handley		[email-masked]
Geert Heijenk		[email-masked]
Rune Hjelsvald		[email-masked]
Frank Hoffmann		[email-masked]
Xinli Hou		[email-masked]
Sascha Ignjatovic	[email-masked]
Phil Irey		[email-masked]
John T. Johnston	[email-masked]
Thomas Kaeppner		[email-masked]
Peter Kirstein		[email-masked]
Jim Knowles		[email-masked]
John Larson		[email-masked]
Mark Laubach		[email-masked]
Allison Mankin		[email-masked]
Dave Marlow		[email-masked]
Shahzad Merchant	[email-masked]
Donald Merritt		[email-masked]
Topi Miettinen		[email-masked]
Paul G. Milazzo		[email-masked]
Ronny Nilsen		[email-masked]
Zbigniew Opalka		[email-masked]
Jorg Ott		[email-masked]
Mark Prior		[email-masked]
Mark Pullen		[email-masked]
Eve Schooler		[email-masked]
Henk Sennema		[email-masked]
Velu Sinha		[email-masked]
Ken Smith		[email-masked]
Kamlesh Tewani		[email-masked]
Claudio Topolcic	[email-masked]
Antoine Trannoy		[email-masked]
Thierry Turletti	[email-masked]
Guido van Rossum	[email-masked]
Dono Van-Mierop		[email-masked]
Mario Vecchi		[email-masked]
Abel Weinrib		[email-masked]

---

From: touch
Date: Tue, 10 Aug 93 11:01:03 -0700

>the encapsulation of the transport (point-to-point or multipoint) in a

I'd like to suggest that single-medium transport is an artifact of some  
current technology*. Counterexamples include PictureTel CODEC's, which permit  
in-band audio with video, and instrumentation (visualization of audio going  
to an oscilloscope). I prefer "transport association" to "media association"  
- it reflects the grouping of access to a transport stream, but doesn't  
require single-media streams.

(* - including Bellcore's Touring Machine, which I have experience porting to  
the NeXT and the IETF-loose-style conferencing, in which nevot/vat/etc and  
nv/pvp are considered distinct).

	conference = temporal and control association of resources 

			(people and/or equipment)
		consists of a session and a set of transport associations
	session = control component of a conference
	transport association = data component of a conference 

A while back I posted a note that summarized the previous suggestion of 

	control
	media assoc
	policy
	
and replaced it with
	control
	data (transport)
	meta-control (control of control, member control, etc.)
	
"Policy" is an overloaded term that can mean transport policy, drop policy,  
etc. It's more than control of control, because it's also member control,  
transfer of control, etc. If data is first-order information, and control is  
second order, then it appears we're stuffing all higher orders into "policy".  
I'd like to suggest "metacontrol" instead, or something equivalent.

Just my 2 cents.

Thanks.

Joe Touch
[email-masked]