home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / rtfm / rtfm-minutes-96jun.txt < prev    next >
Text File  |  1996-10-07  |  5KB  |  137 lines
  1. Editor's note:  These minutes have not been edited.
  2.  
  3.  
  4. REALTIME TRAFFICE FLOW MEASUREMENT WORKING GROUP 
  5. MEETING, MONTREAL, 26-JUN-96
  6.  
  7. Minutes produced by Cyndi Mills and Nevil Brownlee 
  8.  
  9.  
  10. REVIEW OF CURRENT DOCUMENTS
  11.  
  12. The current 'traffic flow measurement architecture' and 'traffic flow 
  13. measurement meter mib' documents have been submitted for publicaton 
  14. as experimental RFCs.
  15.  
  16. The 'experiences' document was published as an Internet Draft in May. 
  17. Two changes were suggested:
  18. (1) The term describing the former 'fail' or 'retry' action 
  19. (indicating that an address has not matched a rule during a pass 
  20. through the rule set) will be changed to 'NoMatch.' (2) In response to 
  21. the question of whether flow type attributes should 
  22. contain both source and destination separately; the consensus was that 
  23. both should remain unless there is a specific future need to reduce the 
  24. generality of the architecture. 
  25.  
  26. The original intention was to revise RFC 1272. The group agreed to 
  27. leave RFC 1272 as is with its accounting focus, and produce new 
  28. background information focussed on traffic flow measurement. This 
  29. should address specifically the definition of flows as used in traffic 
  30. flow measurement.
  31.  
  32. PRESENTATIONS
  33.  
  34. Presentations were made by the two current implementors of the traffic 
  35. meter.
  36.  
  37. Sig Handelman has deployed the IBM implementation in a multi-
  38. Ethernet environment. The meter has contained over 64,000 flows while 
  39. maintaining good performance. Since the meter runs on a Unix system, 
  40. the collection mechanism writes active flows periodically to a disk file 
  41. for later collection by a bulk transfer mechanism. 
  42.  
  43. The NetFlow presentation by Nevil Browlee demonstrated uses of 
  44. timing information provided by the meter to pinpoint 'interesting' 
  45. flows, for example the protocols and attributes of short high-rate flows 
  46. (bursts) and long-lived flows (sessions). Plots produced by NetFlow 
  47. illustrated useful techniques for visualising complex relationship of 
  48. flow age, protocol composition, and volume. 
  49.  
  50.  
  51. NEW ARCHITECTURE FEATURES
  52.  
  53. The group agreed that the basic architecture is appropriate in its 
  54. present form and began discussions to identify those attributes which 
  55. might be added to extend its usefulness. In particular, the working 
  56. group expressed the need for some of these new attributes to support 
  57. emerging services and real-time flows. These discussions centered 
  58. around requirements and features needed for the following areas: 
  59.  
  60. IP version 6
  61. The working group should verify that the current architecture supports 
  62. IPv6 and identify any desirable new attributes to support additional 
  63. features of IPv6.
  64.  
  65. Application-layer attributes
  66. In support of application level gateways (e.g. EDI, firewalls) and 
  67. application level services (file transfer, messaging, etc.) there was 
  68. interest in reporting generic application units (where the meaning of 
  69. the unnamed unit is determined by the application, e.g. files for ftp, 
  70. pages for html, etc) as well as generic error measurement (failures, 
  71. sessions, retransmissions,...). A third set of capabilities would be the 
  72. addition of application-defined pairs (name + count pairs.)
  73.  
  74. Rule Table matching extension
  75. Proposed was an extension which would allow a rule table to 
  76. distinguish between a source-dest and a dest-source match. 
  77.  
  78. Interpacket times
  79. For the purpose of measuring jitter and delay, specifically in real-time 
  80. applications such as audio and video packet streams, the working group 
  81. desires an optional means for collecting interpacket delays and spacing. 
  82. Interpacket times indicate either the time between packet sent and 
  83. received (e.g. ping) or between two consecutive packets flowing in the 
  84. same direction (e.g. video stream).
  85.  
  86. Support for resource-controlled flows
  87. Additional attributes may be needed which support the comparison of 
  88. expected and actual traffic flows.
  89.  
  90. Other Discussion
  91. Sometimes it is necessary to use a single meter to collect information for 
  92. several different purposes, e.g. deciding "who is using my network?" 
  93. (which requires address aggregation and long collection intervals) and 
  94. "how well is my network performing?" (which requires protocol 
  95. aggregation and short collection intervals). The current architecture 
  96. allows a meter to run two rule sets simultaneously, and for the flow 
  97. data to be collected by multiple meters in an aysnchronnous manner.
  98.  
  99. REVIEW OF WORKING GROUP GOALS AND MILESTONES 
  100.  
  101. The working group produced a revised set of goals and milestones as 
  102. follows:
  103.  
  104. Jun 96: Submit 'Traffic Flow Measurement: Architecture' and 
  105. 'Traffic Flow Measurement: Meter MIB' I-Ds for publication as 
  106. experimental RFCs
  107.  
  108. Sep 96: Submit 'Traffic Flow Measurement: Experiences with 
  109. NeTraMet' 
  110. I-D for publication as RFC
  111.  
  112. Nov 96: Publish I-D on 'New Attributes for Traffic Flow Measurment' 
  113.  
  114. Dec 96: Select which new attributes will be included in the new 
  115. proposed standard Traffic Flow Architecture. 
  116.  
  117. Mar 97: Submit architecture document(s) as proposed standard 
  118. Begin work on implementation document
  119.  
  120. Jun 97: Submit implementation document for publication as an RFC 
  121.  
  122.  
  123. ACTION ITEMS
  124.  
  125. The RTFM working group maintains a web page at 
  126. http://www.auckland.ac.nz/net/Internet/rtfm/TOP.html Document 
  127. editing team:
  128. Cyndi Mills, Greg Ruth, Nevil Brownlee, Robert Bradshaw Revise 
  129. experiences I-D:
  130. Nevil Brownlee
  131. Generate new background information:
  132. Cyndi Mills
  133. Edit new atttributes:
  134. Greg Ruth, Sig Handelman
  135.  
  136. -----------------------------------------------------------------------
  137.