From mailman-admin@ietf.org Fri Aug 1 09:32:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14062 for ; Fri, 1 Aug 2003 09:18:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iZhZ-0000ie-Gd for ippm-archive@lists.ietf.org; Fri, 01 Aug 2003 09:12:09 -0400 Date: Fri, 01 Aug 2003 09:12:09 -0400 Message-ID: <20030801131209.29120.27738.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: ippm-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, ippm-request@ietf.org ) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for ippm-archive@lists.ietf.org: List Password // URL ---- -------- ippm@ietf.org wurudu https://www1.ietf.org/mailman/options/ippm/ippm-archive%40lists.ietf.org From exim@www1.ietf.org Fri Aug 1 13:59:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02417 for ; Fri, 1 Aug 2003 13:59:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ieBe-0005I3-As for ippm-archive@odin.ietf.org; Fri, 01 Aug 2003 13:59:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h71HxU6l020328 for ippm-archive@odin.ietf.org; Fri, 1 Aug 2003 13:59:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iac5-0005Fl-Ec for ippm-web-archive@optimus.ietf.org; Fri, 01 Aug 2003 10:10:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17676 for ; Fri, 1 Aug 2003 09:36:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iZuw-0007UK-00 for ippm-web-archive@ietf.org; Fri, 01 Aug 2003 09:25:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iZmI-0005pG-04 for ippm-web-archive@ietf.org; Fri, 01 Aug 2003 09:17:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iZhT-0000Zl-87 for ippm-web-archive@ietf.org; Fri, 01 Aug 2003 09:12:03 -0400 Date: Fri, 01 Aug 2003 09:12:03 -0400 Message-ID: <20030801131203.29120.39554.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: ippm-web-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, ippm-request@ietf.org ) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for ippm-web-archive@ietf.org: List Password // URL ---- -------- ippm@ietf.org ikrodi https://www1.ietf.org/mailman/options/ippm/ippm-web-archive%40ietf.org From ippm-admin@ietf.org Sun Aug 17 21:51:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25822 for ; Sun, 17 Aug 2003 21:51:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oZAi-0001ix-PB; Sun, 17 Aug 2003 21:51:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oZ9k-0001iJ-6v for ippm@optimus.ietf.org; Sun, 17 Aug 2003 21:50:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25779 for ; Sun, 17 Aug 2003 21:49:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oZ9h-00041h-00 for ippm@ietf.org; Sun, 17 Aug 2003 21:49:57 -0400 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 19oZ9g-00041e-00 for ippm@ietf.org; Sun, 17 Aug 2003 21:49:56 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 198CD7B4C8; Sun, 17 Aug 2003 21:49:57 -0400 (EDT) Received: from aa109.internet2.edu (wlan238.internet2.edu [207.75.165.238]) by basie.internet2.edu (Postfix) with ESMTP id 17ED37B487; Sun, 17 Aug 2003 21:49:56 -0400 (EDT) Date: Sun, 17 Aug 2003 21:49:55 -0400 From: Matthew J Zekauskas To: ippm@ietf.org Cc: Matt Zekauskas , Merike Kaeo , jerry_mccollom@agilent.com Message-ID: <388038489.1061156995@localhost> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by AMaViS 0.3.12pre8 Content-Transfer-Encoding: 7bit Subject: [ippm] Version 00 Minutes for the IPPM meeting in Vienna at IETF-57 Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Here is a draft copy. My apologies for taking so long... I can say for one thing having a massive power failure right around the last minute doesn't help :). Let me or the list know if you have comments. They were probably due Friday, although I haven't received any nagging reminders yet... --Matt p.s.: these, along with the presentations are available at http://people.internet2.edu/~matt/IPPM/Meetings/ietf57/ , at least until the official minutes come out. ------------------------------------------------------- IETF IP Performance Metrics WG (ippm) Tuesday, July 15, 2003 at 09:00 to 11:30 ======================================== The meeting was moderated by the working group chairs, Matt Zekauskas and Merike Kaeo. Al Morton, and Henk Uijterwaal took notes, which were edited into these minutes by the chairs. AGENDA 1. Agenda Bashing 2. Packet Reordering 3. Reordering Density 4. IPPM-MIB & Registry 5. Status, Milestones & Futures 2. Packet Reordering --Al Morton Al Morton led off the meat of the meeting with a report on the reordering metric progress. Many editorial changes were made from -02 to -03 to clarify text, and there are more in progress. A reordering-free-run metric was added based on Jon Bennett's comments in the last meeting. This metric characterizes how often reordering happens (along with previous gap metric and general frequency metric). Comment from Jon: want to answer the question how often do you get packets out of order. This is important for some applications that need in-order packets. Applications that run well when in-order (or increasing order) want a feel for how much "order" there is. Matt asked why is gap metric not good enough. Jon replied that it doesn't show how often reordering happens. Basically, the 'beginning of reordering event' is defined. You can't know when the event ends, in order to keep the metric orthogonal to loss. Call the places where a sequence number increases, but skips the 'reordering discontinuity'. The Reordering Gap is the difference between discontinuities. The reordering free run says how many packets arrive in order. To some extent, the gap shows the "early packets", while reordering free shows the "late packets". Al mentioned two pending updates. First, separating reordering by packet sequence numbers and other views (time, byte counts (TCP sequence numbers). Second, clarify the base "nonreversing sequence" metric so that it reports "true" for packets that are out of sequence by it's definition, false otherwise (currently, it's not as clear and inverted). One open issue that was mentioned: dealing with fragmentation. The current draft says that you only consider reassembled IP datagrams (and that's all it says). Jerry Perser (spirent) would like all reordering to be noted -- reassembly could hide the case where a datagram was fragmented, the fragments reordered, and then reassembled. Jerry will supply some text for the next draft revision. 3. Reordering Density --Jerry McCollom Next, Jerry McCollom from Agilent gave a presentation on reordering density, a separate characterization metric developed at the University of Colorado at Fort Collins. The authors were not present, but Jerry has been working with them, and presented slides they produced (see slides). The metric has a model of a buffer, and looks at how many packets are stored in the buffer to compute the metric. If the buffer overflows, those packets are considered lost. If the duplicates arrive, they are ignored. The audience (and mailing list members) have questioned this mixing of loss and reordering -- there will be a new draft after the meeting that should address (some of?) the concerns. This led to a good general reordering discussion, including adding usage notes to each metric (where it works well, when it fails) and having each metric indicate when it is out-of-scope (if such a condition exists). Greg Ryan made a number of points, including that it is "squishy" as to what exactly is measured; the drafts should explain what the metric measures compared to a complete characterization of reordering (perhaps edit distance), and give some examples. It is very important to specify when the "domain of validity" is exceeded... for example, the underlying assumption with both drafts is that reordering does not happen very often (otherwise "frequency of reordering" and "reordering free gaps" don't make much sense). What happens if the data is "completely messed up" -- say the packets arrive in truly random order. Greg is interested in providing some text to Al about edit distance. He will comment to the list. Jon Bennett probed how reordering density interacts with packet loss. Jerry said that the metric is density not loss. The metric assumes a threshold (the buffer size) where packet is lost and leaves it at that. The authors believe that a characterization of loss needs to be added; how often are packets lost? Jon asked what happens if the threshold is wrong? It depends on the application data stream in the end. So Jon wondered if the metric tried to represent a prototypical application... and then time might become more relevant than distance, especially for real time applications. Jerry said that without much thought it seems that it's possible to compute a sensible threshold that would cover a large number of applications. Jon noted that the metric keeps state - the packets in he buffer. Thus it seems like there might be a number of metrics for different applications. Either a metric tells me something intuitively or it's specific to an application. It seems like this metric is too complicated to be intuitive, but not complicated enough to match an application. Jon also noted that with "tool devices", having to keep state (particularly on a high-speed test) is impossible, or places a high load on the device. You have to accept that there may be some deficiency... but being loss impervious might be more practical than trying to emulate an application. Al thanked Jerry for coming to represent the metric. It's difficult to maintain orthogonality between loss and reordering, but that's what the current reordering draft tries to do. In the -00 draft of reordering density, there is an example where the metric counts "early packets" out of order. The current draft calls "late packets" out of order, for one thing to distinguish loss (only way to distinguish is to have the late packet arrive). Jerry M. mentioned that in the second examples... some of packets in buffer reordered, doesn't catch. Before releasing the packets, one could take a look at what have in buffer to accurately reflect metric. Al thought that sounded reasonable... he noted that one of the problems in the industry right now is that multiple vendors look at the same same stream would call different packets out of order; we need one definition that everyone agrees to. Jerry Purser wanted to pursue how easily such a metric could be interpreted, say by a technical support person. Look at the first graph on slide 9. What does it tell you? It looks like two packets got pushed out. Al noted that two packets out of order, but the chart has three bars. Jerry M. noted that the 0 slot represents in-order packets. Jerry P. was trying to understand normalization... How many times was packet 3 displaced? That's not what we're measuring. Merike noted it was how many times packet was in a particular buffer slot. Jerry M said that if packet 3 is what caused us to start buffering in the first place... one tweak could be to see 3 and release, displacement of 3 for packet. Jerry P was trying to think as support person on line. Get that chart, can you figured out what happened from that chart? 55% of time everyting is in order 45% of packets experienced some reordering Jerry P was wondering if it was reordering or buffering. 4. IPPM-MIB & Registry --Emile Stephan Next was Emile Stephan to report on Reporting MIB progress. Major changes include VACM support for security instead of roll-your-own, and tweaking all the tables so that VACM access made sense (mainly replacing pointers with data in some cases). Emile also added 'burst' and 'multiburst' packet types -- MattZ asked where this came from, and didn't get a clear answer. He will take it to the mailing list. No comments from floor, other than Andy Bierman who noted there were still a number of problems (probably due to the major reorganization to satisfy VACM). The chairs asked had anyone read draft. No responses other than Andy in this audience. The chairs then followed up with who would use it. No responses in this audience. This is different from the response in earlier meetings, where there was general interest. 5. Status, Milestones & Futures --Matt Zekauskas Finally, Matt once again went over the milestones. The OWAMP requirements document was cycling between the author and the IESG for clarification of the security section. OWAMP itself was being updated based on a sample implementation. More information on the implementation is available at http://owamp.internet2.edu/ . The MIB work has been progressing. Matt noted areas where there was interest, but it had waned. (In particular: Cap, a BTC implementation; parameter sensitivity; ITU vs IPPM metrics; path bottleneck definitions; and the applicability statement.) On the applicability statement: Merike and Henk Uijterwaal have repeatedy prodded vendors, and they indicate interest and promise text, but the text never materializes. They want to shelve it as an ippm item for now. Perhaps interest might be generated in doing it in 'ispmon', should it become a WG from a BOF? MattZ noted that a probe will be sent to the list, and if no interest is generated, the chairs would drop the items from the charter milestones. Al noted that the advancing metrics draft was really needed. He wanted to know if the -00 draft was still available even though it had expired? Matt said that he had one, and that it was also available from some of the unofficial internet-drafts archives. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Sun Aug 17 21:51:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25837 for ; Sun, 17 Aug 2003 21:51:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oZB5-0001l3-0H for ippm-archive@odin.ietf.org; Sun, 17 Aug 2003 21:51:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7I1pMA3006755 for ippm-archive@odin.ietf.org; Sun, 17 Aug 2003 21:51:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oZB4-0001ks-Pz for ippm-web-archive@optimus.ietf.org; Sun, 17 Aug 2003 21:51:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25801 for ; Sun, 17 Aug 2003 21:51:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oZB1-00042d-00 for ippm-web-archive@ietf.org; Sun, 17 Aug 2003 21:51:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19oZB1-00042Z-00 for ippm-web-archive@ietf.org; Sun, 17 Aug 2003 21:51:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oZAi-0001ix-PB; Sun, 17 Aug 2003 21:51:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oZ9k-0001iJ-6v for ippm@optimus.ietf.org; Sun, 17 Aug 2003 21:50:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25779 for ; Sun, 17 Aug 2003 21:49:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oZ9h-00041h-00 for ippm@ietf.org; Sun, 17 Aug 2003 21:49:57 -0400 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 19oZ9g-00041e-00 for ippm@ietf.org; Sun, 17 Aug 2003 21:49:56 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 198CD7B4C8; Sun, 17 Aug 2003 21:49:57 -0400 (EDT) Received: from aa109.internet2.edu (wlan238.internet2.edu [207.75.165.238]) by basie.internet2.edu (Postfix) with ESMTP id 17ED37B487; Sun, 17 Aug 2003 21:49:56 -0400 (EDT) Date: Sun, 17 Aug 2003 21:49:55 -0400 From: Matthew J Zekauskas To: ippm@ietf.org Cc: Matt Zekauskas , Merike Kaeo , jerry_mccollom@agilent.com Message-ID: <388038489.1061156995@localhost> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by AMaViS 0.3.12pre8 Content-Transfer-Encoding: 7bit Subject: [ippm] Version 00 Minutes for the IPPM meeting in Vienna at IETF-57 Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Here is a draft copy. My apologies for taking so long... I can say for one thing having a massive power failure right around the last minute doesn't help :). Let me or the list know if you have comments. They were probably due Friday, although I haven't received any nagging reminders yet... --Matt p.s.: these, along with the presentations are available at http://people.internet2.edu/~matt/IPPM/Meetings/ietf57/ , at least until the official minutes come out. ------------------------------------------------------- IETF IP Performance Metrics WG (ippm) Tuesday, July 15, 2003 at 09:00 to 11:30 ======================================== The meeting was moderated by the working group chairs, Matt Zekauskas and Merike Kaeo. Al Morton, and Henk Uijterwaal took notes, which were edited into these minutes by the chairs. AGENDA 1. Agenda Bashing 2. Packet Reordering 3. Reordering Density 4. IPPM-MIB & Registry 5. Status, Milestones & Futures 2. Packet Reordering --Al Morton Al Morton led off the meat of the meeting with a report on the reordering metric progress. Many editorial changes were made from -02 to -03 to clarify text, and there are more in progress. A reordering-free-run metric was added based on Jon Bennett's comments in the last meeting. This metric characterizes how often reordering happens (along with previous gap metric and general frequency metric). Comment from Jon: want to answer the question how often do you get packets out of order. This is important for some applications that need in-order packets. Applications that run well when in-order (or increasing order) want a feel for how much "order" there is. Matt asked why is gap metric not good enough. Jon replied that it doesn't show how often reordering happens. Basically, the 'beginning of reordering event' is defined. You can't know when the event ends, in order to keep the metric orthogonal to loss. Call the places where a sequence number increases, but skips the 'reordering discontinuity'. The Reordering Gap is the difference between discontinuities. The reordering free run says how many packets arrive in order. To some extent, the gap shows the "early packets", while reordering free shows the "late packets". Al mentioned two pending updates. First, separating reordering by packet sequence numbers and other views (time, byte counts (TCP sequence numbers). Second, clarify the base "nonreversing sequence" metric so that it reports "true" for packets that are out of sequence by it's definition, false otherwise (currently, it's not as clear and inverted). One open issue that was mentioned: dealing with fragmentation. The current draft says that you only consider reassembled IP datagrams (and that's all it says). Jerry Perser (spirent) would like all reordering to be noted -- reassembly could hide the case where a datagram was fragmented, the fragments reordered, and then reassembled. Jerry will supply some text for the next draft revision. 3. Reordering Density --Jerry McCollom Next, Jerry McCollom from Agilent gave a presentation on reordering density, a separate characterization metric developed at the University of Colorado at Fort Collins. The authors were not present, but Jerry has been working with them, and presented slides they produced (see slides). The metric has a model of a buffer, and looks at how many packets are stored in the buffer to compute the metric. If the buffer overflows, those packets are considered lost. If the duplicates arrive, they are ignored. The audience (and mailing list members) have questioned this mixing of loss and reordering -- there will be a new draft after the meeting that should address (some of?) the concerns. This led to a good general reordering discussion, including adding usage notes to each metric (where it works well, when it fails) and having each metric indicate when it is out-of-scope (if such a condition exists). Greg Ryan made a number of points, including that it is "squishy" as to what exactly is measured; the drafts should explain what the metric measures compared to a complete characterization of reordering (perhaps edit distance), and give some examples. It is very important to specify when the "domain of validity" is exceeded... for example, the underlying assumption with both drafts is that reordering does not happen very often (otherwise "frequency of reordering" and "reordering free gaps" don't make much sense). What happens if the data is "completely messed up" -- say the packets arrive in truly random order. Greg is interested in providing some text to Al about edit distance. He will comment to the list. Jon Bennett probed how reordering density interacts with packet loss. Jerry said that the metric is density not loss. The metric assumes a threshold (the buffer size) where packet is lost and leaves it at that. The authors believe that a characterization of loss needs to be added; how often are packets lost? Jon asked what happens if the threshold is wrong? It depends on the application data stream in the end. So Jon wondered if the metric tried to represent a prototypical application... and then time might become more relevant than distance, especially for real time applications. Jerry said that without much thought it seems that it's possible to compute a sensible threshold that would cover a large number of applications. Jon noted that the metric keeps state - the packets in he buffer. Thus it seems like there might be a number of metrics for different applications. Either a metric tells me something intuitively or it's specific to an application. It seems like this metric is too complicated to be intuitive, but not complicated enough to match an application. Jon also noted that with "tool devices", having to keep state (particularly on a high-speed test) is impossible, or places a high load on the device. You have to accept that there may be some deficiency... but being loss impervious might be more practical than trying to emulate an application. Al thanked Jerry for coming to represent the metric. It's difficult to maintain orthogonality between loss and reordering, but that's what the current reordering draft tries to do. In the -00 draft of reordering density, there is an example where the metric counts "early packets" out of order. The current draft calls "late packets" out of order, for one thing to distinguish loss (only way to distinguish is to have the late packet arrive). Jerry M. mentioned that in the second examples... some of packets in buffer reordered, doesn't catch. Before releasing the packets, one could take a look at what have in buffer to accurately reflect metric. Al thought that sounded reasonable... he noted that one of the problems in the industry right now is that multiple vendors look at the same same stream would call different packets out of order; we need one definition that everyone agrees to. Jerry Purser wanted to pursue how easily such a metric could be interpreted, say by a technical support person. Look at the first graph on slide 9. What does it tell you? It looks like two packets got pushed out. Al noted that two packets out of order, but the chart has three bars. Jerry M. noted that the 0 slot represents in-order packets. Jerry P. was trying to understand normalization... How many times was packet 3 displaced? That's not what we're measuring. Merike noted it was how many times packet was in a particular buffer slot. Jerry M said that if packet 3 is what caused us to start buffering in the first place... one tweak could be to see 3 and release, displacement of 3 for packet. Jerry P was trying to think as support person on line. Get that chart, can you figured out what happened from that chart? 55% of time everyting is in order 45% of packets experienced some reordering Jerry P was wondering if it was reordering or buffering. 4. IPPM-MIB & Registry --Emile Stephan Next was Emile Stephan to report on Reporting MIB progress. Major changes include VACM support for security instead of roll-your-own, and tweaking all the tables so that VACM access made sense (mainly replacing pointers with data in some cases). Emile also added 'burst' and 'multiburst' packet types -- MattZ asked where this came from, and didn't get a clear answer. He will take it to the mailing list. No comments from floor, other than Andy Bierman who noted there were still a number of problems (probably due to the major reorganization to satisfy VACM). The chairs asked had anyone read draft. No responses other than Andy in this audience. The chairs then followed up with who would use it. No responses in this audience. This is different from the response in earlier meetings, where there was general interest. 5. Status, Milestones & Futures --Matt Zekauskas Finally, Matt once again went over the milestones. The OWAMP requirements document was cycling between the author and the IESG for clarification of the security section. OWAMP itself was being updated based on a sample implementation. More information on the implementation is available at http://owamp.internet2.edu/ . The MIB work has been progressing. Matt noted areas where there was interest, but it had waned. (In particular: Cap, a BTC implementation; parameter sensitivity; ITU vs IPPM metrics; path bottleneck definitions; and the applicability statement.) On the applicability statement: Merike and Henk Uijterwaal have repeatedy prodded vendors, and they indicate interest and promise text, but the text never materializes. They want to shelve it as an ippm item for now. Perhaps interest might be generated in doing it in 'ispmon', should it become a WG from a BOF? MattZ noted that a probe will be sent to the list, and if no interest is generated, the chairs would drop the items from the charter milestones. Al noted that the advancing metrics draft was really needed. He wanted to know if the -00 draft was still available even though it had expired? Matt said that he had one, and that it was also available from some of the unofficial internet-drafts archives. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Mon Aug 18 10:31:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20946 for ; Mon, 18 Aug 2003 10:31:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ol2E-0007Pr-LB; Mon, 18 Aug 2003 10:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ol1Q-0007OS-Ao for ippm@optimus.ietf.org; Mon, 18 Aug 2003 10:30:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20891 for ; Mon, 18 Aug 2003 10:30:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ol1N-0007PN-00 for ippm@ietf.org; Mon, 18 Aug 2003 10:30:09 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with esmtp (Exim 4.12) id 19ol1M-0007P4-00 for ippm@ietf.org; Mon, 18 Aug 2003 10:30:08 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 18 Aug 2003 16:28:25 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [ippm] Version 00 Minutes for the IPPM meeting in Vienna at IETF-57: "4. IPPM-MIB & Registry" Date: Mon, 18 Aug 2003 16:28:24 +0200 Message-ID: <3CA72DA73F5F02469A09AB598BFFAD38279326@ftrdmel2.rd.francetelecom.fr> Thread-Topic: [ippm] Version 00 Minutes for the IPPM meeting in Vienna at IETF-57 Thread-Index: AcNlK1GuWkKlL7l6SFmUJEB8UpTDVgAYywnw From: "STEPHAN Emile FTRD/DAC/LAN" To: "Matthew J Zekauskas" , "Merike Kaeo" Cc: X-OriginalArrivalTime: 18 Aug 2003 14:28:25.0652 (UTC) FILETIME=[FC278740:01C36594] Content-Transfer-Encoding: quoted-printable Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Dear Merike and Matt, I have several comments on the minutes: During this session I did not present anything regarding the IPPM registry because the WG last call of the IPPM registry document endded 2 months ago. So the title of the section 4 should be "4. IPPM MIB" instead of "4. IPPM-MIB & Registry". The state of this document might be given in the section '5. Status, Milestones & Futures'. Regarding 'burst' and 'multiburst', we just completed the list of generation mode. is there a link to the advanced metrics document ? Best Regards Emile =09 > -----Message d'origine----- > De : Matthew J Zekauskas [mailto:matt@internet2.edu] > Envoye : lundi 18 aout 2003 03:50 > A : ippm@ietf.org > Cc : Matt Zekauskas; Merike Kaeo; jerry_mccollom@agilent.com > Objet : [ippm] Version 00 Minutes for the IPPM meeting in Vienna at > IETF-57 >=20 >=20 > Here is a draft copy. My apologies for taking so long... > I can say for one thing having a massive power failure right > around the last minute doesn't help :). >=20 > Let me or the list know if you have comments. They were probably > due Friday, although I haven't received any nagging reminders yet... >=20 > --Matt >=20 > p.s.: these, along with the presentations are available at > http://people.internet2.edu/~matt/IPPM/Meetings/ietf57/ , > at least until the official minutes come out. >=20 > ------------------------------------------------------- >=20 > IETF IP Performance Metrics WG (ippm) > Tuesday, July 15, 2003 at 09:00 to 11:30 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > The meeting was moderated by the working group chairs, Matt Zekauskas > and Merike Kaeo. Al Morton, and Henk Uijterwaal took notes, which > were edited into these minutes by the chairs. >=20 > AGENDA > 1. Agenda Bashing > 2. Packet Reordering > 3. Reordering Density > 4. IPPM-MIB & Registry > 5. Status, Milestones & Futures >=20 >=20 >=20 >=20 > 2. Packet Reordering > --Al Morton >=20 > Al Morton led off the meat of the meeting with a report on=20 > the reordering > metric progress. Many editorial changes were made from -02=20 > to -03 to clarify > text, and there are more in progress. A reordering-free-run metric > was added based on Jon Bennett's comments in the last meeting. This > metric characterizes how often reordering happens (along with=20 > previous gap > metric and general frequency metric). >=20 > Comment from Jon: want to answer the question how often do you get > packets out of order. This is important for some applications that > need in-order packets. Applications that run well when in-order > (or increasing order) want a feel for how much "order" there is. > Matt asked why is gap metric not good enough. Jon replied that it > doesn't show how often reordering happens. >=20 > Basically, the 'beginning of reordering event' is defined. You can't > know when the event ends, in order to keep the metric=20 > orthogonal to loss. > Call the places where a sequence number increases, but skips the > 'reordering discontinuity'. The Reordering Gap is the difference > between discontinuities. The reordering free run says how many > packets arrive in order. To some extent, the gap shows the > "early packets", while reordering free shows the "late packets". >=20 > Al mentioned two pending updates. First, separating=20 > reordering by packet > sequence numbers and other views (time, byte counts (TCP=20 > sequence numbers). > Second, clarify the base "nonreversing sequence" metric so=20 > that it reports > "true" for packets that are out of sequence by it's definition, false > otherwise (currently, it's not as clear and inverted). >=20 > One open issue that was mentioned: dealing with=20 > fragmentation. The current > draft says that you only consider reassembled IP datagrams (and that's > all it says). Jerry Perser (spirent) would like all=20 > reordering to be noted > -- reassembly could hide the case where a datagram was fragmented, the > fragments reordered, and then reassembled. Jerry will supply > some text for the next draft revision. >=20 >=20 >=20 >=20 > 3. Reordering Density > --Jerry McCollom >=20 > Next, Jerry McCollom from Agilent gave a presentation on reordering > density, a separate characterization metric developed at the=20 > University > of Colorado at Fort Collins. The authors were not present, but Jerry > has been working with them, and presented slides they produced (see > slides). The metric has a model of a buffer, and looks at > how many packets are stored in the buffer to compute the metric. > If the buffer overflows, those packets are considered lost. If > the duplicates arrive, they are ignored. The audience (and mailing > list members) have questioned this mixing of loss and reordering -- > there will be a new draft after the meeting that should address > (some of?) the concerns. >=20 > This led to a good general reordering discussion, including adding > usage notes to each metric (where it works well, when it fails) and > having each metric indicate when it is out-of-scope (if such a > condition exists). >=20 > Greg Ryan made a number of points, including that it is "squishy" > as to what exactly is measured; the drafts should explain what the > metric measures compared to a complete characterization of reordering > (perhaps edit distance), and give some examples. It is very important > to specify when the "domain of validity" is exceeded... for example, > the underlying assumption with both drafts is that reordering does > not happen very often (otherwise "frequency of reordering"=20 > and "reordering > free gaps" don't make much sense). What happens if the data is > "completely messed up" -- say the packets arrive in truly=20 > random order. > Greg is interested in providing some text to Al about edit distance. > He will comment to the list. >=20 > Jon Bennett probed how reordering density interacts with packet loss. > Jerry said that the metric is density not loss. The metric assumes > a threshold (the buffer size) where packet is lost and leaves=20 > it at that. > The authors believe that a characterization of loss needs to be added; > how often are packets lost? >=20 > Jon asked what happens if the threshold is wrong? It depends on > the application data stream in the end. So Jon wondered if the > metric tried to represent a prototypical application... and then > time might become more relevant than distance, especially for > real time applications. Jerry said that without much thought=20 > it seems that it's possible to > compute a sensible threshold that would cover a large number of > applications. Jon noted that the metric keeps state - the=20 > packets in he buffer. > Thus it seems like there might be a number of metrics for different > applications. Either a metric tells me something intuitively or it's > specific to an application. It seems like this metric is too > complicated to be intuitive, but not complicated enough to match > an application. >=20 > Jon also noted that with "tool devices", having to keep state > (particularly on a high-speed test) is impossible, or places a high > load on the device. You have to accept that there may be some > deficiency... but being loss impervious might be more practical than > trying to emulate an application. >=20 > Al thanked Jerry for coming to represent the metric. > It's difficult to maintain orthogonality between loss and reordering, > but that's what the current reordering draft tries to do. In the -00 > draft of reordering density, there is an example where the metric > counts "early packets" out of order. The current draft calls "late > packets" out of order, for one thing to distinguish loss (only way > to distinguish is to have the late packet arrive). >=20 > Jerry M. mentioned that in the second examples... some of packets in > buffer reordered, doesn't catch. Before releasing the packets, one > could take a look at what have in buffer to accurately reflect metric. >=20 > Al thought that sounded reasonable... he noted that one of=20 > the problems > in the industry right now is that multiple vendors look at the same > same stream would call different packets out of order; we need one > definition that everyone agrees to. >=20 > Jerry Purser wanted to pursue how easily such a metric could be > interpreted, say by a technical support person. Look at the first > graph on slide 9. What does it tell you? It looks like two packets > got pushed out. Al noted that two packets out of order, but the > chart has three bars. Jerry M. noted that the 0 slot represents > in-order packets. >=20 > Jerry P. was trying to understand normalization... How many times > was packet 3 displaced? That's not what we're measuring. > Merike noted it was how many times packet was in a particular buffer > slot. >=20 > Jerry M said that if packet 3 is what caused us to start buffering > in the first place... one tweak could be to see 3 and=20 > release, displacement > of 3 for packet. >=20 > Jerry P was trying to think as support person on line. Get=20 > that chart, > can you figured out what happened from that chart? > 55% of time everyting is in order > 45% of packets experienced some reordering > Jerry P was wondering if it was reordering or buffering. >=20 >=20 >=20 >=20 > 4. IPPM-MIB & Registry > --Emile Stephan >=20 > Next was Emile Stephan to report on Reporting MIB progress. =20 > Major changes > include VACM support for security instead of roll-your-own,=20 > and tweaking > all the tables so that VACM access made sense (mainly=20 > replacing pointers > with data in some cases). Emile also added 'burst' and 'multiburst' > packet types -- MattZ asked where this came from, and didn't get > a clear answer. He will take it to the mailing list. >=20 > No comments from floor, other than Andy Bierman who noted there were > still a number of problems (probably due to the major reorganization > to satisfy VACM). The chairs asked had anyone read draft. =20 > No responses > other than Andy in this audience. The chairs then followed=20 > up with who > would use it. No responses in this audience. This is=20 > different from the > response in earlier meetings, where there was general interest. >=20 >=20 >=20 >=20 > 5. Status, Milestones & Futures > --Matt Zekauskas >=20 > Finally, Matt once again went over the milestones. The OWAMP=20 > requirements > document was cycling between the author and the IESG for clarification > of the security section. OWAMP itself was being updated based on > a sample implementation. More information on the implementation is > available at http://owamp.internet2.edu/ . The MIB work has been > progressing. >=20 > Matt noted areas where there was interest, but it had waned. (In > particular: Cap, a BTC implementation; parameter sensitivity; ITU vs > IPPM metrics; path bottleneck definitions; and the applicability > statement.) On the applicability statement: Merike and Henk > Uijterwaal have repeatedy prodded vendors, and they indicate interest > and promise text, but the text never materializes. They want to > shelve it as an ippm item for now. Perhaps interest might be > generated in doing it in 'ispmon', should it become a WG from a BOF? > MattZ noted that a probe will be sent to the list, and if no interest > is generated, the chairs would drop the items from the charter > milestones. >=20 > Al noted that the advancing metrics draft was really needed. He > wanted to know if the -00 draft was still available even though > it had expired? Matt said that he had one, and that it was also > available from some of the unofficial internet-drafts archives. >=20 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/ippm >=20 _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Mon Aug 18 10:31:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20965 for ; Mon, 18 Aug 2003 10:31:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ol2Z-0007Sn-Pw for ippm-archive@odin.ietf.org; Mon, 18 Aug 2003 10:31:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7IEVN0L028685 for ippm-archive@odin.ietf.org; Mon, 18 Aug 2003 10:31:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ol2Z-0007Sa-LI for ippm-web-archive@optimus.ietf.org; Mon, 18 Aug 2003 10:31:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20924 for ; Mon, 18 Aug 2003 10:31:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ol2X-0007Pe-00 for ippm-web-archive@ietf.org; Mon, 18 Aug 2003 10:31:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ol2W-0007Pb-00 for ippm-web-archive@ietf.org; Mon, 18 Aug 2003 10:31:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ol2E-0007Pr-LB; Mon, 18 Aug 2003 10:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ol1Q-0007OS-Ao for ippm@optimus.ietf.org; Mon, 18 Aug 2003 10:30:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20891 for ; Mon, 18 Aug 2003 10:30:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ol1N-0007PN-00 for ippm@ietf.org; Mon, 18 Aug 2003 10:30:09 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with esmtp (Exim 4.12) id 19ol1M-0007P4-00 for ippm@ietf.org; Mon, 18 Aug 2003 10:30:08 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 18 Aug 2003 16:28:25 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [ippm] Version 00 Minutes for the IPPM meeting in Vienna at IETF-57: "4. IPPM-MIB & Registry" Date: Mon, 18 Aug 2003 16:28:24 +0200 Message-ID: <3CA72DA73F5F02469A09AB598BFFAD38279326@ftrdmel2.rd.francetelecom.fr> Thread-Topic: [ippm] Version 00 Minutes for the IPPM meeting in Vienna at IETF-57 Thread-Index: AcNlK1GuWkKlL7l6SFmUJEB8UpTDVgAYywnw From: "STEPHAN Emile FTRD/DAC/LAN" To: "Matthew J Zekauskas" , "Merike Kaeo" Cc: X-OriginalArrivalTime: 18 Aug 2003 14:28:25.0652 (UTC) FILETIME=[FC278740:01C36594] Content-Transfer-Encoding: quoted-printable Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Dear Merike and Matt, I have several comments on the minutes: During this session I did not present anything regarding the IPPM registry because the WG last call of the IPPM registry document endded 2 months ago. So the title of the section 4 should be "4. IPPM MIB" instead of "4. IPPM-MIB & Registry". The state of this document might be given in the section '5. Status, Milestones & Futures'. Regarding 'burst' and 'multiburst', we just completed the list of generation mode. is there a link to the advanced metrics document ? Best Regards Emile =09 > -----Message d'origine----- > De : Matthew J Zekauskas [mailto:matt@internet2.edu] > Envoye : lundi 18 aout 2003 03:50 > A : ippm@ietf.org > Cc : Matt Zekauskas; Merike Kaeo; jerry_mccollom@agilent.com > Objet : [ippm] Version 00 Minutes for the IPPM meeting in Vienna at > IETF-57 >=20 >=20 > Here is a draft copy. My apologies for taking so long... > I can say for one thing having a massive power failure right > around the last minute doesn't help :). >=20 > Let me or the list know if you have comments. They were probably > due Friday, although I haven't received any nagging reminders yet... >=20 > --Matt >=20 > p.s.: these, along with the presentations are available at > http://people.internet2.edu/~matt/IPPM/Meetings/ietf57/ , > at least until the official minutes come out. >=20 > ------------------------------------------------------- >=20 > IETF IP Performance Metrics WG (ippm) > Tuesday, July 15, 2003 at 09:00 to 11:30 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > The meeting was moderated by the working group chairs, Matt Zekauskas > and Merike Kaeo. Al Morton, and Henk Uijterwaal took notes, which > were edited into these minutes by the chairs. >=20 > AGENDA > 1. Agenda Bashing > 2. Packet Reordering > 3. Reordering Density > 4. IPPM-MIB & Registry > 5. Status, Milestones & Futures >=20 >=20 >=20 >=20 > 2. Packet Reordering > --Al Morton >=20 > Al Morton led off the meat of the meeting with a report on=20 > the reordering > metric progress. Many editorial changes were made from -02=20 > to -03 to clarify > text, and there are more in progress. A reordering-free-run metric > was added based on Jon Bennett's comments in the last meeting. This > metric characterizes how often reordering happens (along with=20 > previous gap > metric and general frequency metric). >=20 > Comment from Jon: want to answer the question how often do you get > packets out of order. This is important for some applications that > need in-order packets. Applications that run well when in-order > (or increasing order) want a feel for how much "order" there is. > Matt asked why is gap metric not good enough. Jon replied that it > doesn't show how often reordering happens. >=20 > Basically, the 'beginning of reordering event' is defined. You can't > know when the event ends, in order to keep the metric=20 > orthogonal to loss. > Call the places where a sequence number increases, but skips the > 'reordering discontinuity'. The Reordering Gap is the difference > between discontinuities. The reordering free run says how many > packets arrive in order. To some extent, the gap shows the > "early packets", while reordering free shows the "late packets". >=20 > Al mentioned two pending updates. First, separating=20 > reordering by packet > sequence numbers and other views (time, byte counts (TCP=20 > sequence numbers). > Second, clarify the base "nonreversing sequence" metric so=20 > that it reports > "true" for packets that are out of sequence by it's definition, false > otherwise (currently, it's not as clear and inverted). >=20 > One open issue that was mentioned: dealing with=20 > fragmentation. The current > draft says that you only consider reassembled IP datagrams (and that's > all it says). Jerry Perser (spirent) would like all=20 > reordering to be noted > -- reassembly could hide the case where a datagram was fragmented, the > fragments reordered, and then reassembled. Jerry will supply > some text for the next draft revision. >=20 >=20 >=20 >=20 > 3. Reordering Density > --Jerry McCollom >=20 > Next, Jerry McCollom from Agilent gave a presentation on reordering > density, a separate characterization metric developed at the=20 > University > of Colorado at Fort Collins. The authors were not present, but Jerry > has been working with them, and presented slides they produced (see > slides). The metric has a model of a buffer, and looks at > how many packets are stored in the buffer to compute the metric. > If the buffer overflows, those packets are considered lost. If > the duplicates arrive, they are ignored. The audience (and mailing > list members) have questioned this mixing of loss and reordering -- > there will be a new draft after the meeting that should address > (some of?) the concerns. >=20 > This led to a good general reordering discussion, including adding > usage notes to each metric (where it works well, when it fails) and > having each metric indicate when it is out-of-scope (if such a > condition exists). >=20 > Greg Ryan made a number of points, including that it is "squishy" > as to what exactly is measured; the drafts should explain what the > metric measures compared to a complete characterization of reordering > (perhaps edit distance), and give some examples. It is very important > to specify when the "domain of validity" is exceeded... for example, > the underlying assumption with both drafts is that reordering does > not happen very often (otherwise "frequency of reordering"=20 > and "reordering > free gaps" don't make much sense). What happens if the data is > "completely messed up" -- say the packets arrive in truly=20 > random order. > Greg is interested in providing some text to Al about edit distance. > He will comment to the list. >=20 > Jon Bennett probed how reordering density interacts with packet loss. > Jerry said that the metric is density not loss. The metric assumes > a threshold (the buffer size) where packet is lost and leaves=20 > it at that. > The authors believe that a characterization of loss needs to be added; > how often are packets lost? >=20 > Jon asked what happens if the threshold is wrong? It depends on > the application data stream in the end. So Jon wondered if the > metric tried to represent a prototypical application... and then > time might become more relevant than distance, especially for > real time applications. Jerry said that without much thought=20 > it seems that it's possible to > compute a sensible threshold that would cover a large number of > applications. Jon noted that the metric keeps state - the=20 > packets in he buffer. > Thus it seems like there might be a number of metrics for different > applications. Either a metric tells me something intuitively or it's > specific to an application. It seems like this metric is too > complicated to be intuitive, but not complicated enough to match > an application. >=20 > Jon also noted that with "tool devices", having to keep state > (particularly on a high-speed test) is impossible, or places a high > load on the device. You have to accept that there may be some > deficiency... but being loss impervious might be more practical than > trying to emulate an application. >=20 > Al thanked Jerry for coming to represent the metric. > It's difficult to maintain orthogonality between loss and reordering, > but that's what the current reordering draft tries to do. In the -00 > draft of reordering density, there is an example where the metric > counts "early packets" out of order. The current draft calls "late > packets" out of order, for one thing to distinguish loss (only way > to distinguish is to have the late packet arrive). >=20 > Jerry M. mentioned that in the second examples... some of packets in > buffer reordered, doesn't catch. Before releasing the packets, one > could take a look at what have in buffer to accurately reflect metric. >=20 > Al thought that sounded reasonable... he noted that one of=20 > the problems > in the industry right now is that multiple vendors look at the same > same stream would call different packets out of order; we need one > definition that everyone agrees to. >=20 > Jerry Purser wanted to pursue how easily such a metric could be > interpreted, say by a technical support person. Look at the first > graph on slide 9. What does it tell you? It looks like two packets > got pushed out. Al noted that two packets out of order, but the > chart has three bars. Jerry M. noted that the 0 slot represents > in-order packets. >=20 > Jerry P. was trying to understand normalization... How many times > was packet 3 displaced? That's not what we're measuring. > Merike noted it was how many times packet was in a particular buffer > slot. >=20 > Jerry M said that if packet 3 is what caused us to start buffering > in the first place... one tweak could be to see 3 and=20 > release, displacement > of 3 for packet. >=20 > Jerry P was trying to think as support person on line. Get=20 > that chart, > can you figured out what happened from that chart? > 55% of time everyting is in order > 45% of packets experienced some reordering > Jerry P was wondering if it was reordering or buffering. >=20 >=20 >=20 >=20 > 4. IPPM-MIB & Registry > --Emile Stephan >=20 > Next was Emile Stephan to report on Reporting MIB progress. =20 > Major changes > include VACM support for security instead of roll-your-own,=20 > and tweaking > all the tables so that VACM access made sense (mainly=20 > replacing pointers > with data in some cases). Emile also added 'burst' and 'multiburst' > packet types -- MattZ asked where this came from, and didn't get > a clear answer. He will take it to the mailing list. >=20 > No comments from floor, other than Andy Bierman who noted there were > still a number of problems (probably due to the major reorganization > to satisfy VACM). The chairs asked had anyone read draft. =20 > No responses > other than Andy in this audience. The chairs then followed=20 > up with who > would use it. No responses in this audience. This is=20 > different from the > response in earlier meetings, where there was general interest. >=20 >=20 >=20 >=20 > 5. Status, Milestones & Futures > --Matt Zekauskas >=20 > Finally, Matt once again went over the milestones. The OWAMP=20 > requirements > document was cycling between the author and the IESG for clarification > of the security section. OWAMP itself was being updated based on > a sample implementation. More information on the implementation is > available at http://owamp.internet2.edu/ . The MIB work has been > progressing. >=20 > Matt noted areas where there was interest, but it had waned. (In > particular: Cap, a BTC implementation; parameter sensitivity; ITU vs > IPPM metrics; path bottleneck definitions; and the applicability > statement.) On the applicability statement: Merike and Henk > Uijterwaal have repeatedy prodded vendors, and they indicate interest > and promise text, but the text never materializes. They want to > shelve it as an ippm item for now. Perhaps interest might be > generated in doing it in 'ispmon', should it become a WG from a BOF? > MattZ noted that a probe will be sent to the list, and if no interest > is generated, the chairs would drop the items from the charter > milestones. >=20 > Al noted that the advancing metrics draft was really needed. He > wanted to know if the -00 draft was still available even though > it had expired? Matt said that he had one, and that it was also > available from some of the unofficial internet-drafts archives. >=20 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/ippm >=20 _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Mon Aug 18 16:43:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03861 for ; Mon, 18 Aug 2003 16:43:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oqqC-0004XK-Ov; Mon, 18 Aug 2003 16:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oqpv-0004X5-7L for ippm@optimus.ietf.org; Mon, 18 Aug 2003 16:42:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03824 for ; Mon, 18 Aug 2003 16:42:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oqpt-0002QX-00 for ippm@ietf.org; Mon, 18 Aug 2003 16:42:41 -0400 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 19oqps-0002QU-00 for ippm@ietf.org; Mon, 18 Aug 2003 16:42:40 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id AAE327B508; Mon, 18 Aug 2003 16:42:35 -0400 (EDT) Received: from wlan238.internet2.edu (wlan238.internet2.edu [207.75.165.238]) by basie.internet2.edu (Postfix) with ESMTP id B0F3E7B4C5; Mon, 18 Aug 2003 16:42:34 -0400 (EDT) Date: Mon, 18 Aug 2003 16:42:34 -0400 From: Matthew J Zekauskas To: "STEPHAN Emile FTRD/DAC/LAN" Cc: Matthew J Zekauskas , Merike Kaeo , ippm@ietf.org Subject: RE: [ippm] Version 00 Minutes for the IPPM meeting in Vienna at IETF-57: "4. IPPM-MIB & Registry" Message-ID: <455988957.1061224954@localhost> In-Reply-To: <3CA72DA73F5F02469A09AB598BFFAD38279326@ftrdmel2.rd.francetelecom.fr> References: <3CA72DA73F5F02469A09AB598BFFAD38279326@ftrdmel2.rd.francetelecom.fr> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by AMaViS 0.3.12pre8 Content-Transfer-Encoding: 7bit Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit --On Monday, August 18, 2003 4:28 PM +0200 "STEPHAN Emile FTRD/DAC/LAN" wrote: > endded 2 months ago. So the title of the section 4 should be "4. IPPM > MIB" instead of "4. IPPM-MIB & Registry". The state of this document > might be given in the section '5. Status, Milestones & Futures'. Done. > > is there a link to the advanced metrics document ? I think you are referring to draft-bradner-metricstest-00.txt, and one unofficial copy is here: http://www.watersprings.org/pub/id/draft-bradner-metricstest-00.txt I believe Allison is working on finding someone to pick this up... --Matt _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Mon Aug 18 16:43:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03876 for ; Mon, 18 Aug 2003 16:43:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oqqO-0004ZT-0L for ippm-archive@odin.ietf.org; Mon, 18 Aug 2003 16:43:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7IKhBpp017565 for ippm-archive@odin.ietf.org; Mon, 18 Aug 2003 16:43:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oqqN-0004ZB-QK for ippm-web-archive@optimus.ietf.org; Mon, 18 Aug 2003 16:43:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03849 for ; Mon, 18 Aug 2003 16:43:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oqqL-0002Qq-00 for ippm-web-archive@ietf.org; Mon, 18 Aug 2003 16:43:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19oqqL-0002Qn-00 for ippm-web-archive@ietf.org; Mon, 18 Aug 2003 16:43:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oqqC-0004XK-Ov; Mon, 18 Aug 2003 16:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oqpv-0004X5-7L for ippm@optimus.ietf.org; Mon, 18 Aug 2003 16:42:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03824 for ; Mon, 18 Aug 2003 16:42:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oqpt-0002QX-00 for ippm@ietf.org; Mon, 18 Aug 2003 16:42:41 -0400 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 19oqps-0002QU-00 for ippm@ietf.org; Mon, 18 Aug 2003 16:42:40 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id AAE327B508; Mon, 18 Aug 2003 16:42:35 -0400 (EDT) Received: from wlan238.internet2.edu (wlan238.internet2.edu [207.75.165.238]) by basie.internet2.edu (Postfix) with ESMTP id B0F3E7B4C5; Mon, 18 Aug 2003 16:42:34 -0400 (EDT) Date: Mon, 18 Aug 2003 16:42:34 -0400 From: Matthew J Zekauskas To: "STEPHAN Emile FTRD/DAC/LAN" Cc: Matthew J Zekauskas , Merike Kaeo , ippm@ietf.org Subject: RE: [ippm] Version 00 Minutes for the IPPM meeting in Vienna at IETF-57: "4. IPPM-MIB & Registry" Message-ID: <455988957.1061224954@localhost> In-Reply-To: <3CA72DA73F5F02469A09AB598BFFAD38279326@ftrdmel2.rd.francetelecom.fr> References: <3CA72DA73F5F02469A09AB598BFFAD38279326@ftrdmel2.rd.francetelecom.fr> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by AMaViS 0.3.12pre8 Content-Transfer-Encoding: 7bit Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit --On Monday, August 18, 2003 4:28 PM +0200 "STEPHAN Emile FTRD/DAC/LAN" wrote: > endded 2 months ago. So the title of the section 4 should be "4. IPPM > MIB" instead of "4. IPPM-MIB & Registry". The state of this document > might be given in the section '5. Status, Milestones & Futures'. Done. > > is there a link to the advanced metrics document ? I think you are referring to draft-bradner-metricstest-00.txt, and one unofficial copy is here: http://www.watersprings.org/pub/id/draft-bradner-metricstest-00.txt I believe Allison is working on finding someone to pick this up... --Matt _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Wed Aug 20 02:57:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26644 for ; Wed, 20 Aug 2003 02:57:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pMt0-0004ys-Lu; Wed, 20 Aug 2003 02:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pMpY-0004qh-Cu for ippm@optimus.ietf.org; Wed, 20 Aug 2003 02:52:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26513 for ; Wed, 20 Aug 2003 02:52:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pMpU-0005EO-00 for ippm@ietf.org; Wed, 20 Aug 2003 02:52:24 -0400 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 19pMpT-0005EH-00 for ippm@ietf.org; Wed, 20 Aug 2003 02:52:23 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id A8CFF7B4E8; Wed, 20 Aug 2003 02:52:24 -0400 (EDT) Received: from wlan238.internet2.edu (wlan238.internet2.edu [207.75.165.238]) by basie.internet2.edu (Postfix) with ESMTP id AED897B4D4; Wed, 20 Aug 2003 02:52:23 -0400 (EDT) Date: Wed, 20 Aug 2003 02:52:23 -0400 From: Matthew J Zekauskas To: ippm@ietf.org Cc: Matt Zekauskas , Allison Mankin Message-ID: <578962954.1061347943@localhost> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by AMaViS 0.3.12pre8 Content-Transfer-Encoding: 7bit Subject: [ippm] ippm list temporarily moderated Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit FYI, Because I've been receiving tons of Sobig.F worm spews via a mibs list, I'm putting the ippm list into moderated mode for a few days. I don't have any evidence that it has been used as a conduit, but this should ensure junk with headers that indicate it's from a list member will not traverse the list. (For what it's worth, the list has gotten 13 copies of either the worm itself or bounces related to the worm over the last 24 hours, none of which had forged headers indicating a list member.) I expect to remove the moderated bit from the list this weekend, and will pass any legitimate mail on ASAP (but there could be a few hours delay). --Matt _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Wed Aug 20 02:57:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26659 for ; Wed, 20 Aug 2003 02:57:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pMtw-000542-J2 for ippm-archive@odin.ietf.org; Wed, 20 Aug 2003 02:57:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7K6v0Yf019460 for ippm-archive@odin.ietf.org; Wed, 20 Aug 2003 02:57:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pMtv-00053n-Dy for ippm-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 02:56:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26618 for ; Wed, 20 Aug 2003 02:56:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pMtr-0005GR-00 for ippm-web-archive@ietf.org; Wed, 20 Aug 2003 02:56:55 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pMtr-0005GN-00 for ippm-web-archive@ietf.org; Wed, 20 Aug 2003 02:56:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pMt0-0004ys-Lu; Wed, 20 Aug 2003 02:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pMpY-0004qh-Cu for ippm@optimus.ietf.org; Wed, 20 Aug 2003 02:52:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26513 for ; Wed, 20 Aug 2003 02:52:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pMpU-0005EO-00 for ippm@ietf.org; Wed, 20 Aug 2003 02:52:24 -0400 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 19pMpT-0005EH-00 for ippm@ietf.org; Wed, 20 Aug 2003 02:52:23 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id A8CFF7B4E8; Wed, 20 Aug 2003 02:52:24 -0400 (EDT) Received: from wlan238.internet2.edu (wlan238.internet2.edu [207.75.165.238]) by basie.internet2.edu (Postfix) with ESMTP id AED897B4D4; Wed, 20 Aug 2003 02:52:23 -0400 (EDT) Date: Wed, 20 Aug 2003 02:52:23 -0400 From: Matthew J Zekauskas To: ippm@ietf.org Cc: Matt Zekauskas , Allison Mankin Message-ID: <578962954.1061347943@localhost> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by AMaViS 0.3.12pre8 Content-Transfer-Encoding: 7bit Subject: [ippm] ippm list temporarily moderated Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit FYI, Because I've been receiving tons of Sobig.F worm spews via a mibs list, I'm putting the ippm list into moderated mode for a few days. I don't have any evidence that it has been used as a conduit, but this should ensure junk with headers that indicate it's from a list member will not traverse the list. (For what it's worth, the list has gotten 13 copies of either the worm itself or bounces related to the worm over the last 24 hours, none of which had forged headers indicating a list member.) I expect to remove the moderated bit from the list this weekend, and will pass any legitimate mail on ASAP (but there could be a few hours delay). --Matt _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Fri Aug 22 11:18:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02428 for ; Fri, 22 Aug 2003 11:18:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qDfs-0007zC-5s; Fri, 22 Aug 2003 11:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qDFM-0006gM-D2 for ippm@optimus.ietf.org; Fri, 22 Aug 2003 10:50:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00712 for ; Fri, 22 Aug 2003 10:50:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qDFJ-0005Q9-00 for ippm@ietf.org; Fri, 22 Aug 2003 10:50:33 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with esmtp (Exim 4.12) id 19qDFJ-0005Pw-00 for ippm@ietf.org; Fri, 22 Aug 2003 10:50:33 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 22 Aug 2003 16:49:56 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [ippm] Version 00 Minutes for the IPPM meeting in Vienna at IETF-57 Date: Fri, 22 Aug 2003 16:49:55 +0200 Message-ID: <3CA72DA73F5F02469A09AB598BFFAD382796C7@ftrdmel2.rd.francetelecom.fr> Thread-Topic: [ippm] Version 00 Minutes for the IPPM meeting in Vienna at IETF-57 Thread-Index: AcNlK1GuWkKlL7l6SFmUJEB8UpTDVgAns2Lw From: "STEPHAN Emile FTRD/DAC/LAN" To: "Matthew J Zekauskas" Cc: , "Merike Kaeo" X-OriginalArrivalTime: 22 Aug 2003 14:49:56.0266 (UTC) FILETIME=[A71298A0:01C368BC] Content-Transfer-Encoding: quoted-printable Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Dear Matt, many thanks for the link. Regarding the minutes, the need of metrics implementation report is missing. . Best Regards Emile > -----Message d'origine----- > De : Matthew J Zekauskas [mailto:matt@internet2.edu] > Envoye : lundi 18 aout 2003 03:50 > A : ippm@ietf.org > Cc : Matt Zekauskas; Merike Kaeo; jerry_mccollom@agilent.com > Objet : [ippm] Version 00 Minutes for the IPPM meeting in Vienna at > IETF-57 >=20 >=20 > Here is a draft copy. My apologies for taking so long... > I can say for one thing having a massive power failure right > around the last minute doesn't help :). >=20 > Let me or the list know if you have comments. They were probably > due Friday, although I haven't received any nagging reminders yet... >=20 > --Matt >=20 > p.s.: these, along with the presentations are available at > http://people.internet2.edu/~matt/IPPM/Meetings/ietf57/ , > at least until the official minutes come out. >=20 > ------------------------------------------------------- >=20 > IETF IP Performance Metrics WG (ippm) > Tuesday, July 15, 2003 at 09:00 to 11:30 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > The meeting was moderated by the working group chairs, Matt Zekauskas > and Merike Kaeo. Al Morton, and Henk Uijterwaal took notes, which > were edited into these minutes by the chairs. >=20 > AGENDA > 1. Agenda Bashing > 2. Packet Reordering > 3. Reordering Density > 4. IPPM-MIB & Registry > 5. Status, Milestones & Futures >=20 >=20 >=20 >=20 > 2. Packet Reordering > --Al Morton >=20 > Al Morton led off the meat of the meeting with a report on=20 > the reordering > metric progress. Many editorial changes were made from -02=20 > to -03 to clarify > text, and there are more in progress. A reordering-free-run metric > was added based on Jon Bennett's comments in the last meeting. This > metric characterizes how often reordering happens (along with=20 > previous gap > metric and general frequency metric). >=20 > Comment from Jon: want to answer the question how often do you get > packets out of order. This is important for some applications that > need in-order packets. Applications that run well when in-order > (or increasing order) want a feel for how much "order" there is. > Matt asked why is gap metric not good enough. Jon replied that it > doesn't show how often reordering happens. >=20 > Basically, the 'beginning of reordering event' is defined. You can't > know when the event ends, in order to keep the metric=20 > orthogonal to loss. > Call the places where a sequence number increases, but skips the > 'reordering discontinuity'. The Reordering Gap is the difference > between discontinuities. The reordering free run says how many > packets arrive in order. To some extent, the gap shows the > "early packets", while reordering free shows the "late packets". >=20 > Al mentioned two pending updates. First, separating=20 > reordering by packet > sequence numbers and other views (time, byte counts (TCP=20 > sequence numbers). > Second, clarify the base "nonreversing sequence" metric so=20 > that it reports > "true" for packets that are out of sequence by it's definition, false > otherwise (currently, it's not as clear and inverted). >=20 > One open issue that was mentioned: dealing with=20 > fragmentation. The current > draft says that you only consider reassembled IP datagrams (and that's > all it says). Jerry Perser (spirent) would like all=20 > reordering to be noted > -- reassembly could hide the case where a datagram was fragmented, the > fragments reordered, and then reassembled. Jerry will supply > some text for the next draft revision. >=20 >=20 >=20 >=20 > 3. Reordering Density > --Jerry McCollom >=20 > Next, Jerry McCollom from Agilent gave a presentation on reordering > density, a separate characterization metric developed at the=20 > University > of Colorado at Fort Collins. The authors were not present, but Jerry > has been working with them, and presented slides they produced (see > slides). The metric has a model of a buffer, and looks at > how many packets are stored in the buffer to compute the metric. > If the buffer overflows, those packets are considered lost. If > the duplicates arrive, they are ignored. The audience (and mailing > list members) have questioned this mixing of loss and reordering -- > there will be a new draft after the meeting that should address > (some of?) the concerns. >=20 > This led to a good general reordering discussion, including adding > usage notes to each metric (where it works well, when it fails) and > having each metric indicate when it is out-of-scope (if such a > condition exists). >=20 > Greg Ryan made a number of points, including that it is "squishy" > as to what exactly is measured; the drafts should explain what the > metric measures compared to a complete characterization of reordering > (perhaps edit distance), and give some examples. It is very important > to specify when the "domain of validity" is exceeded... for example, > the underlying assumption with both drafts is that reordering does > not happen very often (otherwise "frequency of reordering"=20 > and "reordering > free gaps" don't make much sense). What happens if the data is > "completely messed up" -- say the packets arrive in truly=20 > random order. > Greg is interested in providing some text to Al about edit distance. > He will comment to the list. >=20 > Jon Bennett probed how reordering density interacts with packet loss. > Jerry said that the metric is density not loss. The metric assumes > a threshold (the buffer size) where packet is lost and leaves=20 > it at that. > The authors believe that a characterization of loss needs to be added; > how often are packets lost? >=20 > Jon asked what happens if the threshold is wrong? It depends on > the application data stream in the end. So Jon wondered if the > metric tried to represent a prototypical application... and then > time might become more relevant than distance, especially for > real time applications. Jerry said that without much thought=20 > it seems that it's possible to > compute a sensible threshold that would cover a large number of > applications. Jon noted that the metric keeps state - the=20 > packets in he buffer. > Thus it seems like there might be a number of metrics for different > applications. Either a metric tells me something intuitively or it's > specific to an application. It seems like this metric is too > complicated to be intuitive, but not complicated enough to match > an application. >=20 > Jon also noted that with "tool devices", having to keep state > (particularly on a high-speed test) is impossible, or places a high > load on the device. You have to accept that there may be some > deficiency... but being loss impervious might be more practical than > trying to emulate an application. >=20 > Al thanked Jerry for coming to represent the metric. > It's difficult to maintain orthogonality between loss and reordering, > but that's what the current reordering draft tries to do. In the -00 > draft of reordering density, there is an example where the metric > counts "early packets" out of order. The current draft calls "late > packets" out of order, for one thing to distinguish loss (only way > to distinguish is to have the late packet arrive). >=20 > Jerry M. mentioned that in the second examples... some of packets in > buffer reordered, doesn't catch. Before releasing the packets, one > could take a look at what have in buffer to accurately reflect metric. >=20 > Al thought that sounded reasonable... he noted that one of=20 > the problems > in the industry right now is that multiple vendors look at the same > same stream would call different packets out of order; we need one > definition that everyone agrees to. >=20 > Jerry Purser wanted to pursue how easily such a metric could be > interpreted, say by a technical support person. Look at the first > graph on slide 9. What does it tell you? It looks like two packets > got pushed out. Al noted that two packets out of order, but the > chart has three bars. Jerry M. noted that the 0 slot represents > in-order packets. >=20 > Jerry P. was trying to understand normalization... How many times > was packet 3 displaced? That's not what we're measuring. > Merike noted it was how many times packet was in a particular buffer > slot. >=20 > Jerry M said that if packet 3 is what caused us to start buffering > in the first place... one tweak could be to see 3 and=20 > release, displacement > of 3 for packet. >=20 > Jerry P was trying to think as support person on line. Get=20 > that chart, > can you figured out what happened from that chart? > 55% of time everyting is in order > 45% of packets experienced some reordering > Jerry P was wondering if it was reordering or buffering. >=20 >=20 >=20 >=20 > 4. IPPM-MIB & Registry > --Emile Stephan >=20 > Next was Emile Stephan to report on Reporting MIB progress. =20 > Major changes > include VACM support for security instead of roll-your-own,=20 > and tweaking > all the tables so that VACM access made sense (mainly=20 > replacing pointers > with data in some cases). Emile also added 'burst' and 'multiburst' > packet types -- MattZ asked where this came from, and didn't get > a clear answer. He will take it to the mailing list. >=20 > No comments from floor, other than Andy Bierman who noted there were > still a number of problems (probably due to the major reorganization > to satisfy VACM). The chairs asked had anyone read draft. =20 > No responses > other than Andy in this audience. The chairs then followed=20 > up with who > would use it. No responses in this audience. This is=20 > different from the > response in earlier meetings, where there was general interest. >=20 >=20 >=20 >=20 > 5. Status, Milestones & Futures > --Matt Zekauskas >=20 > Finally, Matt once again went over the milestones. The OWAMP=20 > requirements > document was cycling between the author and the IESG for clarification > of the security section. OWAMP itself was being updated based on > a sample implementation. More information on the implementation is > available at http://owamp.internet2.edu/ . The MIB work has been > progressing. >=20 > Matt noted areas where there was interest, but it had waned. (In > particular: Cap, a BTC implementation; parameter sensitivity; ITU vs > IPPM metrics; path bottleneck definitions; and the applicability > statement.) On the applicability statement: Merike and Henk > Uijterwaal have repeatedy prodded vendors, and they indicate interest > and promise text, but the text never materializes. They want to > shelve it as an ippm item for now. Perhaps interest might be > generated in doing it in 'ispmon', should it become a WG from a BOF? > MattZ noted that a probe will be sent to the list, and if no interest > is generated, the chairs would drop the items from the charter > milestones. >=20 > Al noted that the advancing metrics draft was really needed. He > wanted to know if the -00 draft was still available even though > it had expired? Matt said that he had one, and that it was also > available from some of the unofficial internet-drafts archives. >=20 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/ippm >=20 _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Fri Aug 22 11:18:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02445 for ; Fri, 22 Aug 2003 11:18:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qDg5-00084D-QL for ippm-archive@odin.ietf.org; Fri, 22 Aug 2003 11:18:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7MFIDoo031003 for ippm-archive@odin.ietf.org; Fri, 22 Aug 2003 11:18:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qDg5-00083y-Hx for ippm-web-archive@optimus.ietf.org; Fri, 22 Aug 2003 11:18:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02421 for ; Fri, 22 Aug 2003 11:18:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qDg4-0005qD-00 for ippm-web-archive@ietf.org; Fri, 22 Aug 2003 11:18:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19qDg4-0005q9-00 for ippm-web-archive@ietf.org; Fri, 22 Aug 2003 11:18:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qDfs-0007zC-5s; Fri, 22 Aug 2003 11:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qDFM-0006gM-D2 for ippm@optimus.ietf.org; Fri, 22 Aug 2003 10:50:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00712 for ; Fri, 22 Aug 2003 10:50:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qDFJ-0005Q9-00 for ippm@ietf.org; Fri, 22 Aug 2003 10:50:33 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with esmtp (Exim 4.12) id 19qDFJ-0005Pw-00 for ippm@ietf.org; Fri, 22 Aug 2003 10:50:33 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 22 Aug 2003 16:49:56 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [ippm] Version 00 Minutes for the IPPM meeting in Vienna at IETF-57 Date: Fri, 22 Aug 2003 16:49:55 +0200 Message-ID: <3CA72DA73F5F02469A09AB598BFFAD382796C7@ftrdmel2.rd.francetelecom.fr> Thread-Topic: [ippm] Version 00 Minutes for the IPPM meeting in Vienna at IETF-57 Thread-Index: AcNlK1GuWkKlL7l6SFmUJEB8UpTDVgAns2Lw From: "STEPHAN Emile FTRD/DAC/LAN" To: "Matthew J Zekauskas" Cc: , "Merike Kaeo" X-OriginalArrivalTime: 22 Aug 2003 14:49:56.0266 (UTC) FILETIME=[A71298A0:01C368BC] Content-Transfer-Encoding: quoted-printable Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Dear Matt, many thanks for the link. Regarding the minutes, the need of metrics implementation report is missing. . Best Regards Emile > -----Message d'origine----- > De : Matthew J Zekauskas [mailto:matt@internet2.edu] > Envoye : lundi 18 aout 2003 03:50 > A : ippm@ietf.org > Cc : Matt Zekauskas; Merike Kaeo; jerry_mccollom@agilent.com > Objet : [ippm] Version 00 Minutes for the IPPM meeting in Vienna at > IETF-57 >=20 >=20 > Here is a draft copy. My apologies for taking so long... > I can say for one thing having a massive power failure right > around the last minute doesn't help :). >=20 > Let me or the list know if you have comments. They were probably > due Friday, although I haven't received any nagging reminders yet... >=20 > --Matt >=20 > p.s.: these, along with the presentations are available at > http://people.internet2.edu/~matt/IPPM/Meetings/ietf57/ , > at least until the official minutes come out. >=20 > ------------------------------------------------------- >=20 > IETF IP Performance Metrics WG (ippm) > Tuesday, July 15, 2003 at 09:00 to 11:30 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > The meeting was moderated by the working group chairs, Matt Zekauskas > and Merike Kaeo. Al Morton, and Henk Uijterwaal took notes, which > were edited into these minutes by the chairs. >=20 > AGENDA > 1. Agenda Bashing > 2. Packet Reordering > 3. Reordering Density > 4. IPPM-MIB & Registry > 5. Status, Milestones & Futures >=20 >=20 >=20 >=20 > 2. Packet Reordering > --Al Morton >=20 > Al Morton led off the meat of the meeting with a report on=20 > the reordering > metric progress. Many editorial changes were made from -02=20 > to -03 to clarify > text, and there are more in progress. A reordering-free-run metric > was added based on Jon Bennett's comments in the last meeting. This > metric characterizes how often reordering happens (along with=20 > previous gap > metric and general frequency metric). >=20 > Comment from Jon: want to answer the question how often do you get > packets out of order. This is important for some applications that > need in-order packets. Applications that run well when in-order > (or increasing order) want a feel for how much "order" there is. > Matt asked why is gap metric not good enough. Jon replied that it > doesn't show how often reordering happens. >=20 > Basically, the 'beginning of reordering event' is defined. You can't > know when the event ends, in order to keep the metric=20 > orthogonal to loss. > Call the places where a sequence number increases, but skips the > 'reordering discontinuity'. The Reordering Gap is the difference > between discontinuities. The reordering free run says how many > packets arrive in order. To some extent, the gap shows the > "early packets", while reordering free shows the "late packets". >=20 > Al mentioned two pending updates. First, separating=20 > reordering by packet > sequence numbers and other views (time, byte counts (TCP=20 > sequence numbers). > Second, clarify the base "nonreversing sequence" metric so=20 > that it reports > "true" for packets that are out of sequence by it's definition, false > otherwise (currently, it's not as clear and inverted). >=20 > One open issue that was mentioned: dealing with=20 > fragmentation. The current > draft says that you only consider reassembled IP datagrams (and that's > all it says). Jerry Perser (spirent) would like all=20 > reordering to be noted > -- reassembly could hide the case where a datagram was fragmented, the > fragments reordered, and then reassembled. Jerry will supply > some text for the next draft revision. >=20 >=20 >=20 >=20 > 3. Reordering Density > --Jerry McCollom >=20 > Next, Jerry McCollom from Agilent gave a presentation on reordering > density, a separate characterization metric developed at the=20 > University > of Colorado at Fort Collins. The authors were not present, but Jerry > has been working with them, and presented slides they produced (see > slides). The metric has a model of a buffer, and looks at > how many packets are stored in the buffer to compute the metric. > If the buffer overflows, those packets are considered lost. If > the duplicates arrive, they are ignored. The audience (and mailing > list members) have questioned this mixing of loss and reordering -- > there will be a new draft after the meeting that should address > (some of?) the concerns. >=20 > This led to a good general reordering discussion, including adding > usage notes to each metric (where it works well, when it fails) and > having each metric indicate when it is out-of-scope (if such a > condition exists). >=20 > Greg Ryan made a number of points, including that it is "squishy" > as to what exactly is measured; the drafts should explain what the > metric measures compared to a complete characterization of reordering > (perhaps edit distance), and give some examples. It is very important > to specify when the "domain of validity" is exceeded... for example, > the underlying assumption with both drafts is that reordering does > not happen very often (otherwise "frequency of reordering"=20 > and "reordering > free gaps" don't make much sense). What happens if the data is > "completely messed up" -- say the packets arrive in truly=20 > random order. > Greg is interested in providing some text to Al about edit distance. > He will comment to the list. >=20 > Jon Bennett probed how reordering density interacts with packet loss. > Jerry said that the metric is density not loss. The metric assumes > a threshold (the buffer size) where packet is lost and leaves=20 > it at that. > The authors believe that a characterization of loss needs to be added; > how often are packets lost? >=20 > Jon asked what happens if the threshold is wrong? It depends on > the application data stream in the end. So Jon wondered if the > metric tried to represent a prototypical application... and then > time might become more relevant than distance, especially for > real time applications. Jerry said that without much thought=20 > it seems that it's possible to > compute a sensible threshold that would cover a large number of > applications. Jon noted that the metric keeps state - the=20 > packets in he buffer. > Thus it seems like there might be a number of metrics for different > applications. Either a metric tells me something intuitively or it's > specific to an application. It seems like this metric is too > complicated to be intuitive, but not complicated enough to match > an application. >=20 > Jon also noted that with "tool devices", having to keep state > (particularly on a high-speed test) is impossible, or places a high > load on the device. You have to accept that there may be some > deficiency... but being loss impervious might be more practical than > trying to emulate an application. >=20 > Al thanked Jerry for coming to represent the metric. > It's difficult to maintain orthogonality between loss and reordering, > but that's what the current reordering draft tries to do. In the -00 > draft of reordering density, there is an example where the metric > counts "early packets" out of order. The current draft calls "late > packets" out of order, for one thing to distinguish loss (only way > to distinguish is to have the late packet arrive). >=20 > Jerry M. mentioned that in the second examples... some of packets in > buffer reordered, doesn't catch. Before releasing the packets, one > could take a look at what have in buffer to accurately reflect metric. >=20 > Al thought that sounded reasonable... he noted that one of=20 > the problems > in the industry right now is that multiple vendors look at the same > same stream would call different packets out of order; we need one > definition that everyone agrees to. >=20 > Jerry Purser wanted to pursue how easily such a metric could be > interpreted, say by a technical support person. Look at the first > graph on slide 9. What does it tell you? It looks like two packets > got pushed out. Al noted that two packets out of order, but the > chart has three bars. Jerry M. noted that the 0 slot represents > in-order packets. >=20 > Jerry P. was trying to understand normalization... How many times > was packet 3 displaced? That's not what we're measuring. > Merike noted it was how many times packet was in a particular buffer > slot. >=20 > Jerry M said that if packet 3 is what caused us to start buffering > in the first place... one tweak could be to see 3 and=20 > release, displacement > of 3 for packet. >=20 > Jerry P was trying to think as support person on line. Get=20 > that chart, > can you figured out what happened from that chart? > 55% of time everyting is in order > 45% of packets experienced some reordering > Jerry P was wondering if it was reordering or buffering. >=20 >=20 >=20 >=20 > 4. IPPM-MIB & Registry > --Emile Stephan >=20 > Next was Emile Stephan to report on Reporting MIB progress. =20 > Major changes > include VACM support for security instead of roll-your-own,=20 > and tweaking > all the tables so that VACM access made sense (mainly=20 > replacing pointers > with data in some cases). Emile also added 'burst' and 'multiburst' > packet types -- MattZ asked where this came from, and didn't get > a clear answer. He will take it to the mailing list. >=20 > No comments from floor, other than Andy Bierman who noted there were > still a number of problems (probably due to the major reorganization > to satisfy VACM). The chairs asked had anyone read draft. =20 > No responses > other than Andy in this audience. The chairs then followed=20 > up with who > would use it. No responses in this audience. This is=20 > different from the > response in earlier meetings, where there was general interest. >=20 >=20 >=20 >=20 > 5. Status, Milestones & Futures > --Matt Zekauskas >=20 > Finally, Matt once again went over the milestones. The OWAMP=20 > requirements > document was cycling between the author and the IESG for clarification > of the security section. OWAMP itself was being updated based on > a sample implementation. More information on the implementation is > available at http://owamp.internet2.edu/ . The MIB work has been > progressing. >=20 > Matt noted areas where there was interest, but it had waned. (In > particular: Cap, a BTC implementation; parameter sensitivity; ITU vs > IPPM metrics; path bottleneck definitions; and the applicability > statement.) On the applicability statement: Merike and Henk > Uijterwaal have repeatedy prodded vendors, and they indicate interest > and promise text, but the text never materializes. They want to > shelve it as an ippm item for now. Perhaps interest might be > generated in doing it in 'ispmon', should it become a WG from a BOF? > MattZ noted that a probe will be sent to the list, and if no interest > is generated, the chairs would drop the items from the charter > milestones. >=20 > Al noted that the advancing metrics draft was really needed. He > wanted to know if the -00 draft was still available even though > it had expired? Matt said that he had one, and that it was also > available from some of the unofficial internet-drafts archives. >=20 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/ippm >=20 _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm