home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / bmwg / bmwg-minutes-96jun.txt < prev    next >
Text File  |  1996-10-07  |  7KB  |  156 lines
  1. Editor's note:  These minutes have not been edited.
  2.  
  3.  
  4.  
  5. Minutes of the Benchmarking Methodology Workgroup 
  6.  
  7. Report by Kevin Dubray
  8.  
  9. Approximately 45 people attended this meeting. 
  10.  
  11. 1. Agenda.
  12.  
  13. The proposed agenda for this BMWG was accepted as follows: 
  14.  
  15. - Administration
  16. - Discussion of Proposed Cell/Call benchmarking - Discussion of LAN 
  17. Switch Draft
  18.  
  19. 2. Administration.
  20.  
  21. Kevin Dubray introduced himself as co-chair of the BMWG, replacing 
  22. Jim McQuaid. Jim was thanked for his service. Dubray also reminded 
  23. attendees of the meeting time and place of the IP Provider Metrics 
  24. (IPPM) half of the BMWG.
  25.  
  26. It was announced that the "Benchmarking Methodology for Network 
  27. Interconnect Devices" draft was approved as an informational RFC 
  28. 1944. 
  29.  
  30. It was reported that a discrepancy had already been found in RFC 1944 
  31. with regards to a range of addresses. Scott Bradner informed the group 
  32. that the error was reported to the RFC Editor. As of the meeting, Scott 
  33. had not heard back.
  34.  
  35. A question was raised on what to do in the interim with anomalies 
  36. found in BMWG documents. It was offered that a list of "Outstanding 
  37. Issues" would be offered periodically through the BMWG mailing list 
  38. and stored via the archive. Dubray volunteered to manage this. 
  39.  
  40. Dubray mentioned that the BMWG charter and goals were updated to 
  41. better reflect the other BMWG effort, IPPM, chaired by Guy Almes. 
  42. The charter can be accessed via the URL:
  43.  
  44. http://www.ietf.cnri.reston.va.us/html.charters/bmwg-charter.html 
  45.  
  46.  
  47. 3. Workplan - Proposed Cell/Call Benchmarking. 
  48.  
  49. An assignment from the last BMWG meeting, Dubray presented his 
  50. action item for a proposed Cell/Call Benchmarking workplan that was 
  51. previously distributed on the mailing list. Given the cell focused 
  52. benchmarking activities of other organizations (ATM Forum, ITU-T, 
  53. etc.), the scope of the proposed workplan focused on the definition of 
  54. the terminology and methodology of benchmarking cell-
  55. forwarding/connection-oriented devices in PACKET-BASED 
  56. internetworks.
  57.  
  58. A vote was made on whether to proceed with the workplan. There was 
  59. consensus that the group move forward with this effort. 
  60.  
  61. The workplan suggested that the effort be split into two distinct parts: 
  62.  
  63. 1. Draft a document identifying or defining the relevant terminology 
  64. and metrics in characterizing the performance of these devices. 
  65.  
  66. 2. Draft a document defining the methodology of collecting the metrics 
  67. produced in the Terminology document. 
  68.  
  69. Item 2 would only occur after consensus was reach on Item 1. 
  70.  
  71. A volunteer was solicited to head the Metric and Terminology effort. 
  72. Robert Craig gratiously volunteered. Robert is to make an initial draft 
  73. available on the mailing list.
  74.  
  75.  
  76. 4. LAN Switch Benchmarking Draft.
  77.  
  78. Bob Mandeville was on hand to discuss the latest revision of the LAN 
  79. Switch Benchmarking Draft. This draft has evolved significantly since 
  80. its last version. In the latest version, Bob modified the draft to: 
  81.  
  82. - Focus on the identification of related metrics and terminology, much 
  83. like RFC 1242.
  84.  
  85. - Expand the draft's scope beyond Ethernet switches. 
  86.  
  87. There was a discussion on how various media will be supported, given 
  88. the inherent differences between, for instance, deterministic media and 
  89. contention-based media. Bob's response was to have a master document 
  90. that would attempt to address issues in a most generic fashion. When 
  91. specific topics warranted a more focused discussion, separate memos 
  92. addressing these issues could be issued.
  93.  
  94. An issue was brought up that most of the suggested metrics' stimuli were 
  95. monolithic in style; further, the stimuli were offered outside the 
  96. context of any application. It was cited that application-specific tests 
  97. introduced many variables that made characterization difficult (e.g. 
  98. How does running a file transfer on a 8086 PC vs Pentium-based PC using 
  99. different protocol stacks, affect a switch's benchmark?) Another 
  100. example, however, was offered citing the need to distinguish how a 
  101. switch handles that file transfer in light of, say, video traffic. It was 
  102. agreed that reliance on one specific application or another wasn't 
  103. necessarily desirable. However, that is not to say that the use of 
  104. generalized, application-like stimuli (e.g., the bursty nature of data 
  105. transfers vs. more "constant" bit rate of video) isn't undesirable. 
  106. Further, it may be desirable to see how the application of one stimulli 
  107. impacts the other across the tested system.
  108.  
  109. On the draft's discussion of bursts, Bob was cautioned that it was one 
  110. thing to say, "Traffic is bursty,"; characterizing traffic as a "burst of 
  111. one," is saying something else.
  112.  
  113. The multidimensional traffic item was brought up. Several examples 
  114. were offered (e.g., broadcast, multicast, Full Duplex Ethernet) on why 
  115. it was difficult to characterize the behavior of a system with the use of 
  116. multidimensional traffic. The consensus appeared to be that this is a 
  117. useful concept if and only if the impact of the stimuli on the tested 
  118. system could clearly be ascertained and communicated. 
  119.  
  120. Bob asked whether jitter should be a addressed in the document. A 
  121. comment was made to the effect that if you consider jitter, you should 
  122. consider both the VBR and CBR cases, but only if you can clearly 
  123. describe the observed behavior.
  124.  
  125. Bob queried the group as to whether the document should attempt to 
  126. define a switch. The group generally agreed that there was more 
  127. marketecture than technology these days in the taxonomy of a switch. 
  128. Further, if there was enough distinct qualities between a generic 
  129. switch, a Layer 2 switch or a Layer 3 frame/packet switch, subsequent 
  130. work could address those features specifically. It was offered that 
  131. regardless of the "type" of LAN switch, most of the concepts offered in 
  132. the current draft could be applied. 
  133.  
  134. In general, there was a positive air regarding the draft. Bob was going 
  135. to put the latest draft on the mailing list for further discussion. The 
  136. draft should be discussed enough on the mailing list so that by the next 
  137. meeting, the draft can be forwarded for consideration as a RFC.
  138.  
  139.  
  140. 5. Assignments & Goals:
  141.  
  142. The next round of goals slated for the BMWG by the next meeting are: 
  143.  
  144. 1. Present for discussion a preliminary draft on the Benchmarking 
  145. Terminology for Cell Forwarding/Connection-Oriented Internetworking 
  146. Devices. (Robert Craig)
  147.  
  148. 2. Prepare the LAN Switch Benchmarking Terminology Draft to the 
  149. point where its ready to forward for consideration as a RFC by next 
  150. meeting. (Bob Mandeville)
  151.  
  152.  
  153. The meeting concluded with Dubray requesting that people monitor and 
  154. participate in the discussions on the BMWG mailing list so that 
  155. expeditious progress can be made in the above areas.
  156.