home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / rtfm / rtfm-minutes-96mar.txt < prev    next >
Text File  |  1996-05-24  |  3KB  |  78 lines
  1. Editor╒s note:  These minutes have not been edited.
  2.  
  3.  
  4. Minutes of the Realtime Traffic Flow Measurement Working Group 
  5. (RTFM) 
  6.  
  7. 35th IETF, Los Angeles, Wed 6 Mar 96
  8.  
  9. Chairs: Nevil Brownlee, Sig Handelman
  10.  
  11. Minutes by: Cyndi Mills & Nevil Brownlee 
  12.  
  13. The group's charter and milestones were reviewed and confirmed. 
  14. Nevil Brownlee gave a brief overview of the Traffic Flow Measurement 
  15. model, and of NeTraMet (his public-domain implementation). Sig 
  16. Handelman gave a status report of the IBM implementation. 
  17.  
  18. Existing work on traffic flow measurement was discussed, particularly 
  19.  
  20. - The work of the NLANR group at the San Diego Supercomputer 
  21. Centre 
  22. (see http://www.nlanr.net/NA for a good introduction). - A journal 
  23. article on "Measurement, Modelling and Emulation of Internet 
  24. Round Trip Delays" was discussed. The reference has been posted to the 
  25. mailing list.
  26. - The Flow Statistics provided by Cisco's Flow switching option for 
  27. their high-end routers.
  28. - The work of other IETF Working Groups such as BMWG/IPPM, RMON 
  29. and RSVP. 
  30.  
  31. The distinction between this group and IPPM was discussed. IPPM is 
  32. concerned with measurements which a user may use EXTERNALLY to 
  33. measure an ISP's performance, while RTFM provides instrumentation 
  34. which may be used INTERNALLY in an ISP's network to measure flows 
  35. and performance. Steve Corbato gave a short presentation of his recent 
  36. work on high-speed polling of router variables.
  37.  
  38. We will publish a detailed list of references to these on the RTFM Web 
  39. page (http://www.auckland.ac.nz/net/Internet/rtfm/TOP.html). 
  40.  
  41. The 'Flow Measurement: Architecture' Draft was reviewed. Many 
  42. people asked interesting questions, but only editorial changes were 
  43. requested. We will run a two-week call on this draft, make these 
  44. changes so as to produce a new Draft early in March. After a two-week 
  45. last call we will submit this Draft to IESG for publication as an 
  46. experimental RFC. 
  47.  
  48. The 'Flow Measurement: Meter MIB' document was reviewed. A number 
  49. of significant changes to this have been suggested since it was 
  50. published in mid-February. These will be made, and a new draft 
  51. published. If - after a two-week last call - there are no requests for 
  52. further changes, we will submit this Draft to IESG for publication as an 
  53. experimental RFC. 
  54.  
  55. Two further new Drafts, 'Flow Measurement: Background' and 'Flow 
  56. Measurement: Experience' will be prepared before the Montreal IETF 
  57. meeting. These are intended for publication as information RFCs. 
  58.  
  59. The group's next work item, a revised version of the traffic flow model, 
  60. was considered. Two topics of interest were raised: 
  61.  
  62. - How well does the meter cope with running out of resources? 
  63. Switching to a standby rule set so as to reduce the rate new flow records 
  64. are created has worked well in practice, but we should consider sending 
  65. an alarm request to the manager. 
  66.  
  67. - Would it be sensible to have a hard disk in the meter? 
  68. This would make the meter less simple than it is now, but it would let 
  69. the meter save its configuration data such a rule sets so that it could 
  70. restart after a power outage without needing a download from the 
  71. manager. It would also allow the meter to write its flow table to disk 
  72. when a manager commanded it to do so. 
  73.  
  74. We will collect further ideas on the mailing list for discussion in 
  75. Montreal.
  76.  
  77. -------------------------------------------------------------------
  78.