home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / cip / cip-minutes-90dec.txt < prev    next >
Text File  |  1993-02-17  |  8KB  |  232 lines

  1.  
  2.  
  3. CURRENT_MEETING_REPORT_
  4.  
  5.  
  6.  
  7. Reported by Ken Schroder/BBN
  8.  
  9. CIP Minutes
  10.  
  11. Agenda
  12.  
  13. Status Reports
  14.  
  15.  
  16.    o ST-II
  17.    o COIP-K
  18.    o FP
  19.    o MCHIP
  20.  
  21.  
  22. Collaboration Plans
  23.  
  24.  
  25.    o Research, experiments
  26.  
  27.  
  28. Meeting Report
  29.  
  30. The Connection Oriented Internetwork Protocol Working Group (CIP) is
  31. developing a set of protocols and resource management algorithms to
  32. support guaranteed service, packet switched communication in an
  33. internet.  Applications in the areas of wide area video conferencing and
  34. distributed simulation would both benefit from service guarantees.
  35. Elements of this support include resource reservation, flow regulation,
  36. instrumentation and enforcement mechanisms to ensure acceptable
  37. bandwidth, end-to-end delay and delay variation.  Approaches for
  38. allowing reservations to be renegotiated as the workload changes are
  39. also anticipated.
  40.  
  41. Claudio Topolcic, Working Group Chair, opened the meeting.  The goal of
  42. this meeting was to review what had been accomplished since the
  43. Vancouver meeting and to plan what will be done during the next three
  44. months.  We were particularly interested in understanding how the work
  45. each group member was doing might compliment one other.
  46.  
  47. RFC-1190 ``Experimental Internet Stream Protocol, Version 2 (ST-II)''
  48. has been released.  ST-II is an IP-layer protocol that provides
  49.  
  50.                                    1
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57. end-to-end service guarantees across an internet.  It was designed
  58. through earlier efforts of the Working Group to replace the Internet
  59. Stream Protocol originally defined in IEN-119.
  60.  
  61. ST-II implementation status was presented by Ken Schroder.  Portions of
  62. the control protocol are currently operating at BBN on an Ethernet.
  63. They expect to:
  64.  
  65.  
  66.    o Pass data application to application over Ethernet by the end of
  67.      December.
  68.    o Integrate T1 support by end of January.
  69.  
  70.  
  71. The protocol implementation is expected to be operating in the DARPA
  72. sponsored DARTNET in February.  Support will include connection setup
  73. and tear down, hop identifier negotiation, and add/delete targets.
  74. ST-II will then be used as a protocol testbed for exploring
  75. instrumentation and algorithms that:
  76.  
  77.  
  78.    o Ensure proper priority traffic handling to ensure that time
  79.      guarantees are met.
  80.    o Provide predictable estimates of delay and delay variance.
  81.    o Guarantee that network switching elements meet end-to-end
  82.      performance promised to applications.
  83.    o Enforce that application traffic cannot exceed the resources level
  84.      it originally requested.
  85.  
  86.  
  87. The issuing of RFC-1190 signaled the end, at least for now, of the ST
  88. track that this Working Group was following.  The Working Group will
  89. continue to study connection oriented protocols.
  90.  
  91. FP Flow Protocol work was presented by Lixia Zhang.  They are using IP
  92. option fields to implement the flow protocol.  This approach has
  93. simplified the work required and allows the protocol to coexist with IP,
  94. since standard gateways will forward the packets.  Developing a
  95. customized protocol would not have offered those benefits.  The current
  96. implementation goals include support for:
  97.  
  98.  
  99.    o Lixia's Flow Protocol
  100.    o Fair queuing algorithms
  101.    o Timestamp ordered driver queues to support priority scheduling
  102.  
  103.  
  104.  
  105.                                    2
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112. They have plans to experiment with dynamic rate adjustment, including
  113. selectively throttling traffic sources (rather than all sources) to
  114. handle congestion control.  They hope to make TCP use FP in the future.
  115.  
  116. They cited several difficulties they encountered with the current
  117. approach.
  118.  
  119.  
  120.    o Clock granularity is too coarse for traffic generator applications
  121.      programs to use for generating packets at specific rates
  122.    o Table lookup inefficient:  hard to get small universal identifiers
  123.    o Fair Queuing for IP is implemented on a per TCP connection basis.
  124.      The current implementation uses source and destination host IP
  125.      addresses plus port numbers as the connection identifier.
  126.  
  127.  
  128. Performance measurement was discussed.  They timestamp packets at
  129. source, destination and all intermediate routers.  Since transmission
  130. and propagation delays are known, queuing delay can be calculated.
  131.  
  132. Potential future work includes:
  133.  
  134.  
  135.    o Virtual clock testing.  The virtual clock was implemented but not
  136.      tested because queues don't build up on Sparcs with Ethernet.
  137.      (Ethernet is much faster.)
  138.    o FP providing reliability by selective retransmission
  139.    o Host pacing
  140.  
  141.  
  142. FP/ST sharing was discussed.  It was felt that some of the enforcement
  143. mechanism supported by the virtual clock Lixia's flow protocol could be
  144. integrated into the ST-II network layer.  This would require integration
  145. of the timestamp ordering mechanisms and supplying various flow
  146. parameters.  The potential for more extensive integration will be
  147. discussed after the ST-II implementation is working.
  148.  
  149. Resource management work at Berkeley was presented by Hui Zhang.  Their
  150. work includes explicit delay and jitter control.  Packets are marked
  151. with the desired transmission time and buffered until the deadline
  152. arrives.  This works to limit jitter.  Studies they have performed
  153. suggests this will also reduce the buffer space requirements of the
  154. overall network.
  155.  
  156. Connection Oriented IP Kernel was presented by Guru Parulkar.  The
  157. COIP-K is meant to provide a core set of functions--application and
  158. network interface, data forwarding and state machine
  159.  
  160.                                    3
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167. management--expected to be needed by high performance protocols such as
  168. ST-II. Their goal is to provide a reusable foundation in which resource
  169. management protocol research can be performed more easily.
  170.  
  171.  
  172.    o Chuck Cranor will return to work on software shortly
  173.    o They expect to have it debugged in January
  174.    o Can implement resource enforcement, potentially by incorporating
  175.      Lixia's virtual clock code
  176.  
  177.  
  178. There was some discussion about the availability and suitability of
  179. COIP-K to the ST-II and FP efforts.  We plan to revisit this in January
  180. after initial implementation is available.
  181.  
  182. MCHIP was presented by Guru Parulkar.  This is a connection oriented
  183. resource management protocol that Guru has been working on.  There are
  184. three basic elements:
  185.  
  186.  
  187.   1. Resource requirements characterized by peak rate, average rate and
  188.      burstiness.
  189.   2. Perpetual Congrams (PiCons) are routed using reservations and
  190.      virtual circuits, e.g., through ATM networks.
  191.   3. Server can provide resource allocations for unmanaged datagram
  192.      networks, e.g., Ethernet.  (There was some dispute as to whether
  193.      this was doable in the general case, whether source routing would
  194.      provide an adequate solution, and how much constraints would have
  195.      to be relaxed for it to work.)
  196.  
  197.  
  198. The meeting concluded after discussions of what next steps to take.  The
  199. potential combining of COIP-K, ST-II, and FP into a single COIP will be
  200. explored in January.  Many elements of FP resource management and
  201. enforcement seem complimentary and compatible with the ST-II
  202. implementation, which provides connection setup and management
  203. facilities.  The COIP-K is intended to be compatible with these and
  204. other protocols.
  205.  
  206. We plan to meeting, ideally by video conference, in late January to
  207. discuss how more of our work can be integrated.  At that point, working
  208. versions of COIP-K and ST-II should both be available.
  209.  
  210. Attendees
  211.  
  212. Ashok Agrawala           agrawala@cs.umd.edu
  213. Robert Braden            braden@isi.edu
  214.  
  215.                                    4
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222. Kevin Fall               kfall@ucsd.edu
  223. Gurudatta Parulkar       guru@flora.wustl.edu
  224. Ken Schroder             schroder@bbn.com
  225. Claudio Topolcic         topolcic@bbn.com
  226. Hui Zhang                hzhang@tenet.berkeley.edu
  227. Lixia Zhang              lixia@parc.xerox.com
  228.  
  229.  
  230.  
  231.                                    5
  232.