home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 94dec / area.transport.94dec.txt < prev    next >
Text File  |  1995-02-28  |  10KB  |  206 lines

  1.  
  2. Transport Area
  3.  
  4. Director:
  5.  
  6.  
  7.    o Allison Mankin:  mankin@cmf.nrl.navy.mil
  8.  
  9.  
  10. Area Summary reported by Allison Mankin/NRL
  11.  
  12. The Transport Services Area deals with protocols and algorithms that
  13. provide end-to-end transmission services in the Internet.  We maintain
  14. the notion of transport services, not just transport protocols, because
  15. of the increasing variety of end-to-end requirements that the Internet
  16. meets or will have to meet soon.
  17.  
  18. The members of the Transport Area Directorate are:
  19.  
  20.  
  21.                Dave Borman     dab@cray.com
  22.                Sally Floyd     floyd@ee.lbl.gov
  23.                Jim Hughes      hughes@hughes.network.com
  24.                Matt Mathis     mathis@pele.psc.edu
  25.                Greg Minshall   minshall@wc.novell.com
  26.                Eve Schooler    schooler@isi.edu
  27.                John Wroclawski jtw@lcs.mit.edu
  28.                Lixia Zhang     lixia@parc.xerox.com
  29.  
  30.  
  31. The Transport Area Directorate is primarily responsible for quality
  32. review of the working groups.  It meets regularly on the MBONE to plan
  33. for each upcoming IETF. It has a mailing list, but its location is in
  34. transition, with the Area Director's move to ISI (in a new East Coast
  35. lab).
  36.  
  37. Here is some news of the Area from between the meetings and San Jose,
  38. followed by group meeting summaries.
  39.  
  40.  
  41.    o We will soon plan what Transport Next Generation work should begin,
  42.      as the mid-term result of the TCPng BOF reported below.
  43.  
  44.    o The ONCRPC Working Group was in hiatus for San Jose, while the
  45.      IETF's agreement with Sun was worked out.  Soon on the TSV agenda
  46.      will be determining how the second half of the ONCRPC charter
  47.      (enhancing the standards once they were documented) should go.
  48.  
  49.    o Richard Stevens, the author of TCP/IP Illustrated, has been asked
  50.      to write an RFC documenting TCP's adaptive algorithms, since Sally
  51.      Floyd reviewed that chapter in TCP/IP Illustrated Vol.  2 and
  52.      reported that it was extremely accurate and clear.  He will try to
  53.      do so before the next IETF.
  54.  
  55.    o The Thin-OSI Working Group completed its charter and concluded
  56.      between Toronto and San Jose.
  57.  
  58.    o The TMUX proposal, developed in a TSV BOF, received an extended
  59.      Last Call and was elevated to Proposed Standard (RFC 1692).
  60.  
  61.    o Of the TSV working groups, four met in San Jose, and one BOF was
  62.      hosted, TCPng, a review in conjunction with IPng.
  63.  
  64.    o The ONC Remote Procedure Call Working Group (ONCRPC) and the TCP
  65.      Large Windows Working Group (TCPLW) are dormant.
  66.  
  67.  
  68.  
  69. Next Generation TCP BOF (TCPNG)
  70.  
  71.  
  72. The TCPng BOF was convened to consider what changes need to be made to
  73. TCP for the transition to IPv6, and whether any other new features
  74. should be added at this time.  The meeting distinguished TCP6, the
  75. minimal changes to operate over IPv6, from a TCPng, a wonderful new
  76. TCP-like protocol.  It discussed a number of different possible features
  77. that might be included in TCPng, and suggested that the Transport
  78. Service Area Director might set up a working group to talk about next
  79. generation transport protocols.
  80.  
  81.  
  82.  
  83. Audio/Video Transport Working Group (AVT)
  84.  
  85.  
  86. A report was presented on the changes to the Real-time Transport
  87. Protocol draft since the July version (-05).  These changes were all
  88. small, though a few did introduce incompatibilities.  There were no
  89. objections to these changes.  However, there was a surprising amount of
  90. debate about the jitter parameter in the Reception Report which had not
  91. changed except that the algorithm had been defined.  As a result, a
  92. second session was scheduled to allow completing the planned
  93. presentations.  During the second session, a compromise solution was
  94. devised:  the jitter field remained unchanged, but the ``cumulative
  95. packets received'' was changed to ``cumulative packets lost'' and
  96. reduced to 24 bits.  The freed 8 bits will contain a ``fraction of
  97. packets lost'' allowing short-term loss measurements with singleton
  98. reception reports.  With this issue settled, the draft editing will be
  99. completed and the draft will be submitted for Area Directorate review.
  100.  
  101. Additional presentations were given on the implementation of RTPv2 in
  102. vic (by Steve McCanne) and Loki (by Frank Kastenholz), and on the new
  103. draft Packet Format for Encapsulation of MPEG in RTP (by Gerard
  104. Fernando).
  105.  
  106.  
  107. Integrated Services Working Group (INTSERV)
  108.  
  109.  
  110. The integrated services working group (INT-SRV) held two meetings at the
  111. San Jose IETF. At these meetings the group discussed several parts of a
  112. ``reusable framework'' approach to providing quality of service control
  113. in the Internet.  The key goal of this approach is to allow new services
  114. to be deployed in an evolutionary, market-driven manner, while
  115. maintaining backward compatibility and (re)using standard components.
  116.  
  117. The first meeting began with a brief presentation describing this new
  118. approach and how it differs from the group's previously proposed path.
  119. John Wroclawski's presentation discussed goals, described four
  120. components (QM manager, setup protocols, traffic specifiers, and service
  121. specification templates), and briefly described the impact of this
  122. approach on the work items adopted at the Toronto IETF.
  123.  
  124. The majority of the first meeting was devoted to a discussion of the
  125. Quality of Service Manager, an abstraction layer designed to isolate
  126. applications from the specific details of services provided by an
  127. internet.  Dave Clark gave a general presentation of the QM idea, its
  128. uses, and how it might be realised in practice.  Craig Partridge
  129. discussed a binding of the QM to Berkeley sockets.  Both of these
  130. presentations describe early work, and the authors received significant
  131. feedback from the working group.
  132.  
  133. The meeting closed with a brief discussion of the merits of the
  134. framework approach to providing integrated services.  A show of hands
  135. revealed essentially complete consensus that the new approach was
  136. preferred to the alternative of mandating a single set of services
  137. throughout the Internet.
  138.  
  139. The group continued the discussion of framework components in the second
  140. meeting.  Scott Shenker presented a preliminary draft of a service
  141. specification requirements document.  The document has two parts.  The
  142. first specifies a ``template'' for defining services, including router
  143. behavior, composition rules, and the like.  The remainder of the
  144. document gives several examples of the use of this template.  The
  145. intention is that the template format become a standard, but for now,
  146. the example services are informational.  The group agreed that this
  147. draft was a good base for continued work.
  148.  
  149. Craig Partridge gave a presentation about traffic specifications
  150. (``flowspecs'') and whether these are a reusable component or specific
  151. to a particular service.  After some discussion, the group appeared to
  152. find some merit to common flowspecs, but believed that further concrete
  153. evidence of their usefulness was required.  Further discussion centered
  154. on the use of RFC 1363 or the Windows Sockets version 2.0 specification
  155. as a possible starting point for experimental implementations.
  156.  
  157. John Wroclawski presented a proposal for initial deployment of
  158. integrated service capabilities in the July '95 time frame.  The
  159. proposal includes RSVP, a level-of-effort predictive service, and
  160. management and monitoring capability.  John asked about interest in a
  161. small implementors group to further this work, and received several
  162. positive responses during and after the meeting.
  163.  
  164. The second meeting closed with a technical discussion about token bucket
  165. filters.  TBFs are widely proposed today as traffic descriptors and
  166. shapers, but recent work by Mark Garrett and Craig Partridge suggests
  167. some limitations.  This is directly relevant to the flowspec discussion
  168. described above, and will need to be better understood in the future.
  169.  
  170.  
  171. Multiparty Multimedia Session Control Working Group (MMUSIC)
  172.  
  173. In an effort to make the working group aware of other standardization
  174. efforts, two brief presentations were given on ITU teleconferencing
  175. efforts.  Next, an overview of both a centralized and a distributed
  176. implementation of the Shenker-Weinrib-Schooler agreement protocol was
  177. given -- the implementation experience gave rise to several interesting
  178. research issues concerning generality, dynamicity, and scalability.  A
  179. summary of the responses from a survey of existing session control
  180. protocols was then given, focusing on derived functional requirements
  181. for both session control protocols and session descriptions.  An
  182. overview of inter-system (horizontal) and intra-system (vertical)
  183. session control requirements was presented which left open questions on
  184. the transport and semantic requirements.  A presentation was then given
  185. which identified additional requirements for the ``sd'' protocol and a
  186. discussion of proposed extension followed.  Finally, the current goals
  187. and milestones were reviewed and a list of potential working group
  188. documents was discussed.
  189.  
  190.  
  191. Resource Reservation Setup Protocol Working Group (RSVP)
  192.  
  193. The RSVP Working Group met for two sessions during the San Jose IETF.
  194. The first session began with a brief review of implementation status and
  195. a description of the MM '94 demo.  The rest of the first meeting was
  196. devoted to reports from all those who took study action items at the
  197. Toronto meeting.  Each report included a recommendation to the working
  198. group.
  199.  
  200. The second session began with reviews of some new technical issues, not
  201. previously discussed.  Then the working group developed a list of
  202. features to be included in version 1 RSVP. This list will serve as the
  203. basis for revision of the specification and review, hopefully allowing
  204. submission as a Proposed Standard in July 1995.
  205.  
  206.