home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / mmusic / mmusic-minutes-94jul.txt < prev    next >
Text File  |  1994-11-02  |  10KB  |  226 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Abel Weinrib/Bell Communications Research
  5.  
  6. Minutes of the Multiparty Multimedia Session Control Working Group
  7. (MMUSIC)
  8.  
  9. An on-line copy of the minutes and the accompanying slides are available
  10. in the directory ftp.isi.edu:confctrl/minutes as files ietf.7.94 and
  11. slides.7.94.tar.
  12.  
  13. The Multiparty Multimedia Session Control (MMUSIC) Working Group held
  14. one session at the IETF meeting in Toronto.  This session focused on
  15. reports from implementors of a range of multimedia conferencing
  16. applications.  The goal was to identify common ground for
  17. interoperability.  The agenda included Dick Cogger who talked about
  18. architectural issues in CUSeeMe, a Macintosh-based conferencing tool.
  19. Ron Frederick spoke about the Jupiter project that is providing audio,
  20. video and shared windows for MOO systems.  Carsten Bormann presented a
  21. reliable multicast protocol similar to MTP that they have designed and
  22. implemented to support their Xy shared window system.  Ian Wakeman gave
  23. an update on the CCCP communication and control protocol being developed
  24. to support conference control.  Joerg Ott described the ITU T.gcc
  25. standardization efforts.  Abel Weinrib provided an update on an
  26. implementation of the agreement algorithm being developed by Ted Ko at
  27. Bellcore as a Masters project.  Finally, Eve Schooler spoke about
  28. interoperability, defining the various interfaces that, if standardized,
  29. would facilitate interoperation of different applications and media
  30. agents.
  31.  
  32.  
  33.  
  34. Architectural Issues in CUSeeMe
  35.  
  36. The slides from Dick Cogger's presentation follow these minutes.
  37.  
  38. In this talk, Dick Cogger argued for having an integrated user interface
  39. (UI) that is connected to conference control and central bandwidth
  40. management.  The major components of the CUSeeMe system include the user
  41. interface, conference control, and a bandwidth manager, along with
  42. modules for audio, video and a window for displaying slides; it also
  43. provides a plug-in interface that allows for the addition of other
  44. add-on applications.
  45.  
  46. The CUSeeMe system uses a reflector running on a UNIX system that
  47. simulates multicast.  It has been tempting to add additional
  48. functionality to the reflector.  Currently, the reflector prunes a
  49. stream back to its source to conserve bandwidth when no one wants to
  50. receive the stream, which is particularly valuable on low-bandwidth
  51. links.
  52.  
  53. Dick argued that the UI and conference control should interact so that
  54. the control status information can be used to control elements in the UI
  55. that indicate what other users are doing and what they are capable of.
  56. They have not yet come up with a clean separation that would decide
  57. whether this information should be sent in RTCP messages or as part of
  58. general session control.
  59.  
  60. Bandwidth management in CUSeeMe is based on a bandwidth cap that is
  61. adapted based on loss reports from receivers.  This approach may be
  62. problematic if there are heterogeneous receivers that have differing
  63. amounts of available bandwidth.  Audio is given priority (if anyone
  64. wants to hear you) and sending of video is subject to the cap (if anyone
  65. wants to see you).
  66.  
  67.  
  68. Jupiter Video Protocol
  69.  
  70. The slides from Ron Frederick's presentation (slides.7.94.a) follow
  71. these minutes.
  72.  
  73. The goal of the Jupiter project is to extend a MOO system (text-based
  74. social virtual realities) to include audio, video and shared windows.
  75. They are developing a local client that speaks RTP, HTTP, etc.  Each
  76. client is controlled by a TCP connection to the central MOO server.
  77. Currently, the client is running under UNIX and Windows; a Macintosh
  78. version will be done soon.
  79.  
  80. The MOO server plays a coordinating role.  It provides permanent storage
  81. of information, key management, multicast address management, and
  82. sharing of window state (whiteboard, etc.).  The central server also
  83. prunes media streams back to their sources if no one wants to receive
  84. them, and allows control of bandwidth.  Their longer term plan is to do
  85. a distributed server implementation to avoid the single point of failure
  86. and performance bottlenecks of the central server and to better cope
  87. with user communities spread across administrative domains.
  88.  
  89. The Jupiter client is really a media agent, having no inherent UI.
  90. Rather, the server downloads a window layout into the client, and widget
  91. events are sent back to the server for action.  The video client
  92. supports a ``videosend'' protocol that allows the server to request a
  93. list of available video sources, set the TTL, start a video stream from
  94. a source to a destination, stop a video stream (to a particular
  95. destination, or to all) and to set video attributes.  Video reception is
  96. supported by a ``videoPane'' widget that shows one video source of any
  97. size.
  98.  
  99.  
  100. Reliable Multicast and Groupware Applications
  101.  
  102. The slides from Carsten Bormann's presentation (slides.7.94.b) follow
  103. these minutes.
  104.  
  105. Carsten spoke about a reliable multicast protocol that they have
  106. developed.  The goal was to develop a multicast protocol built on top of
  107. IP multicast that is optimized for groupware applications.  In
  108. particular, their objectives included scalability (not linear
  109. algorithm), efficiency, robustness (perhaps more important than strict
  110. ``reliability'') and message ordering (to make the application
  111. programmer's life easier).
  112.  
  113. Their protocol, MTP2, is based on MTP (RFC 1301).  It has one master and
  114. many producers and consumers of messages.  Global ordering is sequenced
  115. by the master with use of a token, and the master can control the
  116. message rate by limiting the transmission of the token.  The protocol
  117. also supports atomicity, and addresses scalability with the use of
  118. unicast negative acknowledgments.  The protocol has a ``heartbeat,'' and
  119. after some number of heartbeats the sender discards the message.
  120. Additional features of the MTP2 protocol include request of message
  121. retransmission from anyone, not just the sender; allowing unsequenced
  122. messages as well as sequenced ones; and master loss recovery and
  123. migration.
  124.  
  125. The MTP2 protocol has been used for the Xy window sharing system, which
  126. is based on multicast from the Xy server to agents on each workstation.
  127. It also underlies the Sharekit application replication toolkit that
  128. allows the creation of cooperation-aware applications by layering
  129. Sharekit between the GUI and the application engine of applications
  130. structured in that way.
  131.  
  132.  
  133. CCCP Prototype
  134.  
  135. The slides from Ian Wakeman's presentation (slides.7.94.c) follow these
  136. minutes.
  137.  
  138. Ian gave an update on the CCCP protocol that was talked about at length
  139. during the Seattle IETF. There is an implementation of CCCP, and it has
  140. been used to create a floor control agent.  They plan to release the
  141. implementation in mid-August.
  142.  
  143.  
  144. ITU GCC Work
  145.  
  146. Joerg Ott talked about the work to standardize ``Generic Conference
  147. Control'' within the ITU. It should be released as a standard by early
  148. next year.  GCC coordinates membership and integrates applications,
  149. including functions to establish conferences, provide a conference
  150. roster and an application roster and registry, and manage conductorship.
  151. It does not support floor control.
  152.  
  153. GCC relies on BMCS, an underlying multicast communication service that
  154. offers reliability, optional global ordering, admission control,
  155. multiplexing and token management.  BMCS is realized with reliable
  156. flow-controlled transport on point-to-point links on a hierarchy of
  157. multipoint control units; the top MCU controls membership, etc.
  158.  
  159. Despite the considerable overlap in interests, the people working on GCC
  160. do not know what is going on at IETF, and we know little of what they
  161. are doing.  We are exploring the possibility of developing a liaison
  162. with this effort.
  163.  
  164.  
  165.  
  166. Agreement Service Update
  167.  
  168.  
  169. Abel Weinrib briefly discussed the work being done at Bellcore to create
  170. an ``agreement engine'' that implements the agreement algorithm which
  171. has been discussed at previous MMUSIC meetings.  Ted Ko from MIT is
  172. doing his Masters thesis on this topic at Bellcore.  It is envisioned
  173. that the agreement algorithm will form the foundation for a general
  174. session control protocol.
  175.  
  176.  
  177.  
  178. Interoperability Report
  179.  
  180.  
  181. The slides from Eve Schooler's presentation (slides.7.94.d) follow these
  182. minutes.
  183.  
  184. Eve discussed work being started to demonstrate interoperability between
  185. existing conferencing implementations.  There is a commonality in the
  186. architectures of many of these implementations, with some sort of
  187. session manager function doing coordination ``horizontally'' (peer to
  188. peer) between session managers, and ``vertically'' controlling the media
  189. agents that provide the media transport for the conferences.  An open
  190. question is whether the vertical and horizontal interfaces should use
  191. the same underlying communication mechanism.
  192.  
  193. There are many session orchestration approaches (sd, mmcc, maven, ivs,
  194. dvc, comet on WWW, mmphone over e-mail).  One goal is to create a common
  195. session description that they can all use.
  196.  
  197. There are many ways to communicate with media agents, including CCCP,
  198. Tk-send and multicast with a TTL of zero.  It would be good to choose
  199. one, and to come up with a common control interface to be used by all
  200. media agents.  Such a control interface should include at least
  201. ``on/off'' control for multi-agent muting, channel surfing, channel
  202. selection, and floor moderation, as well as up-calls from the media
  203. agents to support video-to-follow-audio, adaptive QoS tradeoffs,
  204. inter-agent synchronization and the like.
  205.  
  206. The overall goal is to create a ``plug and play'' environment in which
  207. application developers can choose between a variety of session control
  208. agents and media agents.  What is needed now is the documentation of
  209. control interfaces to existing media agents, and of session agent
  210. protocols.
  211.  
  212.  
  213. Discussion
  214.  
  215. In the ensuing discussions, several implementors agreed to document the
  216. protocols that are presently in use, to outline improvements planned for
  217. future releases, and in some cases actually to work on interoperation.
  218. There were at least two reasons for promoting documentation efforts.
  219. First, it would be useful to provide Informational RFCs for many of the
  220. publicly available applications.  Second, write-ups would go a long way
  221. towards motivating production of a shared protocol or protocols.  It was
  222. also suggested that it might be useful to hold a workshop to bring
  223. together people interested in these problems around the same time as the
  224. next IETF meeting in San Jose, possibly hosted by SRI.
  225.  
  226.