home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / mmusic / confctrl-minutes-93mar.txt < prev    next >
Text File  |  1993-08-12  |  16KB  |  406 lines

  1. Editor's Note: The CONFCTRL BOF became the MMUSIC WG on 6/24/93.
  2.  
  3. CURRENT_MEETING_REPORT_
  4.  
  5.  
  6. Reported by Eve Schooler/Information Sciences Institute
  7.  
  8. Minutes of the Conferencing Control BOF (CONFCTRL)
  9.  
  10. These Minutes were prepared by Eve Schooler from notes provided by Abel
  11. Weinrib of Bellcore and Deborah Estrin of USC/ISI.
  12.  
  13. Introduction and Presentations
  14.  
  15. Two CONFCTRL sessions were held at the Columbus IETF. The first meeting
  16. was used to provide an overview of Conference Control efforts both
  17. within and outside of the IETF. Inside the IETF, the CONFCTRL Group was
  18. spawned by the Remote Conferencing Architecture BOF (REMCONF). Outside
  19. the IETF, interest in conference control, sometimes referred to as
  20. connection management, has been ongoing for some time.  Thus far, the
  21. CONFCTRL mailing list has collected a sizable bibliography containing
  22. references to many of the early and ongoing research projects in this
  23. area.
  24.  
  25. Most of the first session was used for presentations on different
  26. CONFCTRL schemes.  The intent of the presentations was to flesh out
  27. design assumptions, tradeoffs, complexity, scalability, etc.  The
  28. systems were classified according to several parameters:  whether they
  29. (1) concentrate more on groupware conferencing (shared editors,
  30. whiteboards) than on real-time audio/video conferencing, (2) provide
  31. session control of packet-based real-time media versus analog real-time
  32. media, (3) rely on centralized versus distributed session management,
  33. and/or (4) observe loose versus tight session control.
  34.  
  35.  
  36.    o Ruth Lang of SRI reported on the Collaborative Environment for
  37.      Concurrent Engineering Design (CECED).
  38.  
  39.    o Abel Weinrib of Bellcore focused on the session elements and
  40.      functions supported by Bellcore's Touring Machine.
  41.  
  42.    o Hans Eriksson of SICS discussed the CoDesk architecture.
  43.  
  44.    o Don Hoffman of Sun Microsystems outlined the model used for the
  45.      COCO project.
  46.  
  47.    o Chip Elliott of BBN presented his work on VideoTeam and the Sticky
  48.      CONFCTRL protocol on which it relies.
  49.  
  50.    o Lakshman Krishnamurthy of University of Kentucky summarized the
  51.      versatile Multi-flow Conversation Protocol.
  52.  
  53.    o Eve Schooler of ISI gave an overview of the MMCC tool and its
  54.      Conference Control Protocol.
  55.  
  56.                                    1
  57.  
  58.  
  59.  
  60.  
  61.  
  62.    o Thierry Turletti's ivs program was discussed as a contrasting
  63.      example that uses loose-style session management.
  64.  
  65.  
  66. Synthesis of CONFCTRL approaches
  67.  
  68. The second session was used to identify pervasive CONFCTRL themes, and
  69. to question the applicability of the various solutions to the Internet.
  70. The main objective was to narrow the scope of the problem en route to
  71. the design of a generic CONFCTRL protocol.  Observations were culled not
  72. only from the presentations at the IETF but also from templates that
  73. were filled out prior to the meeting.  The templates included Dave
  74. Lewis' write up of the UCL PREPARE project, a description of the ZAPT
  75. project by Joe Touch of ISI, a contribution from Jack Jansen of CWI
  76. about the Meeting project, and Fengmin Gong's template on the MCNC
  77. CONCERT Video Network Migration effort.
  78.  
  79. Of particular interest were implementors' comments about the aspects of
  80. their approaches which were hard, easy, or warranted change.  Except for
  81. a lone comment about the ease of implementation of floor control, there
  82. were several recurrent themes regarding implementation difficulties:
  83.  
  84.  
  85.    o It is difficult to design a CONFCTRL protocol that balances
  86.      simplicity with a high degree of semantic flexibility, e.g., Jansen
  87.      of CWI concluded that different conferencing styles require
  88.      entirely separate CONFCTRL protocols.
  89.  
  90.    o A distributed model comes with distributed system complexities:
  91.  
  92.       -  Support for causality of multiway message exchanges.
  93.       -  Recovery from temporary network failures.
  94.       -  Propagation of consistent state information.
  95.  
  96.      The solutions proved to be cumbersome, unexpectedly hard and often
  97.      times ``tricky''.
  98.  
  99.    o The underlying transport (that carries session control information)
  100.      comes at a price, e.g., the overhead of one RPC implementation led
  101.      the PREPARE project to shift to a different, lighter
  102.      implementation.
  103.  
  104.    o There is room for improved media integration, e.g., asymmetric
  105.      flows are difficult to characterize at setup, there is a need for
  106.      more powerful control over presentation of media streams.
  107.  
  108.  
  109. Most experimental systems either are or began as LAN-based conferencing
  110. systems.  However, it is clear that many, if not all, are aiming for WAN
  111. operation.  Although the tools that currently populate the MBONE rely on
  112. loose-style session control, in the past most experimentation has taken
  113. place with tightly controlled session models -- though this is clearly
  114. changing.  The Group speculated that the predominance of tight-control
  115.  
  116.                                    2
  117.  
  118.  
  119.  
  120.  
  121.  
  122. systems may be a function of the interest in supporting ``coordinated''
  123. telecollaborations, which are readily modeled using a tight-control
  124. framework, whereas the emergence of loose-control systems may be a
  125. reflection of the relative ease with which they are implemented.
  126.  
  127. Systems were clearly differentiated in their approaches to
  128. interconnectivity among participants, both for session and for media
  129. topology.  In certain cases, symmetry exists for N-way communication
  130. capabilities, while in other cases conferees are asymmetrically
  131. interconnected, relying on an initiator, moderator, filter/reflector or
  132. a privileged set of designees to coordinate communication on behalf of
  133. others.  Explicit versus implicit communication is another
  134. distinguishing feature; this relates to whether or not the session has
  135. policies attached to it, such as who dictates membership rules, the
  136. extent to which session information is disseminated or if participant
  137. information is meant to be kept globally coherent.  Finally, it was
  138. observed that the decision to model the system in a centralized or
  139. distributed fashion influenced the degree of messaging synchrony and
  140. causality.
  141.  
  142. Group Scope, Framework and Functional Taxonomy
  143.  
  144. There was rough consensus on the definition of conference control as the
  145. management and coordination of multiple sessions and their multiple
  146. users in multiple media.  It was also agreed that the focus of the Group
  147. is to design a ``session layer'' protocol to perform these functions.
  148. However, the Group debated the utility of designing a
  149. ``teleconferencing'' session protocol specifically for the coordination
  150. of users' ``media'' versus designing a Group negotiation protocol that
  151. is extensible to act as a conduit for media details.
  152.  
  153. The Group recognizes that it cannot set out to support all conferencing
  154. scenarios.  However, it proposes to support one loose style protocol (a
  155. la Xerox PARC's nv, INRIA's ivs, BBN's dvc, LBL's vat, UMass' nevot) and
  156. one tight style protocol (for negotiated and potentially private
  157. sessions).  How loose and how tight?  To answer this, the list of
  158. conversation styles must be mapped (from the last IETF Minutes) into
  159. their underlying CONFCTRL session protocols.
  160.  
  161. As an example of how a tight-control approach to session management
  162. might integrate with already existing MBONE tools, an X-based version of
  163. ISI's MMCC conference control tool was demonstrated at the IETF. MMCC
  164. was used to explicitly invite a specific set of participants (versus
  165. having a wide-open session), to distribute multicast addresses and a
  166. shared encryption key among those participants, and to initiate as well
  167. as tear down sessions comprised of nv, vat and/or BBN's newly released
  168. PictureWindow.
  169.  
  170. Although it was emphasized that the goal of the Group is to design a
  171. session protocol, the Group conceded that there is a need for a common
  172. framework within which it can talk about conferencing control.  The
  173. framework that arose from discussion, looked as follows:
  174.  
  175.  
  176.                                    3
  177.  
  178.  
  179.  
  180.  
  181.  
  182.  
  183.            User A                                       User B
  184.  
  185.        +-------------+                              +-------------+
  186.        |             |                              |             |
  187.        | Application |                              | Application |
  188.        |             |                              |             |
  189.        +------+------+                              +------+------+
  190.               |                                            |
  191.        +------+------+                              +------+------+
  192.        |             |                              |             |
  193.        |   Session   |<----------------------------->|   Session   |
  194.        |             |      "Session Protocol"       |             |
  195.        +---+--+--+---+                              +---+--+--+---+
  196.           /   |   \                                     /  |   \
  197.          /   ...   \                                   /  ...   \
  198.    +-------+     +-------+                       +-------+    +-------+
  199.    | Media | ... | Media |<---------------------->| Media |    | Media |
  200.    | Agent |     | Agent |     "Media Stream"     | Agent |    | Agent |
  201.    +-------+     +-------+                       +-------+    +-------+
  202.  
  203.  
  204.  
  205. The premise is that the session protocol would be distributed in nature,
  206. and would accommodate multiple user sessions (even though the diagram
  207. depicts only two conferees).  There is a firm separation between the
  208. session protocol and media transport protocols.  Thus, it is immaterial
  209. whether the media transport is packet-based or analog.  Generic session
  210. state would include membership and policy information.
  211. Application-domain specific state might include media interconnectivity
  212. (topology) and media configuration (data encodings, rates).  Although
  213. needing further refinment, the list of session functionality provided to
  214. the end systems and reflected in the session protocol would encompass:
  215.  
  216.  
  217.    o Create/Destroy Session
  218.    o Add/Delete Member
  219.    o Set Policy
  220.  
  221.       -  Who may join
  222.       -  Who may invite
  223.       -  Who may set policies
  224.       -  Etc.
  225.  
  226.    o Add/Change Application-Domain Specific State
  227.  
  228.       -  Media interconnectivity
  229.       -  Media configuration
  230.  
  231.    o Floor Control?
  232.    o Prescheduling?
  233.  
  234.  
  235. Polling the interest of the BOF participants, it was found that 75% were
  236.  
  237.                                    4
  238.  
  239.  
  240.  
  241.  
  242.  
  243. interested in solving the session protocol problem, 40% also would be
  244. interested in defining or standardizing the
  245. media-agent-to-session-entity interface, and 30% were interested in
  246. configuration management issues.
  247.  
  248. Terminology
  249.  
  250. It became evident that there are no set definitions for terms such as
  251. conference, connection, session, media agents, etc.  Many of the systems
  252. presented during the BOF and described in the templates used these terms
  253. differently.  Thus, a CONFCTRL terminology reference guide needs to be
  254. developed.
  255.  
  256. The Group had been interchanging the phrases session control, session
  257. management, connection control and connection management, but later
  258. agreed that ``connection'' is too ambiguous since it is used at any
  259. number of levels in the protocol stack.  Connection was replaced by the
  260. term ``session'', and was broadly defined as an association of members
  261. for control purposes.  However, it was later argued that session looks
  262. too much like an OSI term.  The term ``conference'' was also felt to be
  263. too application specific.  Therefore, the Group is open to suggestions
  264. for a better name.
  265.  
  266. It was suggested (although not entirely resolved) that ``media agents''
  267. handle the media specifics associated with a session.  ``Media'' could
  268. be considered any data streams that involve communication.  It was also
  269. suggested that floor control is deemed the responsibility of a media
  270. agent when it concerns a single media agent, but the responsibility of
  271. the session entity when it requires coordination across different media
  272. agents (e.g., video to follow audio).
  273.  
  274. The Group also differentiated between two meanings of configuration; the
  275. static end-system description, including hardware and software
  276. capabilities, and the per-session description.
  277.  
  278. Liaisons
  279.  
  280. The CONFCTRL Group is committed to tracking the progress of related
  281. efforts, both within and outside the IETF. An important IETF linkage is
  282. to leverage off ongoing work in the Audio/Video Transport Working Group
  283. (AVT), which is nearing completion of the Real-time Transport Protocol
  284. (RTP) specification.  During the first two AVT sessions, there was
  285. considerable discussion about RTCP, the control protocol associated with
  286. RTP. Certain functions in RTCP were felt to violate ``layering''; they
  287. do not belong in the transport, but would live comfortably within the
  288. session level, e.g., text strings of session participants.  The Group
  289. will need to follow closely the outcome of these developments,
  290. especially if certain services are assumed to percolate into the session
  291. layer.
  292.  
  293. The MBONE is another strategic testing ground for a CONFCTRL solution,
  294. although its use should not preclude use of these ideas elsewhere, nor
  295.  
  296.  
  297.                                    5
  298.  
  299.  
  300.  
  301.  
  302.  
  303. should these ideas be tailored specifically to the MBONE. By mentioning
  304. MBONE it is really meant that the Group expects, in the long term, to
  305. have access to networks that support multicast and in the longer term to
  306. support real-time services.  The general Internet should suffice for
  307. now.
  308.  
  309. Individuals who volunteered to track developments in related areas
  310. include:
  311.  
  312.  
  313.   Ruth Lang             Directory Services
  314.  
  315.   Hans Eriksson         Multicast Developments
  316.  
  317.   Fengmin Gong          Resource Management/QoS
  318.  
  319.   Steve Casner          Audio/Video Transport
  320.  
  321.   Eve Schooler          Audio/Video Transport
  322.  
  323.   Paul Lambert          Security
  324.  
  325.   Stuart Stubblebine    Security
  326.  
  327.   Yee-Hsiang Chang      ATM
  328.  
  329.   Peter Kirstein        MIBs
  330.  
  331.  
  332. Action Items
  333.  
  334.  
  335.    o Make CONFCTRL bibliography available.
  336.    o Documentation:
  337.  
  338.       -  Terminology reference guide.
  339.       -  Refinement of functional taxonomy.
  340.       -  Turn Minutes into issues/framework document.
  341.       -  Mapping of conversation styles into session protocols.
  342.       -  Collect suggestions for a Group name change.
  343.  
  344.  
  345. Attendees
  346.  
  347. Lou Berger               lberger@bbn.com
  348. Monroe Bridges           monroe@cup.hp.com
  349. Al Broscius              broscius@bellcore.com
  350. Randy Butler             rbutler@ncsa.uiuc.edu
  351. Yee-Hsiang Chang         yhc@hpl.hp.com
  352. Brian Coan               coan@faline.bellcore.com
  353. Richard Cogger           R.Cogger@cornell.edu
  354. Simon Coppins            coppins@arch.adelaide.edu.au
  355. Dave Cullerot            cullerot@ctron.com
  356.  
  357.                                    6
  358.  
  359.  
  360.  
  361.  
  362.  
  363. Steve DeJarnett          steve@ibmpa.awdpa.ibm.com
  364. Ed Ellesson              ellesson@vnet.ibm.com
  365. Chip Elliott             celliot@bbn.com
  366. Hans Eriksson            hans@sics.se
  367. Deborah Estrin           estrin@isi.edu
  368. Francois Fluckiger       fluckiger@vxcern.cern.ch
  369. Jerry Friesen            jafries@sandia.llnl.gov
  370. Fengmin Gong             gong@concert.net
  371. Kenneth Goodwin          goodwin@a.psc.edu
  372. Mark Green               markg@apple.com
  373. Russ Hobby               rdhobby@ucdavis.edu
  374. Don Hoffman              hoffman@eng.sun.com
  375. Frank Hoffmann           hoffmann@dhdibm1.bitnet
  376. Michael Khalandovsky     mlk@ftp.com
  377. Peter Kirstein           P.Kirstein@cs.ucl.ac.uk
  378. Jim Knowles              jknowles@binky.arc.nasa.gov
  379. Lakshman Krishnamurthy   lakashman@ms.uky.edu
  380. Giri Kuthethoor          giri@ms.uky.edu
  381. Paul Lambert             paul_lambert@email.mot.com
  382. Ruth Lang                rlang@nisc.sri.com
  383. Patrick Leung            patrickl@eicon.qc.ca
  384. Allison Mankin           mankin@cmf.nrl.navy.mil
  385. Donald Merritt           Don@brl.mil
  386. Paul Milazzo             milazzo@bbn.com
  387. Robert Mines             rfm@sandia.llnl.gov
  388. Joseph Pang              pang@bodega.stanford.edu
  389. Geir Pedersen            Geir.Pedersen@usit.uio.no
  390. John Penners             jpenners@advtech.uswest.com
  391. Bala Rajagopalan         braja@qsun.att.com
  392. Michael Safly            saf@tank1.msfc.nasa.gov
  393. Eve Schooler             schooler@isi.edu
  394. Michael St.  Johns       stjohns@darpa.mil
  395. Stuart Stubblebine       stubblebine@isi.edu
  396. Sally Tarquinio          sallyt@gateway.mitre.org
  397. Claudio Topolcic         topolcic@cnri.reston.va.us
  398. Mario Vecchi             mpv@thumper.bellcore.com
  399. Abel Weinrib             abel@bellcore.com
  400. John Wroclawski          jtw@lcs.mit.edu
  401. Yow-Wei Yao              yao@chang.austin.ibm.com
  402.  
  403.  
  404.  
  405.                                    7
  406.