From mailman-bounces@ietf.org Wed Sep 1 10:38:45 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19575 for ; Wed, 1 Sep 2004 10:38:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Re6-0001OT-EG for ippm-archive@lists.ietf.org; Wed, 01 Sep 2004 05:43:14 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: ippm-archive@ietf.org X-No-Archive: yes Message-ID: Date: Wed, 01 Sep 2004 05:12:33 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org Content-Transfer-Encoding: 7bit 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, mailman-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: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@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 ippm-bounces@ietf.org Wed Sep 1 20:12:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18796 for ; Wed, 1 Sep 2004 20:12:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2eoa-00048h-7j; Wed, 01 Sep 2004 19:46:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2ehJ-0005u8-29 for ippm@megatron.ietf.org; Wed, 01 Sep 2004 19:39:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17036 for ; Wed, 1 Sep 2004 19:39:21 -0400 (EDT) Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2eja-0005ek-BL for ippm@ietf.org; Wed, 01 Sep 2004 19:41:46 -0400 Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 4DFB21CD673; Wed, 1 Sep 2004 19:39:23 -0400 (EDT) Received: from basie.internet2.edu ([127.0.0.1]) by localhost (basie.internet2.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25211-04; Wed, 1 Sep 2004 19:39:23 -0400 (EDT) Received: from BMW (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 3A0E91CD669; Wed, 1 Sep 2004 19:39:22 -0400 (EDT) Date: Wed, 01 Sep 2004 19:39:21 -0400 From: Matthew J Zekauskas To: ippm@ietf.org Message-ID: X-Mailer: Mulberry/3.1.3 (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 mail.internet2.edu virus scanner X-Spam-Score: 0.0 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Content-Transfer-Encoding: 7bit Cc: Henk Uijterwaal , Matt Zekauskas Subject: [ippm] IPPM Minutes for IETF 60, version 0 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: 7bit Here is a complete cut at the minutes. If anyone has a comment, get it to me or the list before 3pm or so EDT on Friday (they are due by 5pm EDT). The presentations are all linked off of http://people.internet2.edu/~matt/IPPM/Meetings/ietf60/ --Matt -=- IP Performance Metrics WG (ippm) Monday, August 2, 2004 at 1300-1500 =================================== The meeting was moderated by the working group chairs, Henk Uijterwaal and Matt Zekauskas. Al Morton and Matt Zekauskas took notes, which were edited into these minutes by the chairs. Simon Leinen scribed to Jabber. AGENDA: 1. Administrivia, Milestone Status 2. One-Way Active Measurements Protocol 3. A Hardware Timestamper for One-way Delay Measurements 4. Reordering Density (RD) and Reorder Buffer-occupancy Density (RBD): Metrics for packet reordering 5. Packet Reordering Metric for IPPM 6. Implementation reports for RFC2678-2681: RIPE NCC Test Traffic Measurements (TTM) 7. Implementation report: Surveyor 8. IPPM Reporting MIB and Metrics Registry discussion 1. Administrivia, Milestone Status We are looking for a volunteer to act as editor on link bandwidth draft, there is some existing material to base it on. [Note: after the meeting, Phil Chimento volunteered to edit.] Reviewing the rest of the milestones, OWAMP appears to be on track, reordering schedule will depend on today's discussion. 2. One-Way Active Measurements Protocol http://www.ietf.org/internet-drafts/draft-ietf-ippm-owdp-09.txt - Stanislav Shalunov There were two wire protocol changes and a bunch of clarifications since the last version (see slides). Changes were made in response to the approved requirements draft, two wire protocol changes (to expose TTL, and a minor change in reporting lost packets, both in response to implementation experience). Stanislav reported that there were pending changes to remove a feature that caused some ambiguity (essentially "start in the past"), and a reordering of values in one message to make it more likely that the timestamp falls on a nice word boundary. Stanislav mentioned that the protocol really needed a thorough security review. TTL is intended to count hops, was not specified before, now receiver must report actual received value (sender uses 255). Matt asked why 255? Why not negotiated? Stanislav said that it made sense to have it large and equal. Timmons Player asked what if an implementation cannot set the value? Stanislav said that then you get back what you get back ("junk"); it should be possible to report if you know what it is set to (so you can understand in context). Al Morton asked a question on send scheduling for test packets. He was wondering if there was a way to have a random start time, then a periodic schedule after that. It seems that the current scheme would try to do random, periodic, and then back to random again. Stas believed it could be done with the current scheme; Stas and Al will work on this afterwards. 3. A Hardware Timestamper for One-way Delay Measurements - Zhang Shu Zhang Shu reported on a hardware implementation of OWAMP, in particular, timestamping the packets in hardware, to get rid of inaccuracies due to software overhead and timing within the measurement node. The limitations are that it supports unauthenticated mode only, one measurement stream only, and on INPUT the UDP checksum is zeroed (when the input timestamp is added). They showed the results of measurements in Japan using IPv4 and IPv6. They claim high precision (see slides). Stanislav thought this was splendid. He noted that they apparently did not make use of OWAMP-CTL anywhere. That is true. So, they should make it clear that they use the test versus the full OWAMP protocol. Matt asked about support of more than one port number or stream? not yet. Matt also asked if before the UDP checksum was cleared, was it checked? Right now, it is cleared. Zhang felt that in the current internet there isn't much chance for this to happen. Emile Stephan asked how the test endpoints were set up without OWAMP-control. Zhang responded that setup was performed manually. 4. Reordering Density (RD) and Reorder Buffer-occupancy Density (RBD): Metrics for packet reordering http://www.ietf.org/internet-drafts/draft-jayasumana-reorder-density-03.txt - Anura Jayasumana Anura Jayasumana presented an update on his team's work on "reorder density" (see slides). He presented a new version of reorder density that he says is orthogonal to loss and duplication, but it still doesn't use the same base definitions as in the current IPPM reordering draft. He says that this provides a "reorder response" similar to "impulse response" in engineering control theory, which has a formal proof in a recent paper; they are looking to use this as a base for a version of TCP that sets "dupthresh" automatically. He also said the results on individual segments are composable. He may be interested in submitting this as an additional work item, or move it forward personally if the group is not interested. Mark Allman asked what do the numbers output by these metrics say? He didn't think the interpretation was obvious; how do you get insight into how the network is working from the numbers? Anura responded that it gives insight into the nature of the reordering; they give a distribution. Al Morton thought the real value was the ability to measure segments and combine. This is a desirable quality in current IPPM reordering draft. However, intuitively he doesn't believe that these distributions are independent of packet spacing. Al would like to harmonize basic definition of reordering (so same as what current draft is, and what others use). Anura said that to understand the independence of spacing, look at system theory. You are not predicting the effect on any given packet, but statistical nature. With respect to the current ippm draft, The current definitions only work with "early" or "late" packets, don't combine the two. You need this combination in order to get the insight. 5. Packet Reordering Metric for IPPM http://www.ietf.org/internet-drafts/draft-ietf-ippm-reordering-06.txt - Al Morton Al Morton presented the current state of the IPPM reordering draft. The fragmentation additions were complex enough to be confusing in the mainline text, so the discussion has been moved to the appendix. There were many clarification changes based on comments on the list and at meetings. Two groups have implemented the metric (and there was some discussion on the list). 6. Implementation reports for RFC2678-2681: RIPE NCC Test Traffic Measurements (TTM) Henk presented an template for producing an implementation report, including what was asked for at the last IETF meeting and on the mailing list. The purpose of these presentations are to provide complete examples, and encourage other implementers to contribute. For 2679, all metrics were implemented except Type-P-One-way-Delay-Inverse-Percentile. For 2680, all were implemented. 2678 (connectivity) and 2681 (round trip delay) were not implemented by this system. Specific percentiles and averaging intervals used were given. 7. Implementation report: Surveyor Matt Zekauskas made a similar report for Surveyor. For 2679, all were implemented except the inverse percentile metric (although histograms of delays were computed). Matt gave more details on the "Type-P" used, as well as transmission rates. He also gave percentiles and averaging intervals used. As with the RIPE system Surveyor implemented all of the 2680 metrics, and non of 2678 or 2681. 8. IPPM Reporting MIB and Metrics Registry discussion http://www.ietf.org/internet-drafts/draft-ietf-ippm-reporting-mib-06.txt http://www.ietf.org/internet-drafts/draft-ietf-ippm-metrics-registry-07.txt - Emile Stephan Emile noted that there was a move to stop work on the MIB as a working group item. He also noted that in other groups he observed that there wasn't much discussion on the respective groups. He then noted what made the IPPM MIB different from some others, and presented a list of questions the group. He also briefly updated the latest changes. Matt presented the chairs position that there appears to be no consensus to continue with the current document, and that the plan will be to once again query the mailing list looking for interest in either this MIB, or the simpler MIB; if none then we would drop this item from the charter (and Emile would be free to request publication as an Informational RFC). Andy Bierman noted that perhaps because the group was interested in measurement, not management (defining metrics, not MIBs) there was little interest in the MIB. Andy said that it is a very complicated MIB, and it needs better use cases. The packet generation is not typical. The idea of fast report is not typical. There is some overlap with TPM MIB, for some of the metrics. Also, once you get into views, filtering, aggregation, something like TPM already does it. He's of the opinion that we should not proceed with the MIB. Phil Chimento asked if it made sense to have a general MIB at all, or is it better to have reporting in the context of an application? Andy agreed to the need to provide results in the context of an application. There was some short discussion of the pros and cons of a simple ring-buffer based MIB, and whether the update rates would just overwhelm a simple implementation. Was there a use case for a simple MIB? Finally, Matt presented the remaining open issue with the MIB registry, whether to include branches for enterprises and "other standards bodies". Andy was of the opinion that a centralized place to look for the values is enough. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu Sep 2 12:59:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18437 for ; Thu, 2 Sep 2004 12:59:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2ur7-00038h-LV; Thu, 02 Sep 2004 12:54:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2sq1-0002hH-3p for ippm@megatron.ietf.org; Thu, 02 Sep 2004 10:45:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08811 for ; Thu, 2 Sep 2004 10:45:19 -0400 (EDT) Received: from post.tau.ac.il ([132.66.16.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2ssP-0001VJ-Us for ippm@ietf.org; Thu, 02 Sep 2004 10:47:50 -0400 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by post.tau.ac.il (Postfix) with ESMTP id 1A3BB47E83 for ; Thu, 2 Sep 2004 17:44:47 +0300 (IDT) Received: from post.tau.ac.il (localhost.localdomain [127.0.0.1]) by localhost.localdomain (VaMailArmor-2.0.2-6) id 02849-04CB69E9; Thu, 02 Sep 2004 17:44:46 +0300 Received: from eng.tau.ac.il (amirotem-pc.eng.tau.ac.il [132.66.196.214]) by post.tau.ac.il (Postfix) with ESMTP id 9A8C647E83 for ; Thu, 2 Sep 2004 17:44:46 +0300 (IDT) Message-ID: <41373F92.1060103@eng.tau.ac.il> Date: Thu, 02 Sep 2004 17:43:14 +0200 From: Yuval Shavitt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ippm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.2-6; VAE: 6.27.0.6; VDF: 6.27.0.44; host: localhost) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 02 Sep 2004 12:54:36 -0400 Subject: [ippm] Internet Mapping and Measurement X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: 7bit (We apologize if you receive multiple copies of this e-mail.) Dear Colleagues, DIMES is a new project that aims at accurately mapping the Internet topology using a distributed agent system. The project success depends on the willingness of users around the world to download and activate our agents. The agents will perform network measurements (basically traceroute and ping) at very low rates that will not affect the hosting machines. We currently support MS Windows, and plan a Linux porting soon. To download the agent please point to http://www.netdimes.org We are very enthusiastic about DIMES and hope for your collaboration. Please feel free to forward the above DIMES link to anyone who might be interested in the project. Best regards, Yuval Shavitt -- Yuval Shavitt School of Electrical Engineering Tel Aviv University, Tel Aviv 69978, Israel Tel: +972 3 640 8659 Fax: +972 3 640 5027 URL: http://www.eng.tau.ac.il/~shavitt _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Fri Sep 3 12:34:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09502 for ; Fri, 3 Sep 2004 12:34:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3Gpw-00008Z-NN; Fri, 03 Sep 2004 12:22:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3Gi7-0005jK-WD for ippm@megatron.ietf.org; Fri, 03 Sep 2004 12:14:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08511; Fri, 3 Sep 2004 12:14:45 -0400 (EDT) Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C3Gkl-0003Bs-69; Fri, 03 Sep 2004 12:17:31 -0400 Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id D149C1CD734; Fri, 3 Sep 2004 12:14:45 -0400 (EDT) Received: from basie.internet2.edu ([127.0.0.1]) by localhost (basie.internet2.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22674-09; Fri, 3 Sep 2004 12:14:45 -0400 (EDT) Received: from BMW (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 9B1371CD730; Fri, 3 Sep 2004 12:14:44 -0400 (EDT) Date: Fri, 03 Sep 2004 12:14:43 -0400 From: Matthew J Zekauskas To: proceedings@ietf.org Message-ID: X-Mailer: Mulberry/3.1.3 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========AFA06220432B73BC891C==========" X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Score: 0.0 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Cc: Henk Uijterwaal , Matt Zekauskas , ippm@ietf.org Subject: [ippm] Minutes for IPPM at IETF60 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org --==========AFA06220432B73BC891C========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 7bit Enclosed. In addition, these minutes and the proceedings are available off of http://people.internet2.edu/~matt/IPPM/Meetings/ietf60/ --Matt --==========AFA06220432B73BC891C========== Content-Type: text/plain; charset=us-ascii; name="ippm-minutes-01.txt" Content-Disposition: attachment; filename="ippm-minutes-01.txt"; size=9902 Content-Transfer-Encoding: 7bit IP Performance Metrics WG (ippm) Monday, August 2, 2004 at 1300-1500 =================================== The meeting was moderated by the working group chairs, Henk Uijterwaal and Matt Zekauskas. Al Morton and Matt Zekauskas took notes, which were edited into these minutes by the chairs. Simon Leinen scribed to Jabber. AGENDA: 1. Administrivia, Milestone Status 2. One-Way Active Measurements Protocol 3. A Hardware Timestamper for One-way Delay Measurements 4. Reordering Density (RD) and Reorder Buffer-occupancy Density (RBD): Metrics for packet reordering 5. Packet Reordering Metric for IPPM 6. Implementation reports for RFC2678-2681: RIPE NCC Test Traffic Measurements (TTM) 7. Implementation report: Surveyor 8. IPPM Reporting MIB and Metrics Registry discussion 1. Administrivia, Milestone Status We are looking for a volunteer to act as editor on link bandwidth draft, there is some existing material to base it on. [Note: after the meeting, Phil Chimento volunteered to edit.] Reviewing the rest of the milestones, OWAMP appears to be on track, reordering schedule will depend on today's discussion. 2. One-Way Active Measurements Protocol http://www.ietf.org/internet-drafts/draft-ietf-ippm-owdp-09.txt - Stanislav Shalunov There were two wire protocol changes and a bunch of clarifications since the last version (see slides). Changes were made in response to the approved requirements draft, two wire protocol changes (to expose TTL, and a minor change in reporting lost packets, both in response to implementation experience). Stanislav reported that there were pending changes to remove a feature that caused some ambiguity (essentially "start in the past"), and a reordering of values in one message to make it more likely that the timestamp falls on a nice word boundary. Stanislav mentioned that the protocol really needed a thorough security review. TTL is intended to count hops, was not specified before, now receiver must report actual received value (sender uses 255). Matt asked why 255? Why not negotiated? Stanislav said that it made sense to have it large and equal. Timmons Player asked what if an implementation cannot set the value? Stanislav said that then you get back what you get back ("junk"); it should be possible to report if you know what it is set to (so you can understand in context). Al Morton asked a question on send scheduling for test packets. He was wondering if there was a way to have a random start time, then a periodic schedule after that. It seems that the current scheme would try to do random, periodic, and then back to random again. Stas believed it could be done with the current scheme; Stas and Al will work on this afterwards. 3. A Hardware Timestamper for One-way Delay Measurements - Zhang Shu Zhang Shu reported on a hardware implementation of OWAMP, in particular, timestamping the packets in hardware, to get rid of inaccuracies due to software overhead and timing within the measurement node. The limitations are that it supports unauthenticated mode only, one measurement stream only, and on INPUT the UDP checksum is zeroed (when the input timestamp is added). They showed the results of measurements in Japan using IPv4 and IPv6. They claim high precision (see slides). Stanislav thought this was splendid. He noted that they apparently did not make use of OWAMP-CTL anywhere. That is true. So, they should make it clear that they use the test versus the full OWAMP protocol. Matt asked about support of more than one port number or stream? not yet. Matt also asked if before the UDP checksum was cleared, was it checked? Right now, it is cleared. Zhang felt that in the current internet there isn't much chance for this to happen. Emile Stephan asked how the test endpoints were set up without OWAMP-control. Zhang responded that setup was performed manually. 4. Reordering Density (RD) and Reorder Buffer-occupancy Density (RBD): Metrics for packet reordering http://www.ietf.org/internet-drafts/draft-jayasumana-reorder-density-03.txt - Anura Jayasumana Anura Jayasumana presented an update on his team's work on "reorder density" (see slides). He presented a new version of reorder density that he says is orthogonal to loss and duplication, but it still doesn't use the same base definitions as in the current IPPM reordering draft. He says that this provides a "reorder response" similar to "impulse response" in engineering control theory, which has a formal proof in a recent paper; they are looking to use this as a base for a version of TCP that sets "dupthresh" automatically. He also said the results on individual segments are composable. He may be interested in submitting this as an additional work item, or move it forward personally if the group is not interested. Mark Allman asked what do the numbers output by these metrics say? He didn't think the interpretation was obvious; how do you get insight into how the network is working from the numbers? Anura responded that it gives insight into the nature of the reordering; they give a distribution. Al Morton thought the real value was the ability to measure segments and combine. This is a desirable quality in current IPPM reordering draft. However, intuitively he doesn't believe that these distributions are independent of packet spacing. Al would like to harmonize basic definition of reordering (so same as what current draft is, and what others use). Anura said that to understand the independence of spacing, look at system theory. You are not predicting the effect on any given packet, but statistical nature. With respect to the current ippm draft, The current definitions only work with "early" or "late" packets, don't combine the two. You need this combination in order to get the insight. 5. Packet Reordering Metric for IPPM http://www.ietf.org/internet-drafts/draft-ietf-ippm-reordering-06.txt - Al Morton Al Morton presented the current state of the IPPM reordering draft. The fragmentation additions were complex enough to be confusing in the mainline text, so the discussion has been moved to the appendix. There were many clarification changes based on comments on the list, off the list, and at meetings (see slides). Two new and independent groups have implemented the metric (and there was some discussion on the list). Al asked the meeting if there were further comments, and there were none. 6. Implementation reports for RFC2678-2681: RIPE NCC Test Traffic Measurements (TTM) Henk presented an template for producing an implementation report, including what was asked for at the last IETF meeting and on the mailing list. The purpose of these presentations are to provide complete examples, and encourage other implementers to contribute. For 2679, all metrics were implemented except Type-P-One-way-Delay-Inverse-Percentile. For 2680, all were implemented. 2678 (connectivity) and 2681 (round trip delay) were not implemented by this system. Specific percentiles and averaging intervals used were given. 7. Implementation report: Surveyor Matt Zekauskas made a similar report for Surveyor. For 2679, all were implemented except the inverse percentile metric (although histograms of delays were computed). Matt gave more details on the "Type-P" used, as well as transmission rates. He also gave percentiles and averaging intervals used. As with the RIPE system Surveyor implemented all of the 2680 metrics, and non of 2678 or 2681. 8. IPPM Reporting MIB and Metrics Registry discussion http://www.ietf.org/internet-drafts/draft-ietf-ippm-reporting-mib-06.txt http://www.ietf.org/internet-drafts/draft-ietf-ippm-metrics-registry-07.txt - Emile Stephan Emile noted that there was a move to stop work on the MIB as a working group item. He also noted that in other groups he observed that there wasn't much discussion on the respective groups. He then noted what made the IPPM MIB different from some others, and presented a list of questions the group. He also briefly updated the latest changes. Matt presented the chairs position that there appears to be no consensus to continue with the current document, and that the plan will be to once again query the mailing list looking for interest in either this MIB, or the simpler MIB; if none then we would drop this item from the charter (and Emile would be free to request publication as an Informational RFC). Andy Bierman noted that perhaps because the group was interested in measurement, not management (defining metrics, not MIBs) there was little interest in the MIB. Andy said that it is a very complicated MIB, and it needs better use cases. The packet generation is not typical. The idea of fast report is not typical. There is some overlap with TPM MIB, for some of the metrics. Also, once you get into views, filtering, aggregation, something like TPM already does it. He's of the opinion that we should not proceed with the MIB. Phil Chimento asked if it made sense to have a general MIB at all, or is it better to have reporting in the context of an application? Andy agreed to the need to provide results in the context of an application. There was some short discussion of the pros and cons of a simple ring-buffer based MIB, and whether the update rates would just overwhelm a simple implementation. Was there a use case for a simple MIB? Finally, Matt presented the remaining open issue with the MIB registry, whether to include branches for enterprises and "other standards bodies". Andy was of the opinion that a centralized place to look for the values is enough. --==========AFA06220432B73BC891C========== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm --==========AFA06220432B73BC891C==========-- From ippm-bounces@ietf.org Mon Sep 6 21:43:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19467 for ; Mon, 6 Sep 2004 21:43:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4UzM-0006Ck-4I; Mon, 06 Sep 2004 21:41:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4UyH-00063a-JA for ippm@megatron.ietf.org; Mon, 06 Sep 2004 21:40:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19049 for ; Mon, 6 Sep 2004 21:40:31 -0400 (EDT) Received: from web15202.mail.cnb.yahoo.com ([202.43.216.132] helo=web15202.mail.bjs.yahoo.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C4V1a-0000O8-Jf for ippm@ietf.org; Mon, 06 Sep 2004 21:44:01 -0400 Message-ID: <20040907013949.56919.qmail@web15202.mail.bjs.yahoo.com> Received: from [202.96.96.35] by web15202.mail.cnb.yahoo.com via HTTP; Tue, 07 Sep 2004 09:39:49 CST Date: Tue, 7 Sep 2004 09:39:49 +0800 (CST) From: =?gb2312?q?Jing=20Shen?= To: ippm@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id VAA19049 Subject: [ippm] Method of measuring bandwidth of Golden Service Class? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi, As I know some ISPs enable QoS in their network. And, serveral service classes (Real time, Golden, Silver, Bronze , Best Effort) are provided to customers. Beside measuring e2e QoS parameters like delay, jitter, is there any method available to measure bandwidth used or bandwidth available on each service class ? regards Jing Shen _________________________________________________________ Do You Yahoo!? 150=CD=F2=C7=FAMP3=B7=E8=BF=F1=CB=D1=A3=AC=B4=F8=C4=FA=B4=B3=C8=EB=D2=F4=C0= =D6=B5=EE=CC=C3 http://cn.rd.yahoo.com/mail_cn/tag/yisou/music/*http://music.yisou.com/ =C3=C0=C5=AE=C3=F7=D0=C7=D3=A6=D3=D0=BE=A1=D3=D0=A3=AC=CB=D1=B1=E9=C3=C0=CD= =BC=A1=A2=D1=DE=CD=BC=BA=CD=BF=E1=CD=BC http://cn.rd.yahoo.com/mail_cn/tag/yisou/image/*http://image.yisou.com 1G=BE=CD=CA=C71000=D5=D7=A3=AC=D1=C5=BB=A2=B5=E7=D3=CA=D7=D4=D6=FA=C0=A9=C8= =DD=A3=A1 http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mai= l_1g/ _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Sep 7 05:02:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02292 for ; Tue, 7 Sep 2004 05:02:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4bkN-0001Qo-LT; Tue, 07 Sep 2004 04:54:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4bdJ-0000ER-KP for ippm@megatron.ietf.org; Tue, 07 Sep 2004 04:47:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01333 for ; Tue, 7 Sep 2004 04:47:19 -0400 (EDT) Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4bgh-0007jg-RM for ippm@ietf.org; Tue, 07 Sep 2004 04:50:53 -0400 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i878eBJS015583 for ; Tue, 7 Sep 2004 03:40:11 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i878e8JS015545 for ; Tue, 7 Sep 2004 03:40:09 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [ippm] IPPM MIB Date: Tue, 7 Sep 2004 11:47:16 +0300 Message-ID: Thread-Topic: [ippm] IPPM MIB Thread-Index: AcSDbzVACLjUo0zzSQai7YALPUJbQwRR24Fw From: "Romascanu, Dan \(Dan\)" To: "Henk Uijterwaal \(RIPE NCC\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: quoted-printable One piece of information that would be useful and would complement = information in other MIB modules is the list of metrics supported by a = specific application. The current IPPM MIB proposal includes such = information with reference to the IPPM registry. I would like to see = this functionality preserved.=20 Regards, Dan >=20 > * What information would you like to see in a management=20 > interface of a > measurement system? >=20 _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed Sep 8 22:38:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24536 for ; Wed, 8 Sep 2004 22:38:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5En2-0006nV-HD; Wed, 08 Sep 2004 22:36:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4rWl-0000k5-FC for ippm@megatron.ietf.org; Tue, 07 Sep 2004 21:45:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26320 for ; Tue, 7 Sep 2004 21:45:37 -0400 (EDT) Received: from out014pub.verizon.net ([206.46.170.46] helo=out014.verizon.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4raI-0004ku-Ps for ippm@ietf.org; Tue, 07 Sep 2004 21:49:20 -0400 Received: from [192.168.2.40] ([151.200.37.13]) by out014.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040908014536.KKLJ24490.out014.verizon.net@[192.168.2.40]>; Tue, 7 Sep 2004 20:45:36 -0500 In-Reply-To: <20040907013949.56919.qmail@web15202.mail.bjs.yahoo.com> References: <20040907013949.56919.qmail@web15202.mail.bjs.yahoo.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Philip F. Chimento Jr." Subject: Re: [ippm] Method of measuring bandwidth of Golden Service Class? Date: Tue, 7 Sep 2004 21:45:36 -0400 To: Jing Shen X-Mailer: Apple Mail (2.619) X-Authentication-Info: Submitted using SMTP AUTH at out014.verizon.net from [151.200.37.13] at Tue, 7 Sep 2004 20:45:36 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 08 Sep 2004 22:35:59 -0400 Cc: ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello Jing: I haven't seen anything in the literature about a method for doing this. Measuring bandwidth and available bandwidth is difficult enough. It seems to me that you would need to have some mechanism in the routers (or possibly compute it from paramters kept in some of the MIBs). Perhaps someone on the list knows of some work in this area? Regards, Phil Chimento On Sep 6, 2004, at 21:39, Jing Shen wrote: > Hi, > > > As I know some ISPs enable QoS in their network. And, > serveral service classes (Real time, Golden, Silver, > Bronze , Best Effort) are provided to customers. > > Beside measuring e2e QoS parameters like delay, > jitter, is there any method available to measure > bandwidth used or bandwidth available on each service > class ? > > regards > > Jing Shen > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www1.ietf.org/mailman/listinfo/ippm > _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Fri Sep 10 06:07:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09180 for ; Fri, 10 Sep 2004 06:07:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5iFg-0006vT-PR; Fri, 10 Sep 2004 06:03:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5iC3-000632-EZ for ippm@megatron.ietf.org; Fri, 10 Sep 2004 05:59:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08838 for ; Fri, 10 Sep 2004 05:59:44 -0400 (EDT) Received: from phoebe.eim.surrey.ac.uk ([131.227.74.4] ident=exim) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5iG4-0002QH-SL for ippm@ietf.org; Fri, 10 Sep 2004 06:03:58 -0400 Received: from ccsrlt70.ee.surrey.ac.uk ([131.227.89.220] ident=root) by phoebe.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 1C5iBq-0001va-00; Fri, 10 Sep 2004 10:59:34 +0100 Received: from localhost (eep2ll@localhost) by ccsrlt70.ee.surrey.ac.uk (8.11.6/8.9.3) with ESMTP id i8A9xYp10323; Fri, 10 Sep 2004 10:59:34 +0100 X-Authentication-Warning: ccsrlt70.ee.surrey.ac.uk: eep2ll owned process doing -bs Date: Fri, 10 Sep 2004 10:59:33 +0100 (BST) From: Lei Liang X-X-Sender: eep2ll@ccsrlt70.ee.surrey.ac.uk To: "Henk Uijterwaal (RIPE NCC)" Subject: Re: [ippm] why no considerations on the multi-to-multi measurement Metrics? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-107.1 required=5.5 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE, USER_IN_WHITELIST,X_AUTH_WARNING autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanner: exiscan *1C5iBq-0001va-00*1wU4PtJ8XY.* (SECM, UniS) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Dear Henk and all, I just managed to submit the internet draft to the internet-drafts@ietf.org and cc to the working group as well. the file name is draft-liang-multiparty-para-00.txt. I will very appreciate any comments from you. Best regards, Lei Liang On Tue, 3 Aug 2004, Henk Uijterwaal (RIPE NCC) wrote: > Dear Lei, > > > The enclosed document shows some intitial thoughts on this issue. I will > > be very glad to hear any comments regarding this consideration. > > We discussed this briefly yesterday and suggest that you turn your note > into an Internet draft (Individual submission) and submit that. On the > list, we can then discuss to pick this up as a working group item. > > Henk > > > ------------------------------------------------------------------------------ > Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net > RIPE Network Coordination Centre http://www.amsterdamned.org/~henk > P.O.Box 10096 Singel 258 Phone: +31.20.5354414 > 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 > The Netherlands The Netherlands Mobile: +31.6.55861746 > ------------------------------------------------------------------------------ > > Process and Procedure are the last hiding place of people without the wit > and wisdom to do their job properly. (David Brent). > _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Fri Sep 10 10:12:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28801 for ; Fri, 10 Sep 2004 10:12:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5lvb-0003ve-RF; Fri, 10 Sep 2004 09:59:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5NX7-0003Av-Se; Thu, 09 Sep 2004 07:56:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10555; Thu, 9 Sep 2004 07:56:07 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C5Naw-0000Jf-4i; Thu, 09 Sep 2004 08:00:07 -0400 Received: from ads33.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Thu, 9 Sep 2004 12:17:55 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads33.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.0); Thu, 9 Sep 2004 12:17:47 +0100 Received: from 131.227.89.220 ([131.227.89.220]) by EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.152]) with Microsoft Exchange Server HTTP-DAV ; Thu, 9 Sep 2004 11:17:45 +0000 Received: from ccsrlt70 by evs-ec1-node1.surrey.ac.uk; 09 Sep 2004 12:17:45 +0100 From: Lei Liang To: internet-drafts@ietf.org Content-Type: multipart/mixed; boundary="=-hJycOzof3X5dQjkc8XQh" Message-Id: <1094728664.2187.28.camel@ccsrlt70.ee.surrey.ac.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 09 Sep 2004 12:17:45 +0100 X-OriginalArrivalTime: 09 Sep 2004 11:17:47.0926 (UTC) FILETIME=[A3040B60:01C4965E] X-Spam-Score: 1.2 (+) X-Scan-Signature: 52005c17383d4e3f609075a067e11971 X-Mailman-Approved-At: Fri, 10 Sep 2004 09:59:03 -0400 Cc: ippm@ietf.org Subject: [ippm] Individual internet draft--(draft-liang-multiparty-para-00.txt) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org --=-hJycOzof3X5dQjkc8XQh Content-Type: text/plain Content-Transfer-Encoding: 7bit To whom it may concern Dear Sir/lady, My name is Lei Liang. I was encouraged by the IPPM working group to submit an Individual internet draft for the multiparty communication parameters and metrics. the file name is draft-liang-multiparty-para-00.txt. Please find the enclosed draft. the abstract is shown below. Abstract The purpose of this memo is to highlight the new QoS requirements of the multiparty communication services in terms of measurement parameters. It tries to derive a set of parameter metrics from the existing one-way metrics in IP Performance metrics IPPM [2] [3] [4] for the multiparty communications to present these new requirements. These parameter metrics are supposed to provide methods and rules for engineers to measure and judge the QoS of the multiparty communications. Thank you very much for your concern. Best regards, lei Liang -- CCSR, University of Surrey Lei Liang email:l.liang@surrey.ac.uk Tel: +44 (0)1483686013 --=-hJycOzof3X5dQjkc8XQh Content-Disposition: attachment; filename=draft-liang-multiparty-para-00.txt Content-Type: text/plain; name=draft-liang-multiparty-para-00.txt; charset=us-ascii Content-Transfer-Encoding: 7bit Network Working Group Lei Liang Internet Draft Zhili Sun Expiration Date: February 2005 UniS September 2004 Multiparty Communication Parameters and Metrics 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that Other groups may also distribute working documents as Internet-Drafts Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 2. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. 3. Abstract The purpose of this memo is to highlight the new QoS requirements of the multiparty communication services in terms of measurement parameters. It tries to derive a set of parameter metrics from the existing one-way metrics in IP Performance metrics IPPM [2] [3] [4] for the multiparty communications to present these new requirements. These parameter metrics are supposed to provide methods and rules for engineers to measure and judge the QoS of the multiparty communications. 4. Overview Liang et al. [Page 1] INTERNET-DRAFT Multiparty Communication parameters August 2004 The structure of the memo is as follows: + We discuss the new QoS requirements of the multiparty communications and point out the weakness of using one-way metrics in these communications. + Then we will propose a set of parameters and their metrics for multiparty communication based on the one-way metrics defined in IPPM. + We will further discuss the possible usage of these proposed metrics. 5. Motivation All IPPM QoS parameter metrics are defined for one-to-one connections. These metrics provide very good guide in the pair communications. However, further attention should be put on the multiparty communications, which might use multicast routing protocols, e.g. the IP conferencing services, online gaming, online stock market and etc.. The basic consideration is that in the multiparty communication, we have a group of people involved in the communication rather than two. Simple one-way parameter metrics cannot describe the multi-connection situation. One may say that no matter how many people join the communication, the connections can still be treated as a set of one-to-one connection. However, we might not describe a multiparty communication by a set of one-way measurement metrics because of the difficulty for understanding and the lack of convenience. For instance, an engineer might not describe the connections of a multiparty online conference in terms of one-way delay for user A and B, B and C, and C and A because people might be confused. If there are more users in the same communication, the description might be very long. And he might use the one-way metrics with worst and the best value to give users an idea of the QoS range of the service they are provided. But it's not clear enough and might not be accurate in a large multiparty communication scenario. The new suggestion is to use the one-way parameters in a more sophisticated way after reasonable mathematic deriving, i.e. mean, variation etc. The new metrics will be more efficient and accurate to express the connection situation among a group of users. From the QoS point of view, the multiparty communication services not only require the absolute QoS support but also the relative QoS. The relative QoS means the difference between absolute QoS of all users. Directly using the one-way metrics cannot present the relative QoS situation. However, if we use the variations of all users one-way parameters, we can have new metrics to measure the difference of the absolute QoS and hence provide the threshold value of relative QoS that a multiparty service might demand. A very good example of the Liang et al. [Page 2] INTERNET-DRAFT Multiparty Communication parameters August 2004 high relative QoS requirement is the online gaming. A very light worse delay will result in failure in the game. We have to use the new metrics to define exactly how small the relative delay the online gaming requires. There are many other services, e.g. online biding, online stock market, etc., need a rule to judge the relative QoS requirement. Therefore, we can see the importance of new metrics to feed this need. Two groups of parameter are proposed in this stage. 6. Parameters and Metrics for Multiparty Communication To conveniently define new metrics, we call all of the users in the same multiparty communication a user group. This user group should not be mixed with the multicast user group conception. Group members could use either pure unicast or multicast to communicate or mixed, i.e. some of the users in the group could use unicast while others use multicast. When talking about a new metrics we always have an observation point that is one of the users in the group. We classify the new metrics into two groups based on the fact that one user could be either a source or a receiver. Therefore, one group metrics will describe the QoS going out from the group to one particular user and another group describe the QoS coming into the group. We name them as one-to-group parameter metrics and group-to-one parameter metrics. In the document,both of two group parameters are called multiparty communication parameters. These new proposed metrics are established on the base of the one-way metrics defined in the corresponding RFCs in the IPPM working group. And no modification should be added to those one-way metrics in any aspects. This memo only describes the basic aspect of the proposed metrics. Any aspect that is not mentioned in this memo can be found in the corresponding one-way metric RFCs. 6.1 One-to-group Parameters and Metrics One-to-group parameters are defined to measure the QoS in the view of a group user. Two subset parameters are introduced: 1. One-to-group (algorithm) mean a. One-to-group mean delay b. One-to-group mean jitter c. One-to-group mean packet lost rate 2. One-to-group variation a. One-to-group delay variation b. One-to-group jitter variation c. One-to-group packet loss rate variation Liang et al. [Page 3] INTERNET-DRAFT Multiparty Communication parameters August 2004 The one-to-group parameters are measured based on only one source in a multiparty communication group. Whenever we say one-to-group parameter, we should associate it with a source. The Figure 1 shows this concept. +---------+ | User B | +---------+ ^ | IP Network | +--------+ +---------+ +--------+ | User C |<-IP Network--| User D |--Satellit link->| User A | +--------+ +---------+ +--------+ | | LAN | v +---------+ | User E | +---------+ Figure 1 One-to-group measurement scenario example In Figure 1, user A, B, C, D and E belong to the same multiparty communication group. User D is the only active source in the group when measuring the one-to-group parameters. User B and C are connected with user D through terrestrial IP network, user E are in the same LAN with user D. User A are connected with user D using a satellite network. The one-to-group parameters measured in this scenario should be associated with user D. 6.1.1 One-to-group (Arithmetic) Mean One-to-group mean parameters are trying to measure the overall QoS for a multiparty communication group. The definition of the One-to-group mean is the mean of a one-way parameter, such as one-way delay, one-way jitter and packet loss rate, measured simultaneously on all of the group members except of the active source. The word "simultaneously" implies the one-way parameter should be measured based on the same sample interval at each user. The One-to-group mean parameter can be calculated as: P_ogm_para = SUM (Pi)/ N ( i = 1, 2, 3, ... N) (Equation 1) where P_ogm_para is the One-to-group mean parameter, Pi is the corresponding one-way parameter. N is the number of the users except the active user in the group during the sampling interval. Liang et al. [Page 4] INTERNET-DRAFT Multiparty Communication parameters August 2004 "para" means the one-way parameter's name such as delay, jitter and packet loss rate. 6.1.1.1 Metric Name: Type-P-One-to-group-Mean-Parameter The "Parameter" could be any one of the one-way parameter defined in IPPM including delay, jitter and packet loss rate. 6.1.1.2 Metric Parameters: + Src, the IP address of a source + Grp, the multicast group address is multicast or empty for non-multicast + M, a derived value corresponding to one-way parameter 6.1.1.3 Metric Units: The value of a Type-P-One-to-group-Mean-Parameter is depends on what one-way parameter is used. It should be the same corresponding to the one-way metrics defined in IPPM. 6.1.1.4 Methodologies: As the metric is derived from the corresponding one-way metric, the methodology to obtain those one-way parameters can be refer to the corresponding RFCs. We only discuss the methodology to derive One-to-group mean metric from one-way parameter without consideration of details on synchronization, test packetizing, time and etc.. 1. Simultaneously measure the interested one-way parameters, one-way delay, one-way jitter or packet loss, on all of the receivers in a multiparty communication group when there is only one source active. 2. Calculate the mean of one-way metric value using equation 1 to obtain the One-to-group mean metric for this source. The question of when to calculate the One-to-group mean metric will be discussed in 6.1.1.5. 3. Change the active source and repeat the step 1 and 2 until all of the group members have been active as sources. Liang et al. [Page 5] INTERNET-DRAFT Multiparty Communication parameters August 2004 6.1.1.5 Discussion: In the second step of methodology part, we have to decide when to do the One-to-group mean metric calculation. Basically, there are three ways to do so. The first way is to do the calculation based on each packet arrival. The active source sends packet one by one with sequence number in the packet headers so that all receiver could identify each packet. The One-to-group mean calculation is executed for each packet received by all receivers. The resulted metric is similar to the singleton metrics defined for one-way parameters corresponding to every packet received by all users. It will provide the most accurate record of the group mean during a sampling interval with the heaviest calculation overhead. The second way to calculate the One-to-group mean is to use the mean of one-way parameter rather than the parameter itself. The calculation could be scheduled to be executed periodically. For instance, it can be triggered for every T seconds. During the T seconds, all one-way parameters measured have to be recorded at each receiver. At each T second, the mean of the recorded parameter will be calculated first at each receiver and used as in equation 1 to calculate the One-to-group mean metric value. This way can reduce the heavy calculation overhead required by the first one. However, it would provide less detailed information and need more storage space to record one-way parameters for more than one packet. The third way to calculate the One-to-group mean metric is to mix the previous two ways together. We periodically calculate the One-to-group mean parameter using directly the corresponding one-way parameter metric value rather than using its mean. For instance, the calculation can be prearranged to be triggered for every T seconds. The receivers don't need to record the one-way metric value for all of the packets received during each T seconds. we would calculate the One-to-group mean metric value at each T second using the corresponding one-way parameter of the latest received packet. Therefore, the One-to-group mean metrics of all receivers calculated at the same time would not be for the same packet. However, that would not affect engineers to use these metrics because they can still present the network situation at each T second without regarding to packets. Hence, the sequence number seems not necessary for One-to-group mean delay and jitter metrics. However, it still has to been added to the test packets to notify the packet loss. By calculating the One-to-group mean metrics in this way, we can overcome the requirement of big storage space on each receiver and the calculation overhead. One point has to be mentioned here is the calculation of the One-to-group mean packet loss rate. Because the packet loss rate itself is a statistic parameter for a certain measurement interval, Liang et al. [Page 6] INTERNET-DRAFT Multiparty Communication parameters August 2004 we have to use the second way to calculate the One-to-group mean packet loss rate. Clearly, the One-to-group mean calculation period T is a very important factor in the implementation of the measurement. If it is too small, we will not save any calculation overhead. If it is too big, we might loss most of the network situation information. And it might be different for various applications as well. However, how to find a proper T is outside the scope of this document. {Comment: We plan to document elsewhere our own work in describing such more detailed implementation techniques and we encourage others to as well.} 6.1.2 One-to-group Variation One-to-group variation metrics are trying to measure how the QoS varies among all of the users in a multiparty communication group relative to one source. The word "variation" in this document is the population standard deviation. The definition of the One-to-group variation is the population standard deviation of a one-way parameter, such as one-way delay, one-way jitter and packet loss rate, measured simultaneously at all of the group members except of the active source. Therefore, we can have One-to-group delay variation, One-to-group jitter variation and One-to-group packet loss rate variation. The word "simultaneously" implies the one-way parameter should be measured based on the same sample interval at each user. Considering the case shown in Figure 1 as an example, when D is active, we simultaneously monitor a set of packets from P1 to Pn on all of the rest 4 users respectively. Then, the interested one-way parameter of these packets is calculated for each of user. The corresponding One-to-group mean metric could be calculated based on the one-way parameter. Finally, we calculate the variation of these 4 values of the one-way parameter measured on 4 receivers as the One-to-group variation parameter for this scenario. The One-to-group variation parameter can be denoted by P_ogv_para, where the symbol "para" means the one-way parameter's name such as delay, jitter and packet loss rate, and calculation should be: P_ogv_para = ((SUM((Pi-P_ogm_para)^2))/N)^(1/2) (i = 1, 2, 3,...N) (Equation 2) where Pi is the one-way parameter value (delay, jitter and packet loss rate) and P_ogm_para is the corresponding One-to-group mean parameter value. N is the number of the receivers. 6.1.2.1 Metric Name: Liang et al. [Page 7] INTERNET-DRAFT Multiparty Communication parameters August 2004 Type-P-One-to-group-Variation-Parameter The "Parameter" could be any one of the one-way parameter defined in IPPM including delay, jitter and packet loss rate. 6.1.2.2 Metric Parameters: + Src, the IP address of a source + Grp, the multicast group address is multicast or empty for non-multicast + V, a derived value corresponding to one-way parameter 6.1.2.3 Metric Units: The value of a Type-P-One-to-group-Variation-Parameter is depends on what one-way parameter is used. It should be the same corresponding to the one-way metrics defined in IPPM. 6.1.2.4 Methodologies: As the One-to-group variation parameter metric has to be derived on the base of the group mean metric, we have to calculate the One-to-group mean metric first. So the methodology become simple inheriting from the one defined for the One-to-group mean metric. 1. Find out the One-to-group mean parameters 2. Calculate the One-to-group variation parameters using the equation 2. 3. Repeat the step 1 and 2 for all users in the same multiparty communication group. 6.1.2.5 Discussion: As the One-to-group variation parameters must be derived based on the One-to-group mean parameter, its calculation must be corresponding to the one of the One-to-group mean parameter described in section 4.1.1.5. I.e., for each One-to-group mean parameter calculation, we can have the corresponding One-to-group variation parameter calculation. 6.2 Group-to-one Parameter Metrics Liang et al. [Page 8] INTERNET-DRAFT Multiparty Communication parameters August 2004 Group-to-one parameters are defined to measure the QoS in the view of one multiparty communication user with respect to the fact that this user is receiving from more than one source in the group. Similar to the one-to-group parameters, two subset parameters are proposed: 1. Group-to-one member (arithmetic) mean a. Group-to-one mean delay b. Group-to-one mean jitter c. Group-to-one mean packet loss rate 2. Group-to-one variation a. Group-to-one delay variation b. Group-to-one jitter variation c. Group-to-one packet loss rate variation The group-to-one parameters are measured based on only one receiver in a multiparty communication group. Whenever we say group-to-one parameter, we should associate it with the receiver. The Figure 2 shows this concept. +---------+ | User B | +---------+ | IP Network | v +--------+ +---------+ +--------+ | User C |--IP Network->| User D |<-Satellit link--| User A | +--------+ +---------+ +--------+ ^ | LAN | | +---------+ | User E | +---------+ Figure 2 Group-to-one measurement scenario example Figure 2 shows almost the same information as Figure 1. The difference is, in Figure 4, user D is the receiver who received data from all of the rest group members simultaneously or consequently. The group-to-one parameters measured in this scenario should be measured and associated with user D. In the following sections, we will define these parameters and their metrics. You will find the definitions are very similar to one-to-group parameters. One might question on if we need to have separately definitions of one-to-group and group-to-one Liang et al. [Page 9] INTERNET-DRAFT Multiparty Communication parameters August 2004 parameters. The answer is positive and we will discuss it after the definition. 6.2.1 Group-to-one (arithmetic) Mean Group-to-one mean parameters are trying to measure the QoS of a multiparty communication group received by one user. The definition of the Group-to-one mean parameter of a user is the mean of a one-way parameter, such as one-way delay, one-way jitter and packet loss rate, measured on that user when it simultaneously receiving data from all the rest users in the group. The word "simultaneously" implies the one-way parameter should be measured based on the same sample interval on the measured user. The Group-to-one mean parameter can be calculated as: P_gom_para = SUM (Pi)/N (i = 1,2,3,...N) (Equation3) where P_gom_para is the Group-to-one mean parameter, Pi is the corresponding one-way parameter from each of the source to the measured user. N is the number of the users except the measured user in the group during the sampling interval. "para" means the one-way parameter's name such as delay, jitter and packet loss rate. 6.2.1.1 Metric Name: Type-P-Group-to-one-Mean-Parameter The "Parameter" could be any one of the one-way parameter defined in IPPM including delay, jitter and packet loss rate. 6.2.1.2 Metric Parameters: + Dst, the IP address of a receiver + Grp, the multicast group address is multicast or empty for non-multicast + M, a derived value corresponding to one-way parameter 6.2.1.3 Metric Units: The value of a Type-P-Group-to-one-Variation-Parameter is depends on what one-way parameter is used. It should be the same corresponding to the one-way metrics defined in IPPM. Liang et al. [Page 10] INTERNET-DRAFT Multiparty Communication parameters August 2004 6.2.1.4 Methodologies: As the group-to-one mean parameter metric also derived on the base of the corresponding one-way parameter metric, we still only discuss the methodology to derive Group-to-one mean metric from one-way metric without consideration of details on synchronization, test packetizing, time and etc.. 1. Simultaneously measure the interested one-way parameters, one-way delay, one-way jitter or packet loss, on the measured user while all of the rest of users in the multiparty communication group sending data to it. All the one-way parameter should be measured based on the source and destination pair. 2. Calculate the mean of one-way metric value using equation 3 to obtain the Group-to-one mean metric for the measured user. The question of when to calculate the group-to-one mean metric will be discussed in 4.2.1.5. 3. Change the active source and repeat the step 1 and 2 until all of the group members have been measured. 6.2.1.5 Discussion: As we did to the One-to-group mean parameter, we should determine when to calculate the Group-to-one parameter here. Clearly we can use the three ways proposed for the One-to-group mean parameter to calculate the Group-to-one mean parameter. The only difference is the former has many measurement points and calculation has to be done with the information provided by all of these measurement points while for the later all information needed for the group-to-one parameter can be provided by a single measurement point. 6.2.2 Group-to-one Variation Group-to-one variation metrics are trying to measure how the QoS varies at one user in the multiparty communication group when the rest of users sending data to it. The definition of the Group-to-one variation is the population standard deviation of a one-way parameter, such as one-way delay, one-way jitter and packet loss rate, measured at one user in a multiparty communication group while all of the rest group members sending data simultaneously to it. Therefore, we can have Group-to-one delay variation, Group-to-one jitter variation and Group-to-one packet loss rate variation. The word "simultaneously" implies Liang et al. [Page 11] INTERNET-DRAFT Multiparty Communication parameters August 2004 the one-way parameter should be measured based on the same sample interval at the measured user. Considering the case shown in Figure 2 as an example, when D is chose as the measured user, we simultaneously monitor a set of packets from P1 to Pn sent by each of the rest 4 users respectively. Then, the interested one-way parameter of these packets is calculated for each pair of users, i.e., D and A, D and B, D and C and D and E. The corresponding Group-to-one mean metric could be calculated based on the one-way parameter. Finally, we calculate the variation of these 4 values as the Group-to-one variation parameter for this scenario. The One-to-group variation parameter can be denoted by P_gov_para, where the symbol "para" means the one-way parameter's name such as delay, jitter and packet loss rate, and calculation should be: P_gov_para = ((SUM((Pi-P_gom_para)^2))/N)^(1/2) (i = 1, 2, 3,...N) (Equation 4) N is the total user number in the multiparty communication except the measured one and pi is the one-way parameter for each of the N users. 6.2.2.1 Metric Name: Type-P-Group-to-one-Variation-Parameter The "Parameter" could be any one of the one-way parameter defined in IPPM including delay, jitter and packet loss rate. 6.2.2.2 Metric Parameters: + Dst, the IP address of a receiver + Grp, the multicast group address is multicast or empty for non-multicast + V, a derived value corresponding to one-way parameter 6.2.2.3 Metric Units: The value of a Type-P-Group-to-one-Variation-Parameter is depends on what one-way parameter is used. It should be the same corresponding to the one-way metrics defined in IPPM. 6.2.2.4 Methodologies: Liang et al. [Page 12] INTERNET-DRAFT Multiparty Communication parameters August 2004 The methodology can be simply inherited from the one defined for the Group-to-one mean metric as: 1. Find out the Group-to-one mean parameters 2. Calculate the Group-to-one variation parameters using the equation 4 3. Repeat the step 1 and 2 for all users in the same multiparty communication group 6.2.2.5 Discussion: As the Group-to-one variation parameters must be derived based on the Group-to-one mean parameter, its calculation must be corresponding to the one of the Group-to-one mean parameter described in section 4.2.1.5. I.e., for each Group-to-one mean parameter calculation, we can have the corresponding Group-to-one variation parameter calculation. 6.3 Reasons for Two groups of similar parameters As we mentioned in the beginning of section 4.2, the definitions of One-to-group parameters and Group-to-one parameters are very similar. There are reasons we should separately define them. Firstly it is because of the metric parameter definition. The One-to-group metrics have a common parameter, Src, the IP address of the active source during the measurement interval. It must be changed to Dst parameter for the Group-to-one metrics to present the measured user. It's not like the case for the one-way parameter measurement where the destination and the source are single host in the same level. They can be exchanged in the measurement without any difficulty. Therefore one metric is enough for measurement between one pair of hosts. In the multiparty communication, the source and the destination cannot be exchanged because one of them presents more than one user. We have to define two metrics for the measurement for two directions. For instance, if user A and user B communicates with each other, the one-way delay metric can be used for both direction traffics by exchanging the Src and Dst parameter [3]. However, if user C joins their communication, we have to user the proposed new metrics to measure the QoS for the multiparty communication. The One-to-group mean delay metric and the One-to-group delay variation can show clearly the QoS received by user A and user B in the group relative to user C. We cannot use the same metrics to measure the QoS received by C relative to both user A and user B by simply exchanging the Src and Grp parameter in the metric because of the methodology described for One-to-group parameter. Liang et al. [Page 13] INTERNET-DRAFT Multiparty Communication parameters August 2004 Secondly, we should define Group-to-one and One-to-group separately because of the transporting technologies used for multiparty communications. There might be the coexistence of both unicast and multicast. One host in a multiparty communication group might use unicast to receive data from other hosts and user multicast to send data to the others. The delay of each direction would be different due to the difference of the transport technologies. If we can say that for one-to-one communications, delays for both directions can be approximately the same, we might not have the same conclusion for the multiparty communications. Therefore, we need two groups of metric to describe the network situation regarding the traffic direction. 7. Relative QoS and the Proposed Metrics There is an interesting point in the methodologies for obtaining the Group-to-one parameters that we have all of the rest users sending data simultaneously rather than let them work separately in order. The same question can also be asked for the methodology of the One-to-group parameter. As we discussed in the motivation part that the second reason we propose these new parameters and their metrics is that the multiparty communication have extra requirements on the relative QoS beside the absolute QoS. These proposed metrics could be used to describe and measure the relative QoS, which implies that all the one-way parameters needed to derive the Group-to-one and One-to-group parameters have to be measured in the same measurement interval rather than separately in an order. We cannot describe the relative QoS by compare the same parameter for different connection in different time. Here we have some example to show how to use the proposed metrics to describe and measure the relative QoS. For instance, the relative delay can be measured by using the Group-to-one and One-to-group delay variation metric. Group-to-one delay variation measures the difference of delays received by one user in a multiparty communication group relative to the rest sources. A centralized multiparty communication where all clients have to communicate with the rest group members through a central server might require the transmission delays from all clients to the server satisfy a Group-to-one delay variation threshold to guarantee that no clients suffer much bigger delay than others or enjoy much smaller delay than others. Typical examples are the services that need their users to compete with each other. The One-to-group delay variation measures how different for each user to receive data from one source in a multiparty communication group, which is another a relative QoS issue. No matte what topology the multiparty communication Liang et al. [Page 14] INTERNET-DRAFT Multiparty Communication parameters August 2004 service uses, it might need one One-to-group delay variation threshold to ensure that all group members can have the close priority to make further move to response to any source in the group. An example of the use of the proposed metrics might be the adaptable priority optimisation algorithm. The basic idea is to dynamically change the priority for each group member according to the network situation to guarantee that all members in the group have close QoS. In another word, the Group-to-one variation and One-to-group variation parameter should be kept under a certain threshold to satisfy the relative QoS requirements for various applications. The detail of this adaptable priority optimisation algorithm is out of the scope of this document. 8. Errors We are not going to discuss errors caused by the measurement of the one-way parameters in this document because they can be found in the corresponding RFCs. We have to discuss the errors introduced by the proposed metrics in this document. The reason of these errors is the packet loss in the network. When a packet never arrive its destination, its delay might be hidden from the result. When we discussed about when to calculate the proposed metrics, we gave three ways. The first way proved one-way parameter metrics corresponding to packets. That means for each packet we can find one metric for it. Then error caused by packet loss can then be easily sorted out before we calculate the Group-to-one and One-to-group parameters. However, for the other two ways, we either use a mean to present the interested one-way parameter or the last packet received by the measurement point during a period of time. If there are any packets lost in the period of time, they will be ignored by the calculation of the multiparty communication parameters. For instance, we do the calculation of the multiparty communication parameters for every T seconds. Then for the second way, the mean of the one-way delay in a T second could be infinity if any packets lost during that T second and infinity is a valid metric value for the one-way delay metric. Then our Group-to-one and One-to-group mean parameters and variation parameters could be infinity after calculation. This infinity doesn't mean anything in terms of relative delay for multiparty communication. We should not have the conclusion that during that T seconds, users in the group suffered significantly different delay. Liang et al. [Page 15] INTERNET-DRAFT Multiparty Communication parameters August 2004 For the third way where we only use the latest packet received during a T seconds, if all of the packets were lost during the T seconds, which is quite possible since T could be a very short time, the one-way metric value we use to calculate the multiparty communication parameters will be the one for the latest packet receiver in last T seconds. Clearly, the result will not reflect any information of the network situation during this T seconds and therefore, it becomes an error. The possible calibration can be done by using more sophisticated way to calculate the multiparty communication parameters. For instance, we can ignore all the one-way metrics with infinity value when we calculate the multiparty communication parameters for the second calculation way. We can find out which T seconds suffers from the packet lost and do not calculate the multiparty communication parameter for it in the third way. There might be other methods to calibrate the errors, which we did not discuss here. As long as they can avoid leading us to the wrong analysis, they can be implemented in the application. 9. References [1] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998. [2] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999. [3] G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999. [4] C. Demichelis, and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002. 8. Authors' Addresses Lei Liang Zhili Sun Expiration date: February 2005 --=-hJycOzof3X5dQjkc8XQh Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm --=-hJycOzof3X5dQjkc8XQh-- From ippm-bounces@ietf.org Mon Sep 13 06:42:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14402 for ; Mon, 13 Sep 2004 06:42:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6oCu-0007nS-EC; Mon, 13 Sep 2004 06:37:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6o8t-0007Ac-Fv for ippm@megatron.ietf.org; Mon, 13 Sep 2004 06:33:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13616 for ; Mon, 13 Sep 2004 06:33:00 -0400 (EDT) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6oDY-0004T5-GZ for ippm@ietf.org; Mon, 13 Sep 2004 06:37:53 -0400 Received: by postman.ripe.net (Postfix, from userid 8) id F36364E7E3; Mon, 13 Sep 2004 12:31:16 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 68D834E7FC for ; Mon, 13 Sep 2004 12:27:50 +0200 (CEST) Received: from x49.ripe.net (x49.ripe.net [193.0.1.49]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i8DARoDI015703 for ; Mon, 13 Sep 2004 12:27:50 +0200 Received: from localhost (henk@localhost) by x49.ripe.net (8.12.10/8.12.6) with ESMTP id i8DARonq021708 for ; Mon, 13 Sep 2004 12:27:50 +0200 X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Mon, 13 Sep 2004 12:27:50 +0200 (CEST) From: "Henk Uijterwaal (RIPE NCC)" To: ippm@ietf.org Subject: Re: [ippm] Individual internet draft-liang-multiparty-para-00.txt In-Reply-To: <1094728664.2187.28.camel@ccsrlt70.ee.surrey.ac.uk> Message-ID: References: <1094728664.2187.28.camel@ccsrlt70.ee.surrey.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: N 0.000006 / 0.0 / 0.0 / disabled X-RIPE-Signature: c6889f6e045513a063fc12750ae7a996 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Dear All, Lei Liang wrote: > I was encouraged by the IPPM working group to submit an Individual > internet draft for the multiparty communication parameters and metrics. Technically speaking, only the chairs encouraged him to do so after he asked us if this was appropriate for the WG. In any case, we'd like to hear comments both on the draft and the question whether IPPM should pick this up as work item. Kind regards, Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ In a room with a window in the corner, I found truth. (Ian Curtis) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed Sep 15 06:22:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19310 for ; Wed, 15 Sep 2004 06:22:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7Wr0-00059f-5I; Wed, 15 Sep 2004 06:17:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7Wkf-0003CH-Dz for ippm@megatron.ietf.org; Wed, 15 Sep 2004 06:11:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18789 for ; Wed, 15 Sep 2004 06:10:58 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7Wpk-00088y-3X for ippm@ietf.org; Wed, 15 Sep 2004 06:16:17 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 15 Sep 2004 12:10:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ippm] IPPM MIB Date: Wed, 15 Sep 2004 12:10:56 +0200 Message-ID: Thread-Topic: [ippm] IPPM MIB Thread-Index: AcSDbzVACLjUo0zzSQai7YALPUJbQwRR24FwAZP9diA= From: "STEPHAN Emile RD-CORE-LAN" To: "Romascanu, Dan \(Dan\)" X-OriginalArrivalTime: 15 Sep 2004 10:10:57.0107 (UTC) FILETIME=[4ADC2230:01C49B0C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: "Henk Uijterwaal \(RIPE NCC\)" , Matthew J Zekauskas , ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Dear Dan, Basiccally, which tables of the IPPM MIB do you consider useful for = other MIBs ? Regards Emile=20 -----Message d'origine----- De : ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] De la part de = Romascanu, Dan (Dan) Envoy=E9 : mardi 7 septembre 2004 10:47 =C0 : Henk Uijterwaal (RIPE NCC); ippm@ietf.org Objet : RE: [ippm] IPPM MIB One piece of information that would be useful and would complement = information in other MIB modules is the list of metrics supported by a = specific application. The current IPPM MIB proposal includes such = information with reference to the IPPM registry. I would like to see = this functionality preserved.=20 Regards, Dan >=20 > * What information would you like to see in a management interface of=20 > a > measurement system? >=20 _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed Sep 15 06:38:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20330 for ; Wed, 15 Sep 2004 06:38:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7X8e-0002G4-Qx; Wed, 15 Sep 2004 06:35:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7X1R-0001Iy-7f for ippm@megatron.ietf.org; Wed, 15 Sep 2004 06:28:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19706 for ; Wed, 15 Sep 2004 06:28:18 -0400 (EDT) Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7X6W-0008Qu-9i for ippm@ietf.org; Wed, 15 Sep 2004 06:33:37 -0400 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i8FAKtCa004133 for ; Wed, 15 Sep 2004 05:20:55 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i8FAKrCa004121 for ; Wed, 15 Sep 2004 05:20:54 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ippm] IPPM MIB Date: Wed, 15 Sep 2004 13:28:10 +0300 Message-ID: Thread-Topic: [ippm] IPPM MIB Thread-Index: AcSDbzVACLjUo0zzSQai7YALPUJbQwRR24FwAZP9diAAAejLUA== From: "Romascanu, Dan \(Dan\)" To: "STEPHAN Emile RD-CORE-LAN" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Cc: "Henk Uijterwaal \(RIPE NCC\)" , Matthew J Zekauskas , ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: quoted-printable the ippmMetricsTable. Regards, Dan > -----Original Message----- > From: STEPHAN Emile RD-CORE-LAN=20 > [mailto:emile.stephan@francetelecom.com] > Sent: 15 September, 2004 1:11 PM > To: Romascanu, Dan (Dan) > Cc: Henk Uijterwaal (RIPE NCC); ippm@ietf.org; Matthew J Zekauskas > Subject: RE: [ippm] IPPM MIB >=20 >=20 > Dear Dan, >=20 > Basiccally, which tables of the IPPM MIB do you consider=20 > useful for other MIBs ? >=20 > Regards > Emile=20 >=20 > -----Message d'origine----- > De : ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] De=20 > la part de Romascanu, Dan (Dan) > Envoy=E9 : mardi 7 septembre 2004 10:47 > =C0 : Henk Uijterwaal (RIPE NCC); ippm@ietf.org > Objet : RE: [ippm] IPPM MIB >=20 > One piece of information that would be useful and would=20 > complement information in other MIB modules is the list of=20 > metrics supported by a specific application. The current IPPM=20 > MIB proposal includes such information with reference to the=20 > IPPM registry. I would like to see this functionality preserved.=20 >=20 > Regards, >=20 > Dan >=20 >=20 > >=20 > > * What information would you like to see in a management=20 > interface of=20 > > a > > measurement system? > >=20 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www1.ietf.org/mailman/listinfo/ippm >=20 _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed Sep 15 10:10:19 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05628 for ; Wed, 15 Sep 2004 10:10:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7aIE-0000a0-2a; Wed, 15 Sep 2004 09:57:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6tdh-00049W-Lc for ippm@megatron.ietf.org; Mon, 13 Sep 2004 12:25:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14195 for ; Mon, 13 Sep 2004 12:25:10 -0400 (EDT) Received: from [69.84.11.62] (helo=mail.qosmetrics.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C6tiQ-0003tH-5i for ippm@ietf.org; Mon, 13 Sep 2004 12:30:06 -0400 Received: (qmail 23912 invoked from network); 13 Sep 2004 16:24:59 -0000 Received: from unknown (HELO yves) (82.127.31.196) by bugs.internal.qosmetrics.com with SMTP; 13 Sep 2004 16:24:59 -0000 Message-ID: <001401c499ae$14853550$8401a8c0@yves> From: "Yves Cognet" To: Date: Mon, 13 Sep 2004 18:23:57 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 2.2 (++) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 X-Mailman-Approved-At: Wed, 15 Sep 2004 09:57:52 -0400 Cc: ippm@ietf.org Subject: [ippm] re IPPM MIB X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Yves Cognet List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1861576417==" Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org --===============1861576417== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGkgSGVuayANCg0KUGxlYXNlIGZpbmQgZW5jbG9zZWQgbXkgY29tbWVudHMgZm9yIHBvaW50IDEN Cg0KLSBzeW5jaHJvbmlzYXRpb24gYWNjdXJhY3kgKHRoYXQgbGF5cyB0byBtZXRyaWNzIGFjY3Vy YWN5KSAtIE5UUCwgR1BTLCAuLi4gKGV2ZW50IG5vdGlmaWNhdGlvbiBpZiBhY2N1cmFjeSBsZXZl bCBpcyBiYWQpDQotIGFnZ3JlZ2F0aW9uIG9mIG1ldHJpY3MgKCB3aXRoIGEgaGlnaCBsZXZlbCBv ZiBhY2N1cmFjeSAtIG5vdCBhICJwaW5nIiBldmVyeSAxNSBtaW51dGVzICEpLCBhZ2dyZWdhdGlv biB3aWxsIHJlc3VsdHMgaW4gbG93ZXIgbmV0d29yayBidXJkZW4NCi0gYWxhcm0gbm90aWZpY2F0 aW9uIG9uIHRocmVzaG9sZHMgYXR0YWNoZWQgdG8gcGVydGluZW50IG1ldHJpY3MNCi0gb25lIHZp ZXcgb2YgbWV0cmljcyBwZXIgdXNlciAoIGhvdyB5b3UgY2FuIG1hbmFnZSB1c2VyIFNMQSBhbmQg UW9TIG92ZXIgVlBOICkNCi0gY2FwYWNpdHkgdG8gcmVnaXN0ZXIgbmV3IG1ldHJpY3MgKGV2ZW4g cHJvcHJpZXRhcnkpIGluIHRoZSBJUFBNIHJlZ2lzdHJ5IA0KLSBjYXBhY2l0eSB0byBjb3ZlciBh bGwgSVAgdHJhbnNwb3J0IHByb3RvY29scy4oVURQLCBUQ1AgYW5kIGFib3ZlIGFwcGxpY2F0aW9u cyBIVFRQLFJUUCwuLikNCi0gY2FwYWNpdHkgdG8gc2VlIHRlc3QgY29uZmlndXJhdGlvbg0KDQpy ZWdhcmRzDQpZdmVzIENvZ25ldA0KDQoNCg0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0t LS0gDQpGcm9tOiA8aXBwbS1yZXF1ZXN0QGlldGYub3JnPg0KVG86IDxpcHBtQGlldGYub3JnPg0K U2VudDogTW9uZGF5LCBBdWd1c3QgMTYsIDIwMDQgNjoxNCBQTQ0KU3ViamVjdDogaXBwbSBEaWdl c3QsIFZvbCAzLCBJc3N1ZSA4DQoNCg0KPiBTZW5kIGlwcG0gbWFpbGluZyBsaXN0IHN1Ym1pc3Np b25zIHRvDQo+IGlwcG1AaWV0Zi5vcmcgDQo+IA0KPiBUbyBzdWJzY3JpYmUgb3IgdW5zdWJzY3Jp YmUgdmlhIHRoZSBXb3JsZCBXaWRlIFdlYiwgdmlzaXQNCj4gaHR0cHM6Ly93d3cxLmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaXBwbQ0KPiBvciwgdmlhIGVtYWlsLCBzZW5kIGEgbWVzc2FnZSB3 aXRoIHN1YmplY3Qgb3IgYm9keSAnaGVscCcgdG8NCj4gaXBwbS1yZXF1ZXN0QGlldGYub3JnIA0K PiANCj4gWW91IGNhbiByZWFjaCB0aGUgcGVyc29uIG1hbmFnaW5nIHRoZSBsaXN0IGF0DQo+IGlw cG0tb3duZXJAaWV0Zi5vcmcgDQo+IA0KPiBXaGVuIHJlcGx5aW5nLCBwbGVhc2UgZWRpdCB5b3Vy IFN1YmplY3QgbGluZSBzbyBpdCBpcyBtb3JlIHNwZWNpZmljDQo+IHRoYW4gIlJlOiBDb250ZW50 cyBvZiBpcHBtIGRpZ2VzdC4uLiINCj4gDQo+IA0KPiBUb2RheSdzIFRvcGljczoNCj4gDQo+ICAg IDEuIElQUE0gTUlCIChIZW5rIFVpanRlcndhYWwgKFJJUEUgTkNDKSkNCj4gDQo+IA0KPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+IA0KPiBNZXNzYWdlOiAxDQo+IERhdGU6IE1vbiwgMTYgQXVnIDIwMDQgMTA6 NDM6MTggKzAyMDAgKENFU1QpDQo+IEZyb206ICJIZW5rIFVpanRlcndhYWwgKFJJUEUgTkNDKSIg PGhlbmtAcmlwZS5uZXQ+DQo+IFN1YmplY3Q6IFtpcHBtXSBJUFBNIE1JQg0KPiBUbzogaXBwbUBp ZXRmLm9yZw0KPiBNZXNzYWdlLUlEOiA8UGluZS5MTlguNC41OC4wNDA4MTYxMDQyNTkwLjI3NTky QHg0OS5yaXBlLm5ldD4NCj4gQ29udGVudC1UeXBlOiBURVhUL1BMQUlOOyBjaGFyc2V0PVVTLUFT Q0lJDQo+IA0KPiBJUFBNIGdyb3VwLA0KPiANCj4gU2luY2UgdGhlIElQUE0gV0cgbWVldGluZyBp biBTZW91bCwgdGhlcmUgaGF2ZSBiZWVuIHNldmVyYWwgZGlzY3Vzc2lvbnMNCj4gKGJvdGggcHVi bGljIGFuZCBwcml2YXRlKSBiZXR3ZWVuIEVtaWxlIFN0ZXBoYW4sIEFuZHkgQmllcm1hbiAodGhl IElQUE0NCj4gTUlCIHRlY2huaWNhbCBhZHZpc29yKSwgdGhlIGNoYWlycyBvZiB0aGUgV0cgYW5k IHNldmVyYWwgb3RoZXJzLCBvbiBob3cgdG8NCj4gcHJvY2VlZCB3aXRoIHRoZSBJUFBNIE1JQiBk b2N1bWVudCAoZHJhZnQtaWV0Zi1pcHBtLXJlcG9ydGluZy1taWItMDYudHh0KS4NCj4gVGhpcyBt YWlsIHN1bW1hcml6ZXMgdGhlIGRpc2N1c3Npb25zIGFuZCBwcm9wb3NlcyBhIHdheSBmb3J3YXJk Lg0KPiANCj4gV2UgYWxsIGFncmVlIHRoYXQgZXZlbiB0aG91Z2ggdGhlIGN1cnJlbnQgZHJhZnQg aXMgaW4gaXRzIDZ0aCBpdGVyYXRpb24sDQo+IHRoZXJlIGhhcyBiZWVuIHZlcnkgbGl0dGxlIGZl ZWRiYWNrIGZyb20gdGhlIFdHIG9uIGl0cyBjb250ZW50cy4gIFRoZQ0KPiBjaGFpcnMgZGlkIHJl Y2VpdmUgc29tZSBpbmZvcm1hbCBjb21tZW50cyBvbiB0aGUgZG9jdW1lbnQsIHRoZXNlIGNhbiBi ZQ0KPiBzdW1tYXJpemVkIGFzICJ0aGUgZG9jdW1lbnQgYW5kIE1JQiBhcmUgdG9vIGNvbXBsZXgi Lg0KPiANCj4gQSBwcm9wb3NhbCBoYXMgYmVlbiBtYWRlIHRvIGZvciBhIHNpbXBsZXIgYXBwcm9h Y2gsIGJhc2VkIG9uIGEgcmluZyBidWZmZXINCj4gdG8gc3RvcmUgaW5kaXZpZHVhbCBtZWFzdXJl bWVudHMuICBXaGlsZSB0aGlzIGxvb2tlZCBuaWNlIGluIHRoZW9yeSwgaW4NCj4gcHJhY3RpY2Ug aXQgaXMgcHJvYmFibHkgbm90IHBvc3NpYmxlIHRvIHN0b3JlIGFuZCByZXRyaWV2ZSBpbmRpdmlk dWFsDQo+IG1lYXN1cmVtZW50cyBpbiBhIE1JQiBhdCBhIHJhdGUgb2YgdGhlIG9yZGVyIG9mIDFI eiBvciBtb3JlLiBJbiBvdGhlcg0KPiB3b3JkcywgYSBNSUIgY2FuIG9ubHkgYmUgdXNlZCB0byBy ZXBvcnQgYWdncmVnYXRlIGluZm9ybWF0aW9uLCB3aGVyZSB0aGUNCj4gYWdncmVnYXRpb24gaXMg ZG9uZSBlaXRoZXIgb24gZGVtYW5kIG9yIGJ5IGRlZmF1bHQgYXQgcmVndWxhciBpbnRlcnZhbHMu DQo+IA0KPiBBcyB0aGUgbmV4dCBzdGVwcywgd2UgcHJvcG9zZToNCj4gDQo+IDEuIFRoZSBtYWls aW5nIGxpc3Qgd2lsbCBiZSBhc2tlZCB0byBwcm92aWRlIGZlZWRiYWNrIG9uIHRoZSBxdWVzdGlv bg0KPiAgICB3aGF0IGluZm9ybWF0aW9uIHRoZXkgd291bGQgbGlrZSB0byBzZWUgaW4gdGhlIG1h bmFnZW1lbnQgaW50ZXJmYWNlDQo+ICAgIG9mIGEgbmV0d29yayBtZWFzdXJlbWVudCBzeXN0ZW0u IChTZWUgYmVsb3cpLg0KPiANCj4gMi4gV2hlbiB0aGVyZSBpcyBjb25zZW5zdXMgb24gdGhpcyBx dWVzdGlvbiwgd2Ugd2lsbCBsb29rIGF0IGV4aXN0aW5nDQo+ICAgIE1JQidzIChpbiBwYXJ0aWN1 bGFyIHRoZSBSTU9OTUlCIFRQTS1NSUIpIHRvIHNlZSB3aGF0IGlzDQo+ICAgIGFscmVhZHkgdGhl cmUgdG8gc2F0aXNmeSB0aGUgcmVxdWlyZW1lbnRzIGdlbmVyYXRlZCBpbiB0aGUgcHJldmlvdXMN Cj4gICAgc3RlcCBhbmQgd2hhdCBoYXMgdG8gYmUgZGVmaW5lZCBpbiBvdXIgZ3JvdXAuDQo+IA0K PiAzLiBUaGUgZXhpc3RpbmcgZG9jdW1lbnQgd2lsbCBiZSByZXdyaXR0ZW4gdG8gZGVmaW5lIHdo YXRldmVyIGhhcyB0byBiZQ0KPiAgICBkZWZpbmVkIGFuZCBub3RoaW5nIG1vcmUuDQo+IA0KPiBJ ZiB0aGVyZSBpcyBsaXR0bGUgb3Igbm8gZmVlZGJhY2sgb24gc3RlcCAxLCB3ZSB3aWxsIGNvbmNs dWRlIHRoYXQgdGhlcmUNCj4gaXMgbm8gaW50ZXJlc3QgaW4gYW4gSVBQTSBhdCB0aGUgbW9tZW50 LiAgSW4gdGhhdCBjYXNlLCB0aGUgZXhpc3RpbmcNCj4gZG9jdW1lbnQgd2lsbCBiZSBmaW5pc2hl ZCBhbmQgYSBwdWJsaXNoZWQgYXMgYW4gaW5mb3JtYXRpb25hbCBSRkMuDQo+IA0KPiBUbyBzdGFy dCwgdGhlIGZpcnN0IHF1ZXN0aW9ucyB3ZSB3b3VsZCBsaWtlIHRvIHNlZSBhbnN3ZXJlZCwgYXJl Og0KPiANCj4gKiBXaGF0IGluZm9ybWF0aW9uIHdvdWxkIHlvdSBsaWtlIHRvIHNlZSBpbiBhIG1h bmFnZW1lbnQgaW50ZXJmYWNlIG9mIGENCj4gICBtZWFzdXJlbWVudCBzeXN0ZW0/DQo+ICogV2hh dCBhY3Rpb24gd291bGQgeW91IGxpa2UgdG8gdGFrZSB3aXRoIGEgbWFuYWdlbWVudCBpbnRlcmZh Y2Ugb2YgYQ0KPiAgIG1lYXN1cmVtZW50IHN5c3RlbT8NCj4gKiBEbyB5b3UgaGF2ZSByZXF1ZXN0 cyBmcm9tIHRoZSB1c2VycyBvZiB5b3VyIGltcGxlbWVudGF0aW9uIG9mIHRoZQ0KPiAgIElQUE0g bWV0cmljcyBmb3IgYW4gaW50ZXJmYWNlIGJldHdlZW4gdGhlIG1lYXN1cmVtZW50IHN5c3RlbSBh bmQNCj4gICBhIG5ldHdvcmsgbWFuYWdlbWVudCBzeXN0ZW0gKE5NUyk/DQo+IA0KPiBQbGVhc2Ug bm90ZSB0aGUgY29uc3RyYWludCBtZW50aW9uZWQgYWJvdmUuIEl0IGFsc28gc2hvdWxkIGJlIG5v dGVkIHRoYXQNCj4gc29tZSBvZiB0aGUgSVBQTSBtZXRyaWNzIGltcGxlbWVudGF0aW9ucyBkbyBu b3QgdXNlIGEgTUlCIGJ1dCBkbyByZXBvcnQNCj4gYWdncmVnYXRlZCBpbmZvcm1hdGlvbiBpbiBv dGhlciBmb3JtYXRzIChDU1YsIFhNTCwgZ3JhcGhpY2FsLCAuLi4pICBUaGlzDQo+IGlzIGluZm9y bWF0aW9uIHRoYXQgY291bGQgKHBvdGVudGlhbGx5KSBiZSByZXBvcnRlZCBpbiBhIE1JQiBhcyB3 ZWxsLg0KPiANCj4gV2UgaW52aXRlIGV2ZXJ5Ym9keSB0byBjb21tZW50IG9uIGJvdGggdGhlIHBy b2NlZHVyZSBhbmQgdGhlIHF1ZXN0aW9ucw0KPiBhYm92ZSBiZWZvcmUgU2VwdGVtYmVyIDMwLA0K PiANCj4gSGVuaw0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IEhlbmsgVWlqdGVyd2Fh bCAgICAgICAgICAgICAgICAgICAgICAgICAgIEVtYWlsOiBoZW5rLnVpanRlcndhYWwoYXQpcmlw ZS5uZXQNCj4gUklQRSBOZXR3b3JrIENvb3JkaW5hdGlvbiBDZW50cmUgICAgICAgICAgaHR0cDov L3d3dy5hbXN0ZXJkYW1uZWQub3JnL35oZW5rDQo+IFAuTy5Cb3ggMTAwOTYgICAgICAgICAgU2lu Z2VsIDI1OCAgICAgICAgIFBob25lOiArMzEuMjAuNTM1NDQxNA0KPiAxMDAxIEVCIEFtc3RlcmRh bSAgICAgIDEwMTYgQUIgQW1zdGVyZGFtICBGYXg6ICszMS4yMC41MzU0NDQ1DQo+IFRoZSBOZXRo ZXJsYW5kcyAgICAgICAgVGhlIE5ldGhlcmxhbmRzICAgIE1vYmlsZTogKzMxLjYuNTU4NjE3NDYN Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBQcm9jZXNzIGFuZCBQcm9jZWR1cmUgYXJl IHRoZSBsYXN0IGhpZGluZyBwbGFjZSBvZiBwZW9wbGUgd2l0aG91dCB0aGUgd2l0DQo+IGFuZCB3 aXNkb20gdG8gZG8gdGhlaXIgam9iIHByb3Blcmx5LiAgICAgICAgICAgICAgICAgICAgICAgICAg KERhdmlkIEJyZW50KS4NCj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBpcHBtIG1haWxpbmcgbGlzdA0KPiBpcHBtQGlldGYub3JnIA0KPiBodHRwczovL3d3dzEu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBtDQo+IA0KPiANCj4gRW5kIG9mIGlwcG0gRGln ZXN0LCBWb2wgMywgSXNzdWUgOA0KPiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq --===============1861576417== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm --===============1861576417==--