home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / mmusic / mmusic-minutes-93nov.txt < prev    next >
Text File  |  1994-02-23  |  11KB  |  246 lines

  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Abel Weinrib/Bellcore
  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 may be found
  10. in the directory venera.isi.edu:confctrl/minutes as files ietf.11.93 and
  11. slides.[a-d].11.93.ps.
  12.  
  13. The MMUSIC Working Group met for two sessions at the Houston IETF
  14. meeting.  The first day was dedicated to a short overview of the goals
  15. and context for the working group and a presentation of an algorithm and
  16. framework for managing shared session state.  The second meeting focused
  17. on preliminary ideas as to what might comprise shared session state for
  18. a couple of different session types, and three short presentations on
  19. related work.
  20.  
  21.  
  22. Overview and Framework
  23.  
  24. Abel Weinrib presented an overview of the goals of the MMUSIC Working
  25. Group and discussed the framework for the work.  This presentation was
  26. basically a review of the work of previous working group meetings; refer
  27. to the minutes of those meetings available from the confctrl archives
  28. for more detail.
  29.  
  30. In setting the context for the next two talks, a distinction was made
  31. between the ``agreement algorithm'' and the ``session control
  32. protocol.''  The agreement algorithm supports generic control of group
  33. membership and enforces correctness and other policies on state shared
  34. among the members.  This agreement layer ``understands'' membership and
  35. policies, but views the rest of the domain-specific session state as
  36. opaque.  The session control protocol understands the domain-specific
  37. session state, using the services of the agreement protocol to manage
  38. the state shared among the members.  The session protocol may also use
  39. other services in addition to the agreement services, such as services
  40. that support soft state sharing and recovery.
  41.  
  42. Issues that were raised during discussion:
  43.  
  44.  
  45.    o Where should a ``session manager'' that terminates a session
  46.      control protocol reside?  Various alternatives are on a workstation
  47.      (as shown in the framework slide) for one or multiple users, or one
  48.      per domain that could act as a demultiplexing agent by passing on
  49.      session control messages for users in that domain to the
  50.      appropriate place.  The second alternative may provide hooks for
  51.      supporting user mobility and may deal well with security firewalls.
  52.  
  53.    o Should floor control be done through the session control protocol
  54.      or through some other mechanism?
  55.  
  56.    o Should policies be chosen from a predefined set, or should they be
  57.      defined in all of their generality by each application?  This has
  58.      implications on interoperability and the complexity of the
  59.      applications.
  60.  
  61.    o In the framework, resource reservation is separate from session
  62.      management.  The session control protocol is used to propagate a
  63.      shared view of the state, which includes descriptions of the media
  64.      streams required by a conference.
  65.  
  66.  
  67.  
  68. An Algorithm for Managing Shared Teleconferencing State
  69.  
  70. Scott Shenker described some preliminary ideas being developed for
  71. expressing policies about how session state can be changed and the
  72. degree to which members agree on their views of the state.  Policy can
  73. be expressed along three dimensions:  voting policies, consistency
  74. policies, and initiator policies.  Voting policy defines which members
  75. must agree for a state change to take place.  Consistency policies
  76. describe how the state seen by different members may differ.  Initiator
  77. policies set which members may initiate changes to the state.  The
  78. policy framework provides the vocabulary for concretely describing
  79. various session styles.
  80.  
  81. He then presented an algorithm that supports operations on the shared
  82. state while enforcing the policies associated with the session.  These
  83. operations might be adding a member, changing the policies themselves,
  84. or modifying some other domain specific state variable such as an
  85. encryption key.  The basic mechanism is a group agreement algorithm
  86. based on a two-phase commit procedure or correctness.
  87.  
  88. For additional information on this work there is a rough draft document
  89. in the confctrl archives in docs/agree.ps.  Notice of the availability
  90. of more complete drafts of the document will be sent to the confctrl
  91. mailing list.
  92.  
  93. Some points raised in the discussion during and following the talk:
  94.  
  95.  
  96.    o It was observed that some members of a session may be programs
  97.      running on computers.  The fall-back position of always allowing
  98.      members to leave a corrupted session may be less useful than for
  99.      human members who can more easily detect the corruption.
  100.  
  101.    o Critical and non-critical membership allows there to be a core
  102.      group of members that control the conference and a potentially much
  103.      larger set of members that can more easily enter and leave.
  104.  
  105.    o This talk is about agreement, not negotiation.  The distinction is
  106.      that there is no support for multiple rounds of proposals and
  107.      counter-proposals.  This could be future work, or could be done at
  108.      the application level building on top of the basic agreement
  109.      service.
  110.  
  111.  
  112. Session Control Above the Agreement Protocol
  113.  
  114. Eve Schooler's talk was devoted to the interpretation and usage of the
  115. agreement protocol for teleconference session control.  Discussion
  116. attempted to place the agreement protocol in the context of a
  117. traditional protocol stack and to hint at implementation concerns.
  118. Examples were given for generic and domain-specific session operations,
  119. as well as for the array of potentially interesting state attributes
  120. (session-wide, membership-related, or media- and policy-specific).  To
  121. illustrate the range of sessions that can be constructed from different
  122. sets of policies, two example paradigms were presented; one for an open
  123. hailing-channel session with little coordination among members, and
  124. another for a minimal invitation-only session.
  125.  
  126. The second half of the presentation focused on several open issues:
  127. Tradeoffs between different end-system organizations, addressing issues
  128. related to the use of unicast and multicast and to the interaction of
  129. media agents and session agents, and alternate techniques for user
  130. rendezvous that resemble what is currently in place on the MBone for
  131. session directories.
  132.  
  133. For additional information on this work, there is a very rough draft
  134. document in the confctrl archives in docs/usage.txt.  Notice of the
  135. availability of more complete drafts of the document will be sent to the
  136. confctrl mailing list.
  137.  
  138. Some points raised in the discussion:
  139.  
  140.  
  141.    o Issues of media typing and the addressing of media agents are
  142.      related to problems that need to be solved for WWW as well as
  143.      XMosiac naming and MIME mailcap media descriptions.
  144.  
  145.    o It would be nice if session control did not assume that the media
  146.      used by the conference is necessarily carried over an IP network.
  147.  
  148.  
  149. Consensus and Control in Wide-Area Communication
  150.  
  151. Bala Rajagopalan briefly presented his work on agreement and control of
  152. group membership in wide area communications.  He also handed out a
  153. paper that presents his model and algorithm in more detail; contact him
  154. via email for a copy of his paper.
  155.  
  156. The model allows a group to (eventually) come to consensus on its
  157. membership in the presence of unreliable message delivery.  His
  158. algorithm uses wide area multicast and a coordinator for each
  159. partition's ``view'' of the membership state.  Operations on groups
  160. include join, leave, delete, reform, merge.  One underlying assumption
  161. of this work that led to some heated discussion during the meeting is
  162. that connectivity is transitive, meaning that if A is connected to B and
  163. B is connected to C, then A is connected to C; this assumption may break
  164. down during certain failure scenarios in the Internet.
  165.  
  166. This work appears to be relevant to the concerns of the MMUSIC Working
  167. Group.  More effort is required to understand how and where it might fit
  168. into the MMUSIC charter.
  169.  
  170.  
  171. RTCP Implications for MMUSIC
  172.  
  173. Steve Casner discussed the relationship of RTCP, the ``real time control
  174. protocol'' defined by the Audio/Video Transport Working Group (AVT), to
  175. the MMUSIC Working Group effort.  RTCP is separate from the RTP protocol
  176. (which supports transport of time-critical media streams) and may in the
  177. future be replaced by a higher level control protocol, such as the
  178. MMUSIC session control protocol.  In particular, he described the
  179. functions that RTCP currently provides, and discussed other functions
  180. that would be useful in supporting an application such as multimedia
  181. teleconferencing (see the slides).  He concluded that it may make sense
  182. to use some part of the RTCP in conjunction with a higher level control
  183. protocol.
  184.  
  185.  
  186. Session Control Work at BBN
  187.  
  188. Julio Escobar presented a list of relevant work at BBN that is
  189. addressing similar issues to the MMUSIC Working Group.  He mentioned
  190. Chip Elliott's work on the ``sticky'' protocol (Chip had actually
  191. presented this work at an earlier MMUSIC/CONFCTRL BOF), Lou Berger's
  192. simulation exercise management tool, and Walter Milliken's work on
  193. resource coordination objects.  Julio promised to send additional
  194. information on this work to the confctrl mailing list (which he has
  195. done).
  196.  
  197.  
  198. Attendees
  199.  
  200. Lou Berger               lberger@bbn.com
  201. David Borman             dab@cray.com
  202. Stephen Casner           casner@isi.edu
  203. Ping Chen                ping@ping2.aux.apple.com
  204. George Clapp             clapp@ameris.ameritech.com
  205. Steve DeJarnett          steve@ibmpa.awdpa.ibm.com
  206. David Dubois             dad@pacersoft.com
  207. Ed Ellesson              ellesson@vnet.ibm.com
  208. Julio Escobar            jescobar@bbn.com
  209. William Fenner           fenner@cmf.nrl.navy.mil
  210. James Fielding           jamesf@arl.army.mil
  211. Ron Frederick            frederick@parc.xerox.com
  212. Atanu Ghosh              atanu@cs.ucl.ac.uk
  213. Fengmin Gong             gong@concert.net
  214. John Hanratty            jhanratty@agile.com
  215. Ken Hayward              Ken.Hayward@bnr.ca
  216. Van Jacobson             van@ee.lbl.gov
  217. Yasuhiro Katsube         katsube@mail.bellcore.com
  218. Charley Kline            cvk@uiuc.edu
  219. Jim Knowles              jknowles@binky.arc.nasa.gov
  220. Ted Kuo                  tik@vnet.ibm.com
  221. Paul Lambert             paul_lambert@email.mot.com
  222. Mark Laubach             laubach@hpl.hp.com
  223. Jim Martin               jim@noc.rutgers.edu
  224. Thomas Maslen            maslen@eng.sun.com
  225. Donald Merritt           don@arl.army.mil
  226. Karen O'Donoghue         kodonog@relay.nswc.navy.mil
  227. Laura Pate               pate@gateway.mitre.org
  228. J. Mark Pullen           mpullen@cs.gmu.edu
  229. Bala Rajagopalan         braja@qsun.att.com
  230. Steven Richardson        sjr@merit.edu
  231. Eve Schooler             schooler@isi.edu
  232. Henning Schulzrinne      hgs@research.att.com
  233. Scott Shenker            shenker@parc.xerox.com
  234. Michael Speer            michael.speer@sun.com
  235. John Stewart             jstewart@cnri.reston.va.us
  236. Daniel Swinehart         swinehart.parc@xerox.com
  237. Matsuaki Terada          tera@sdl.hitachi.co.jp
  238. Claudio Topolcic         topolcic@cnri.reston.va.us
  239. Abel Weinrib             abel@bellcore.com
  240. Taehwan Weon             weon@cosmos.kaist.ac.kr
  241. John Wroclawski          jtw@lcs.mit.edu
  242. Shinichi Yoshida         yoshida@sumitomo.com
  243. Lixia Zhang              lixia@parc.xerox.com
  244. Weiping Zhao             zhao@nacsis.ac.jp
  245.  
  246.