CURRENT_MEETING_REPORT_ Reported by Eve Schooler/Information Sciences Institute An on-line copy of the minutes and the accompanying slides are available in the directory ftp.isi.edu:confctrl/minutes as files ietf.3.94 and slides.3.94.tar. The MMUSIC Working Group held two sessions at the Seattle IETF, both of which were multicast on the MBone. The first four presentations were aimed at showing the convergence of ideas about the framework and protocols needed for session control in the Internet. These were followed by an update on the status of the agreement protocol, the impact of the WWW on session creation and rendez vous, the relevance of reliable multicast to the Internet MMUSIC problem, and finally an assessment of the working group's direction. From formal and informal conversations with working group participants, it was clear that these ideas are ready to be codified and written down. Conference Control Channel Protocol (CCCP) The slides from Mark Handley's presentation (slides.3.94.a.tar) follow these minutes. One highlight from Mark's talk was the concept that the communication among distributed session managers, and also between a session manager and its media agents, could be facilitated by a session-wide multicast channel. The same channel would be used for both ``horizontal'' and ``vertical'' messaging, with the multicast TTL set to a small value (like 0 or 1) to limit distribution of local media-agent addressed messages. There was debate, however, about the extent to which the horizontal and vertical protocols should be or need to be similar. A naming/addressing convention was also presented that would help users build applications on top of the bus abstraction and that would assist media agents to filter messages. It was noted that the CCCP approach seemed complementary to the idea of an agreement algorithm on which a session service could be built. Although it has been pointed out before that different session functions may require different levels of reliability from the transport service, and thus may need a flexible communication library, in this discussion that idea was extended further. The observation was made that, for a particular function being performed on a session, the degree of reliability may not be a uniform choice across all session participants. An example might be the need for a multiplexer (a.k.a. a ``quad box'') to receive a floor control announcement more reliably than a general user, since the multiplexer is an in-the-network service that is more critical to the smooth operation of the session. Finally, since we are interested in scalable session control solutions, there was agreement that the session control protocol should scale at least as well as the application that it is controlling. More details on this work can be found in a paper available in the MMUSIC archive area, ftp.isi.edu:confctrl/bib/cccp/*. Flow Synchronization Protocol The slides from Julio Escobar's presentation follow these minutes. Julio gave a brief overview of the flow synchronization protocol, a protocol that was designed to provide common delay for synchronized processes across the network. Its strengths include that it allows very flexible synchronization groups (destination processes that may or may not reside on the same host), and also that it is highly adaptive, since Internet operation leads to changes in delay predictions among different destinations. The focus of the talk was twofold: how well the control architecture of the synchronization protocol maps to our ideas in the MMUSIC group about modularized session managers and media agents, and additionally how it relates to the use of an agreement protocol. Julio took the session state needed by the synchronization protocol and classified it according to the agreement algorithm notation. The distinction was made between session-wide parameters, typically established and owned by an initiator, and local parameters that are owned by each individual destination process. The implied session policy was that only the owner of each piece of session state may change it or may announce it. Thus, the synchronization protocol fits quite well under a scheme of eventual consistency. Evolution of MMCC: Session Control Revisited The slides from Eve Schooler's presentation (slides.3.94.b.ps) follow these minutes. Eve presented the architectural framework behind the ISI session orchestration tool, mmcc, and discussed the ongoing evolution of its session control protocol. The main goals of the discussion were to identify similarities and differences among the various session control approaches, and to suggest a synthesis of ideas. A few key points centered around functional requirements. The first was the need to separate session creation from session invitations or joins. Another was that there should be no distinction between the session attributes that can be set at session creation, and those that can be set/changed at any point throughout the lifetime of the session. This relates to the general question, ``what set of descriptors constitutes a session?'' The answer is needed to allow alternate session creation schemes for user rendez vous. In addition, it was argued that the notion of a floor control agent need not be thought of as distinct from a session manager. Although the communication requirements of such an agent exemplify why we need both session-manger-to-session-manager communication and session-manager-to-media-agent communication, this same degree of coordination is required for other functions (e.g., configuration choices such as an encoding scheme) beyond what is traditionally considered floor control. Other issues raised were: the tradeoffs between a classic packet format and string-based messaging, how to characterize media agents, QOS, and session policies as part of a session description, the movement toward an adaptive soft-state approach (periodic refresh) and building a group consensus service on top of it, current options for cross-module communication, and incorporating multicast. Session Control Thoughts for a Non-Unix Conferencing Environment The slides from Charley Kline's presentation (slides.3.94.c.ps) follow these minutes. This past month saw the public release of Maven, an audio conferencing application designed for the Macintosh platform. Charley outlined several of the problems unique to the development environment (e.g., lack of multicast, OS differences) and their influence on Maven's implementation. During the presentation, he summarized the current state of session control among MBone tools and contrasted this with a suggested common protocol for session control interaction. One suggestion was to capitalize on the change within the RTP specification to separate the control port from the data port, and to use the RTCP port for an extended collection of session control functionality. (In off-line discussions about layerist philosophy, there was also the proposal that RTCP was intended for transport control, and that it would make more sense to have a different port be used for session control.) While there appeared to be firm consensus on the modularity of the architecture required for session control, there was ongoing dialog about what information needs explicitly to be shared across the boundaries of the modules. For example, it was argued that Maven might like to display the text of the participants' names, so that it could highlight who was speaking when. On the other hand, to avoid duplication of session information, the text of each participant's name might be owned by the session manager, and highlighted when contacted by the audio media agent to do so. Naturally, this led into a debate about who should own what information, how to share GUIs, and if it is economical from an interactivity standpoint to impose added delay for users to wait for IPC among session and media agents. A related discussion was about the choice for the protocol needed to communication between session managers and media agents. The present options we have are Tk/Tcl, which does in fact run on PCs and Macs, SMTP, or other forms of inter-process communication. Although it might appear that we do not have to standardize the inter-session-manager-media-agent link, it certainly would go a long way to promote interoperability between media agents and session agents that are created by different individuals. As for whether or not the horizontal and vertical protocols should be the same, it was noted that they have very different scaling properties, and are likely to have different distribution needs by virtue of locality. Managing Shared Ephemeral Teleconferencing State: Policy and Mechanism The slides from Abel Weinrib's presentation (slides.3.94.d.ps) follow these minutes. Abel presented an update on the agreement algorithm work that Scott Shenker had introduced at the last IETF meeting. As has been discussed in previous MMUSIC Working Groups, the agreement algorithm provides the foundation for the session control protocol that allows distributed session control agents to jointly manage the shared session state. While similar in basic outline to the earlier proposal, the policy specification and algorithm have undergone some significant changes. There now exist two new types of membership, with different types of members receiving different levels of correctness. In particular, eventual members are guaranteed to share a common view of the eventually correct state E and critical members are guaranteed to share a common view of the critical state C when voting on changes to the state in D. Algorithms have been developed for both a reliable communications infrastructure and unreliable multicast. With reliable communications, locking is used to guarantee the correctness related to changes in critical state, while eventual consistency is guaranteed by sending out announcements that are ordered by timestamps by the recipients. For unreliable multicast communications, announcements of new state are multicast to the group, with back off and suppression of old state messages to improve scalability. More details on this work can be found in a paper available in the MMUSIC document archive, ftp.isi.edu:confctrl/docs/agree.ps. Session Advertisement and Media on Demand via WWW The slides from Bill Fenner's presentation (slides.3.94.e.ps) follow these minutes. Bill described two ways in which real-time audio/video sessions are already being incorporated into WWW. The first approach was designed by Bill as a proof of concept and is based on the creation of an application-specific MIME type for session advertisement in WWW. Two programs were created to assist with this; the sd-listen program captures session directory announcements (from LBL's sd tool) and the sd-launch program is used to spawn the requested sessions. One complication is that by advertising a session using WWW, the multicast TTLs for scoping may not work properly. The second approach uses WWW to deliver media on demand, and was developed by Anders Klemets. It supplies previously recorded sessions or sound files. Although it avoids the multicast TTL problem, since it is unicast-based, there is some issue that the server machine is in some sense co-opted to transmit a session that was initiated elsewhere. Synchronous Collaboration with WWW The slides from Thane Frivold's presentation (slides.3.94.f.ps) follow these minutes. Thane described the Collaborative Multimedia Environment (COMET) project, which takes the persistent document paradigm of WWW and supplements it with synchronous dynamic sessions. The result is shared document collaborations. A conference specification is stored as part of a Mosaic document. By leaving coordinates in documents about authors and other session state, Mosaic is able to launch a variety of session-related applications, including the ones that originally produced the document. The architecture includes a session control manager that distributes conference requirements (applications, data, participants) as well as instantiates conferences. Although the protocol that it uses is still evolving, it is ASCII-based and supplies conference directives as Tcl procedures. Eventually, the intent is to incorporate a suite of session policies, not only on a per session basis, but also on a per person basis. Membership Protocols for Conference Control The slides from Bala Rajagopalan's presentation (slides.3.94.g.ps) follow these minutes. Bala focused on the fact that membership management is the basis for many conference control functions, and that proposals for reliable multicast appear too weighty for these tasks. To design a membership management protocol, one must consider membership in the presence of failures, the impact of scalability, and how communication latency grows with group size. Although there is an inherent trade-off between scalability and control, a possible conference control framework would allow the ``type'' of a conference to be established at initiation through policy selection, and gracefully loosen these policies as a session scales. The ``type'' could itself specify how the control policy changes with size, though this may be difficult to achieve in practice. The membership problem is difficult because consistency of information at each member at every instant is impossible. Eventual consistency is more obtainable under certain definitions of membership, though even eventual consistency may not be simple to achieve when certain network conditions occur. It is critical that in formulating a conference control model that we specifically accommodate real-world network anomalies, such as session fragmentation. Attendees Brian Adamson adamson@itd.nrl.navy.mil Mark Allyn allyn@netcom.com Richard Bantel rb@mtsol.att.com Stephen Batsell batsell@itd.nrl.navy.mil Eric Bennett reb@aads.com Larry Blunk ljb@merit.edu Carsten Bormann cabo@informatik.uni-bremen.de Stephen Casner casner@isi.edu Andrew Cherenson arc@sgi.com Cyrus Chow cchow@ames.arc.nasa.gov Richard Cogger R.Cogger@cornell.edu Eric Crawley kaufman@scrc.symbolics.com Jon Crowcroft jon@cs.ucl.ac.uk David Crowe crowed@osshe.edu Glen Daniels gub@elf.com Sandip Dasgupta sandip@cup.hp.com Chuck deSostoa chuckd@cup.hp.com Michael Elkins elkins@areo.org Julio Escobar jescobar@bbn.com Roger Fajman raf@cu.nih.gov William Fenner fenner@cmf.nrl.navy.mil William Fink bill@wizard.gsfc.nasa.gov Sally Floyd floyd@ee.lbl.gov Ron Frederick frederick@parc.xerox.com Thane Frivold frivold@erg.sri.com Steve Fulling fulling@cs.orst.edu Paul Goransson paulg@wellfleet.com Mark Handley mhandley@cs.ucl.ac.uk Ken Hayward Ken.Hayward@bnr.ca Don Hoffman hoffman@eng.sun.com Ellen Hoffman ellen@merit.edu Jinho Hur jhhur@cosmos.kaist.ac.kr Phil Irey pirey@relay.nswc.navy.mil Kyungran Kang krkang@cosmos.kaist.ac.kr Yasuhiro Katsube katsube@mail.bellcore.com Berry Kercheval kercheval@parc.xerox.com Peter Kirstein P.Kirstein@cs.ucl.ac.uk Charley Kline cvk@uiuc.edu Jim Knowles jknowles@binky.arc.nasa.gov Andrew Knutsen andrewk@sco.com Padma Krishnaswamy kri@cc.bellcore.com Ted Kuo tik@vnet.ibm.com Paul Lambert paul_lambert@email.mot.com Ben Levy seven@ftp.com Arthur Lin yalin@srv.pacbell.com Allison Mankin mankin@cmf.nrl.navy.mil Ken Masica masic@es.net Yosi Mass yosi@ubique.co.il Daniel McDonald danmcd@itd.nrl.navy.mil Marjo Mercado marjo@cup.hp.com Donald Merritt don@arl.army.mil David Meyer meyer@ns.uoregon.edu Greg Minshall minshall@wc.novell.com Steve Minzer minzer@bellcore.com Joseph Pang pang@bodega.stanford.edu Amy Pearl amy.pearl@eng.sun.com Mark Prior mrp@itd.adelaide.edu.au J. Mark Pullen mpullen@cs.gmu.edu Bala Rajagopalan braja@qsun.att.com Martina-Angela Sasse a.sasse@cs.ucl.ac.uk Eve Schooler schooler@isi.edu Katsuhiro Sebayashi sebayasi@tnlab.ntt.jp Paul Serice serice@cos.com Scott Shenker shenker@parc.xerox.com Ming-Jye Sheu msheu@vnet.ibm.com Allyson Showalter allyson@nsipo.arc.nasa.gov Michael Speer michael.speer@sun.com John Stewart jstewart@cnri.reston.va.us Walter Stickle wls@ftp.com Dave Thompson davet@ncsa.uiuc.edu Abel Weinrib abel@bellcore.com Linda Winkler lwinkler@anl.gov Shian-Tung Wong shian@dcsd.sj.nec.com Dan Wood dwood@bbn.com John Wroclawski jtw@lcs.mit.edu Shinichi Yoshida yoshida@sumitomo.com Charles Young Charles.E.Young@att.com