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 (lakshman@ms.uky.edu) 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 abe@infonet.com Chris Adie C.J.Adie@edinburgh.ac.uk Axel Belinfante Axel.Belinfante@cs.utwente.nl Lou Berger lberger@bbn.com Jim Binkley jrb@ibeam.intel.com Carsten Bormann cabo@cs.tu-berlin.de Robert Braden braden@isi.edu Stefan Braun smb@cs.tu-berlin.de Michael Brescia Les Clyne l.clyne@jnt.ac.uk Walid Dabbous Walid.Dabbous@sophia.inria.fr Steve DeJarnett steve@ibmpa.awdpa.ibm.com 7 Ed Ellesson ellesson@vnet.ibm.com Hans Eriksson hans@sics.se Julio Escobar jescobar@bbn.com Deborah Estrin estrin@usc.edu Osten Franberg euaokf@eua.ericsson.se David Ginsburg ginsb@us-es.sel.de Ron Greve rgreve@cs.utwente.nl Mark Handley mhandley@cs.ucl.ac.uk Geert Heijenk heijenk@cs.utwente.nl Rune Hjelsvold Rune.Hjelsvold@idt.unit.no Frank Hoffmann hoffmann@dhdibm1.bitnet Xinli Hou xinli@cs.utwente.nl Sascha Ignjatovic sascha@veda.co.at Phil Irey pirey@relay.nswc.navy.mil John Johnston john@berlioz.nsc.com Thomas Kaeppner kaeppner%heidelbg.vnet@ibmpa.ibm.com Peter Kirstein P.Kirstein@cs.ucl.ac.uk Jim Knowles jknowles@binky.arc.nasa.gov John Larson jlarson@parc.xerox.com Mark Laubach laubach@hpl.hp.com Allison Mankin mankin@cmf.nrl.navy.mil David Marlow dmarlow@relay.nswc.navy.mil Shehzad Merchant merchant@erg.sri.com Donald Merritt don@arl.army.mil Topi Miettinen tm86214@cs.tut.fi Paul Milazzo milazzo@bbn.com Ronny Nilsen Ronny.Nilsen@usit.uio.no Zbigniew Opalka zopalka@agile.com Jorg Ott jo@cs.tu-berlin.de Mark Prior mrp@itd.adelaide.edu.au J. Mark Pullen mpullen@cs.gmu.edu Eve Schooler schooler@isi.edu Henk Sennema sennema@sara.nl A. Velu Sinha avsinha@attmail.com Kenneth Smith kensmith@bnr.ca Kamlesh Tewani ktt@arch2.att.com Claudio Topolcic topolcic@cnri.reston.va.us Antoine Trannoy trannoy@crs4.it Thierry Turletti turletti@sophia.inria.fr Guido van Rossum guido@cwi.nl Dono van-Mierop dono_van_mierop@3mail.3com.com Mario Vecchi mpv@thumper.bellcore.com Abel Weinrib abel@bellcore.com 8