home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / rtfm / rtfm-minutes-96dec.txt < prev    next >
Text File  |  1997-01-30  |  10KB  |  239 lines
  1. Editor's note:  These minutes have not been edited.
  2.  
  3.  
  4. +-----------------------------------------------------------------------+
  5. | Nevil Brownlee                       Director, Technology Development |
  6. | Phone: +64 9 373 7599 x8941          ITSS, The University of Auckland |
  7. |   FAX: +64 9 373 7425        Private Bag 92019, Auckland, New Zealand |
  8. +-----------------------------------------------------------------------C
  9.  
  10. Minutes of RTFM WG session at San Jose IETF, 0900 Wed 11 Dec 96
  11. ---------------------------------------------------------------
  12.  
  13. IMPLEMENTATION REPORTS:
  14.  
  15. Stephen Stibler's experience developing IBM's RTFM implementation has
  16. clarified several aspects of the architecture which are reflected in
  17. the Architecture RFC and the Experimental MIB.  The RTFM meter is
  18. implemented as a DPI RFC 1228 subagent and makes use of native
  19. multi-threading. 
  20.  
  21. Nevil Brownlee reported on current status and uses of NetraMet.
  22. NetraMet has been fully converted to use SNMP version 2C and extended
  23. to a 32-bit PC meter.  The meter can now watch up to four interfaces
  24. and can do link-level passive monitoring with IP disabled on the
  25. monitored interfaces.  In this configuration the monitor is not
  26. available as an IP destination, which eliminates the possibility of an
  27. IP-based security exposure from the monitored link.  A secure network
  28. interface may be used to send collection data to a manager/reader. 
  29.  
  30. Collaboration with the OC3MON project has resulted in a version of the
  31. NetraMet meter which runs within the OC3MON monitor, implemented and
  32. tested in early December 1996.  This, combined with experiments on
  33. 100Mbps Ethernets, demonstrates that the RTFM architecture scales
  34. appropriately to high-speed networks. 
  35.  
  36. NEW ATTRIBUTES AND CHANGES:
  37.  
  38. Sig Handelman presented the three areas in which new attributes are
  39. being defined.  The goal is to keep intact the original RTFM meter
  40. structure and its data reduction characteristics.  Additions will be
  41. simple statistics which benefit from the ability of RTFM to identify
  42. and consolidate flows of interest with specific granularity across
  43. multiple protocol layers.  The three areas are packet tracing for
  44. specific flows, simple aggregates over a time interval, and series of
  45. specific attributes such as packet inter-arrival times.  Discussion
  46. demonstrated interest in packet inter-arrival times, tracing of
  47. specified packet attributes or header fields in exception conditions,
  48. and tracking of TCP window size.  The question arose of whether we
  49. should implement threshholds and traps; this area was not covered by
  50. the internet draft.  It was pointed out that RTFM's view of flows as
  51. basically bi-directional may simplify the measurement of certain delay
  52. metrics, such as measuring the time between a window offer and window
  53. accept or TCP SYN to ACK. 
  54.  
  55. A number of proposed changes to the Experimental RFTM Meter MIB were
  56. discussed:
  57.  
  58. * The MatchingStoD attribute will allow a single rule to determine
  59.   whether a packet is being matched with the addresses in 'wire' order
  60.   (StoD) or in reverse order.  It was agreed that this wuold be useful
  61.   useful - it will be further discussed on the mailing list. 
  62.  
  63. * A mechanism for reading flow table rows was discussed briefly.  This
  64.   would replace the present method of reading parts of flow table
  65.   columns. 
  66.  
  67. * Metering inside tunnels has been requested by NeTraMet users.  The
  68.   Architecture already provides for this by allowing Adjacent Addresses
  69.   to include Peer Addesses - inside an IP tunnel, Adjacent Addresses are
  70.   the IP addresses of the tunnel's end points. 
  71.  
  72.  
  73. REVIEW OF WG STATUS:
  74.  
  75. Accomplished Goals and Milestones:
  76.  
  77. Jun 96: Submit 'Traffic Flow Measurement: Architecture' and 'Traffic
  78.         Flow Measurement: Meter MIB' I-Ds for publication as
  79.         Experimental RFCs.  <<< Approved by IESG, now in RFC queue
  80.  
  81. Sep 96: Submit 'Traffic Flow Measurement: Experiences with NetraMet'
  82.         I-D as informational.  <<< Approved by ADs, now in RFC queue
  83.  
  84. Nov 96: Publish I-D on 'New Attributes for Traffic Flow
  85.         Measurement'   <<< published and available at IETF web site
  86.  
  87. Dec 96: Select new attributes to be included in the proposed standard
  88.         Traffic Architecture.
  89.  
  90. After discussion, it was decided to put forward the existing
  91. Architecture and Meter MIB as proposed standards at the NEXT meeting.
  92. Proposed extensions should be sufficiently articulated in the meantime
  93. so that any modifications needed to the existing RTFM structures can
  94. be put forward as part of the proposed RTFM 'base' standard. 
  95.  
  96. The group's revised milestones are:
  97.  
  98. March 97:  Publish new I-Ds for Architecture and Meter MIB
  99.            Publish revised I-Ds for 'Extended Attributes'
  100.  
  101. April 97:  Submit Architecture and Meter MIB I-Ds to IESG for
  102.            publication as Proposed Standard RFCs
  103.  
  104. August 97: Submit I-Ds on 'Extended Attributes' as Standards
  105.            Track RFCs
  106.  
  107. URLs:
  108.  
  109. IETF WG Information: http://www.ietf.org
  110. RTFM Information:    http://www.auckland.ac.nz/net/Internet/rtfm
  111. OC3MON information:  http://www.nlanr.net/NA/Oc3mon/
  112.  
  113.  
  114. Minutes by Cyndi Mills
  115.  
  116.  
  117.  
  118.  
  119.  
  120. Minutes of the RTFM/IPPM Joint Session, 0900, Thu 12 Dec 96
  121. -----------------------------------------------------------
  122.  
  123. Overview of RTFM
  124.  
  125. Nevil Brownlee presented a brief overview of RTFM.  RTFM has been a
  126. working group for about a year.  It was an outgrowth of an earlier
  127. effort in accounting, meaning defining, measuring and flexibly
  128. aggregating flows of interest. 
  129.  
  130. The RTFM Architecture includes Meter, Manager, Meter Reader, Analysis
  131. Application, and Rule Sets.  It allows you to download a lot of the
  132. analysis into the meter.  It can replace tcpdump by putting front end
  133. data reduction at the meter.  One may place meters far away over even
  134. slow links, and can pull back partially reduced data from the meters. 
  135.  
  136. Rule sets define bi-directional flows.  RTFM has three levels of
  137. addresses - adjacent, peer and transport; this allows very detailed
  138. specification of flows.  Nevil discussed how assymetric flows are handled
  139. by RTFM's bi-directional flow mechanism. 
  140.  
  141. Sig Handelman presented the three areas in which new RTFM attributes are
  142. being defined.  The goal is to keep intact the original RTFM meter
  143. structure and its data reduction characteristics.  Additions will be
  144. simple statistics which benefit from the ability of RTFM to identify and
  145. consolidate flows of interest with specific granularity across multiple
  146. protocol layers.  The three areas are packet tracing for specific flows,
  147. simple aggregates over a time interval, and series of specific
  148. attributes such as packet inter-arrival times. 
  149.  
  150.  
  151. DIFFERENCES between RTFM and IPPM
  152.  
  153. RTFM                   IPPM
  154. ----------------------------       --------------------------------------
  155.  
  156. Passive                   Active
  157.  
  158. Confidential Data           User data not examined
  159.  
  160. Real Usage               Prepared stream
  161.  
  162. Useful at edges and choke       Useful at two points on opposite side
  163.   points of IP clouds                of IP clouds
  164.  
  165. In-service meter           Treats IP clouds as black boxes
  166.  
  167. RTFM is an existing measurement       IPPM is approaching performance
  168.   technique with specific            questions, developing/adopting
  169.   metrics/tools                      technologies/tools and techniques
  170.                      which answer those questions.
  171.  
  172. The above points summarise a lengthy and interesting discussion
  173. Others included:
  174.  
  175. * The meter does not supply enough information to allow one to model
  176.   the state of the TCP flow control at the endpoints.  Being able to do
  177.   so is possible with passive tools designed for the purpose.
  178. * Tools based on the RTFM meter might be strong at indicating *when* a
  179.   problem is likely occuring, but comparitively weak at indicating
  180.   *why* the problem is occuring.  This indicates a complementary
  181.   relationship -- not a problem.
  182. * As with all passive tools, use of the RTFM meter within the core of
  183.   the Internet must honestly address significant privacy concerns.
  184. * Given the presence of asymmetric routes, any RTFM meter deployed
  185.   within the core of the Internet will often see one direction of a
  186.   two-way TCP flow.  Very close time synchronization would be required
  187.   to allow measurements on the two one-way flows to be patched back
  188.   together.
  189.  
  190. TECHNOLOGY INTERACTIONS between RFTM, IPPM and RMON
  191.  
  192. RMON is different from RTFM.  An RMON probe collects a wide variety
  193. of data from the monitored network; a Network Management Sysytem can
  194. use this data to display the network status to a user.  RTFM performs
  195. useful front-end data reduction, and - through its rule sets - allows a
  196. user very detailed control over which flows are of interest, and what
  197. data is to be collected for each of them.
  198.  
  199. At the same time, RMON and RTFM share the same basic MIB structure,
  200. making it possible for an RTFM meter to be implemented within an RMON
  201. probe.  RMON2 provides higher-layer protocol analysis, and selective
  202. packet tracing.  It was agreed that RTFM should focus on real-time
  203. aspects which RMON is not currently addressing. 
  204.  
  205. Several participants asked whether an RTFM meter might also operate as
  206. an (active) IPPM probe.  Consensus was that this does not fit within
  207. the RTFM architecture, however it may well be useful to run such a
  208. probe on the same machine as an RTFM meter.
  209.  
  210. There are a number of concerns shared by RTFM and IPPM.  Clock
  211. synchonisation is vital so that measurements on several probes can be
  212. accurately corelated.  The security of observed traffic data is also
  213. very important.
  214.  
  215. The Argus package was discussed.  Argus was designed as a method of
  216. saving packet information with enough detail to allow site managers to
  217. reconstruct packet streams months after an attempted security violation
  218. was observed.  It differs from RTFM in that RTFM summarises information
  219. about all packets in a flow.
  220.  
  221. There is a very high level of interest in monitoring TCP sessions, with
  222. several different groups actively working in this area.  For this
  223. reason it will be sensible for RTFM to regard TCP session analysis as a
  224. low priority goal.
  225.  
  226.  
  227. PRIMARY REQUESTS FOR RTFM EXTENSIONS
  228.  
  229. Focus first on extensions which are not provided by RMON and satisfy
  230. real-time needs, such as measurements which are useful in determining
  231. jitter and delay characteristics. For example:
  232.  
  233. 1) Packet inter-arrival times.
  234.  
  235. 2) Monitor flows so as to detect flows which are not responding to
  236.    congestion control.
  237.    
  238. =====================================================================
  239.