From ippm-bounces@ietf.org Mon May 01 18:50:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FahDR-0005uV-PN; Mon, 01 May 2006 18:50:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FahDO-0005tm-0T; Mon, 01 May 2006 18:50:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=cypress.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FahDN-0001Ma-NA; Mon, 01 May 2006 18:50:01 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k41Mo10e022776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 May 2006 22:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FahDN-0002GO-AH; Mon, 01 May 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 01 May 2006 18:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: ippm@ietf.org Subject: [ippm] I-D ACTION:draft-ietf-ippm-reordering-13.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: , Errors-To: ippm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : Packet Reordering Metric for IPPM Author(s) : A. Morton, et al. Filename : draft-ietf-ippm-reordering-13.txt Pages : 42 Date : 2006-5-1 This memo defines metrics to evaluate if a network has maintained packet order on a packet-by-packet basis. It provides motivations for the new metrics and discusses the measurement issues, including the context information required for all metrics. The memo first defines a reordered singleton, and then uses it as the basis for sample metrics to quantify the extent of reordering in several useful dimensions for network characterization or receiver design. Additional metrics quantify the frequency of reordering and the distance between separate occurrences. We then define a metric oriented toward assessing reordering effects on TCP. Several examples of evaluation using the various sample metrics are included. An Appendix gives extended definitions for evaluating order with packet fragmentation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-reordering-13.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ippm-reordering-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ippm-reordering-13.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-5-1153417.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-reordering-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-reordering-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-1153417.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm --NextPart-- From ippm-bounces@ietf.org Tue May 02 00:28:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FamUb-0005ut-8S; Tue, 02 May 2006 00:28:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FamUa-0005un-F5 for ippm@ietf.org; Tue, 02 May 2006 00:28:08 -0400 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FamUZ-0005Zo-8P for ippm@ietf.org; Tue, 02 May 2006 00:28:08 -0400 Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id D43CB47CFF for ; Tue, 2 May 2006 00:28:06 -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 18361-08 for ; Tue, 2 May 2006 00:28:06 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 7833547E32 for ; Tue, 2 May 2006 00:28:06 -0400 (EDT) Date: Tue, 02 May 2006 00:28:02 -0400 From: Matthew J Zekauskas To: ippm@ietf.org Message-ID: <28DFBDA048DB44589A5A7DEB@DCFF15AFC1F6764BA3927E50> X-Mailer: Mulberry/4.0.0 (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: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [ippm] IETF Meeting Survey 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: , Errors-To: ippm-bounces@ietf.org Ray Pelletier , the IETF Administrative Director, has asked us to ask you to fill out a short survey that focuses primarily, but not exclusively, on your meeting experience in Dallas (presumably assuming you did attend). The input will be useful in organizing future meetings. If you have a few minutes, the survey is at: --Matt _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue May 02 08:39:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FauA6-0003LS-TE; Tue, 02 May 2006 08:39:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FauA5-0003LN-TR for ippm@ietf.org; Tue, 02 May 2006 08:39:29 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FauA4-0001NY-HK for ippm@ietf.org; Tue, 02 May 2006 08:39:29 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Tue, 2 May 2006 14:39:27 +0200 Received: by S4DE8PSAANS.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 2 May 2006 14:39:27 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED20E631A@S4DE8PSAAFQ.mitte.t-com.de> From: "Geib, Ruediger" To: shalunov@internet2.edu Subject: RE: [ippm] draft-shalunov-ippm-reporting-00.txt - availability Date: Tue, 2 May 2006 14:39:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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: , Errors-To: ippm-bounces@ietf.org Stas, Real time and leased line services are characterised by an "availability". I think availability is a useful and common means to characterise these services. Today, there's only a meausurement principle for IP service availability. There's no commonly implemented IP service availability measurement (RFC2678 on connectivity proposes some metrics which may be useful). The idea is that you define a service availability over time. If the service is available, the metrics you've listed below are applied to characterise the service. If the service is not available, then no further performance characterisation is required. As more real time services start to be migrated to the Internet, measuring IP transport availability may be of interest. Regards, Rudiger Carsten|> * additionally "availability" could be one metric |> (probably with param = (list of) server(s) or network) Stas|Why aren't existing metrics enough? When no packets |come through, you'll see | |delay = +infinity |loss = 100% |jitter = undefined |duplication = 0% |reordering = 0% | |Is that not enough? _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue May 02 09:24:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaurW-0004HL-NO; Tue, 02 May 2006 09:24:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaurV-0004Fc-FG for ippm@ietf.org; Tue, 02 May 2006 09:24:21 -0400 Received: from mail126.messagelabs.com ([216.82.250.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FaurT-000392-0K for ippm@ietf.org; Tue, 02 May 2006 09:24:21 -0400 X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-10.tower-126.messagelabs.com!1146576257!11290285!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 17952 invoked from network); 2 May 2006 13:24:17 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-10.tower-126.messagelabs.com with SMTP; 2 May 2006 13:24:17 -0000 Received: from acmt.att.com (acmt.mt.att.com[135.16.251.35](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20060502132416gw100100kle>; Tue, 2 May 2006 13:24:16 +0000 Message-Id: <6.2.1.2.0.20060502091126.08aeb8d0@postoffice.maillennium.att.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 02 May 2006 09:24:16 -0400 To: "Geib, Ruediger" ,shalunov@internet2.edu From: Al Morton Subject: RE: [ippm] draft-shalunov-ippm-reporting-00.txt - availability In-Reply-To: <6439282641581441A36F7F6F83ED2ED20E631A@S4DE8PSAAFQ.mitte.t -com.de> References: <6439282641581441A36F7F6F83ED2ED20E631A@S4DE8PSAAFQ.mitte.t-com.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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: , Errors-To: ippm-bounces@ietf.org Thanks, Ruediger. Another way to look at this topic: Users experience network performance in at least two states: available or "broken" (unavailable) where typically some sort of failure or misconfiguration cannot be restored automatically and requires human intervention. The tricky part is defining the performance levels that constitute the transitions between the two states, and keep them application-independent for simplicity. Despite the difficulties, Availability is probably one of the most important network metrics, as far as real users are concerned. Al At 08:39 AM 5/2/2006, Geib, Ruediger wrote: >Stas, > >Real time and leased line services are characterised by an "availability". >I think availability is a useful and common means to characterise these >services. Today, there's only a meausurement principle for IP service >availability. There's no commonly implemented IP service availability >measurement (RFC2678 on connectivity proposes some metrics which may be >useful). > >The idea is that you define a service availability over time. If the >service is available, the metrics you've listed below are applied to >characterise the service. If the service is not available, then no further >performance characterisation is required. > >As more real time services start to be migrated to the Internet, measuring >IP transport availability may be of interest. > >Regards, > >Rudiger > > >Carsten|> * additionally "availability" could be one metric >|> (probably with param = (list of) server(s) or network) > >Stas|Why aren't existing metrics enough? When no packets >|come through, you'll see >| >|delay = +infinity >|loss = 100% >|jitter = undefined >|duplication = 0% >|reordering = 0% >| >|Is that not enough? > >_______________________________________________ >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 Tue May 02 09:43:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fav9Q-0004ds-DE; Tue, 02 May 2006 09:42:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fav9P-0004ce-80 for ippm@ietf.org; Tue, 02 May 2006 09:42:51 -0400 Received: from mail126.messagelabs.com ([216.82.250.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fav9O-0004It-Tl for ippm@ietf.org; Tue, 02 May 2006 09:42:51 -0400 X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-6.tower-126.messagelabs.com!1146577368!8897522!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 5907 invoked from network); 2 May 2006 13:42:48 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-6.tower-126.messagelabs.com with SMTP; 2 May 2006 13:42:48 -0000 Received: from acmt.att.com (acmt.mt.att.com[135.16.251.35](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20060502134248gw100100l4e>; Tue, 2 May 2006 13:42:48 +0000 Message-Id: <6.2.1.2.0.20060502093705.08aea138@postoffice.maillennium.att.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 02 May 2006 09:42:48 -0400 To: ippm@ietf.org From: Al Morton Subject: Re: [ippm] I-D ACTION:draft-ietf-ippm-reordering-13.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: 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: , Errors-To: ippm-bounces@ietf.org IPPM, This is an opportunity to see how we've addressed the IESG's comments. With the possible exceptions of adding some new metric names (as discussed on the list last week) and a new "Disclaimer" section, I think it's fair to characterize all the comments and resolutions as clarifications to the text. One typo: RFC2640 should be RFC2460. Diffs can be viewed at the tools pages: http://tools.ietf.org/wg/ippm/draft-ietf-ippm-reordering/ Al At 06:50 PM 5/1/2006, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the IP Performance Metrics Working Group of >the IETF. > > Title : Packet Reordering Metric for IPPM > Author(s) : A. Morton, et al. > Filename : draft-ietf-ippm-reordering-13.txt > Pages : 42 > Date : 2006-5-1 > >This memo defines metrics to evaluate if a network has maintained > packet order on a packet-by-packet basis. It provides motivations > for the new metrics and discusses the measurement issues, including > the context information required for all metrics. The memo first > defines a reordered singleton, and then uses it as the basis for > sample metrics to quantify the extent of reordering in several > useful dimensions for network characterization or receiver design. > Additional metrics quantify the frequency of reordering and the > distance between separate occurrences. We then define a metric > oriented toward assessing reordering effects on TCP. Several > examples of evaluation using the various sample metrics are > included. An Appendix gives extended definitions for evaluating > order with packet fragmentation. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ippm-reordering-13.txt _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue May 02 09:53:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FavJP-0007A6-1V; Tue, 02 May 2006 09:53:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FavJN-0007A1-V7 for ippm@ietf.org; Tue, 02 May 2006 09:53:09 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FavJN-0004vC-IA for ippm@ietf.org; Tue, 02 May 2006 09:53:09 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Tue, 2 May 2006 15:53:04 +0200 Received: by S4DE8PSAANS.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 2 May 2006 15:53:04 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED20E631D@S4DE8PSAAFQ.mitte.t-com.de> From: "Geib, Ruediger" To: acmorton@att.com Subject: RE: [ippm] draft-shalunov-ippm-reporting-00.txt - availability Date: Tue, 2 May 2006 15:53:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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: , Errors-To: ippm-bounces@ietf.org Hi Al, |Users experience network performance in at least two states: |available or "broken" (unavailable) where typically some |sort of failure or misconfiguration cannot be restored automatically |and requires human intervention. | |The tricky part is defining the performance levels that |constitute the transitions between the two states, |and keep them application-independent for simplicity. Exactly. |Despite the difficulties, Availability is probably one of |the most important network metrics, as far as real users |are concerned. Yes, it is part of many product descriptions and SLAs. Regards, Rudiger |At 08:39 AM 5/2/2006, Geib, Ruediger wrote: |>Stas, |> |>Real time and leased line services are characterised by an |>"availability". I think availability is a useful and common |>means to characterise these services. Today, there's only a |>meausurement principle for IP service availability. There's |>no commonly implemented IP service availability measurement |>(RFC2678 on connectivity proposes some metrics which may be |>useful). |> |>The idea is that you define a service availability over time. If the |>service is available, the metrics you've listed below are applied to |>characterise the service. If the service is not available, |>then no further performance characterisation is required. |> |>As more real time services start to be migrated to the |>Internet, measuring IP transport availability may be of interest. |> |>Regards, |> |>Rudiger |> |> |>Carsten|> * additionally "availability" could be one metric |>|> (probably with param = (list of) server(s) or network) |> |>Stas|Why aren't existing metrics enough? When no packets |>|come through, you'll see |>| |>|delay = +infinity |>|loss = 100% |>|jitter = undefined |>|duplication = 0% |>|reordering = 0% |>| |>|Is that not enough? |> |>_______________________________________________ |>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 | _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue May 02 10:26:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Favpy-0007EN-D6; Tue, 02 May 2006 10:26:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Favpw-00077b-GF for ippm@ietf.org; Tue, 02 May 2006 10:26:48 -0400 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Favpv-0005zp-6g for ippm@ietf.org; Tue, 02 May 2006 10:26:48 -0400 Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id C30C247D74; Tue, 2 May 2006 10:26:46 -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 03330-06; Tue, 2 May 2006 10:26:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 545EE47D85; Tue, 2 May 2006 10:26:46 -0400 (EDT) To: Ruediger.Geib@t-systems.com, Al Morton Subject: Re: [ippm] draft-shalunov-ippm-reporting-00.txt - availability References: <6439282641581441A36F7F6F83ED2ED20E631A@S4DE8PSAAFQ.mitte.t-com.de> From: stanislav shalunov Date: 02 May 2006 10:26:47 -0400 In-Reply-To: <6439282641581441A36F7F6F83ED2ED20E631A@S4DE8PSAAFQ.mitte.t-com.de> Message-ID: <86slnsy02g.fsf@abel.internet2.edu> Lines: 52 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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: , Errors-To: ippm-bounces@ietf.org "Geib, Ruediger" writes: > Real time and leased line services are characterised by an > "availability". I think availability is a useful and common means to > characterise these services. Today, there's only a meausurement > principle for IP service availability. There's no commonly > implemented IP service availability measurement (RFC2678 on > connectivity proposes some metrics which may be useful). I believe that, should we want to report availability, we could replace the normal report with ``network unavailable'' or some such phrase if no packets get through. This is consistent with RFC2678 (the second metric, Type-P-Interval-Unidirectional-Connectivity and Type-P-Interval-Bidirectional-Connectivity). Would that work for you? (I'm still not convinced we should put it in, but if we do, that would probably be my preferred way of treating it. What does everyone else think? Is a separate availability metric needed when delay, loss, etc., are already there?) Also, should we call it ``connectivity'' to be consistent with RFC2678? Or is there a reason to say ``availability''? Al Morton writes: > Users experience network performance in at least two states: > available or "broken" (unavailable) where typically some > sort of failure or misconfiguration cannot be restored automatically > and requires human intervention. > > The tricky part is defining the performance levels that > constitute the transitions between the two states, > and keep them application-independent for simplicity. > Despite the difficulties, Availability is probably one of > the most important network metrics, as far as real users > are concerned. I'd prefer to just report the numbers as much as possible. I guess it's a bit like any other kind of dashboard design. Suppose you're designing a dial that shows speed of a vehicle. Should the speedometer display (or point to) zero when the vehicle isn't moving? Or should it change to something else entirely? As a user, I actually prefer the zero for consistency. Popping up a sign ``stopped'' over the speedometer isn't helpful to me. Opinions can legitimately differ on that one, though. But if it popped up the sign at 5 MPH, I would be very irritated: it precludes some usage scenarios just because the designer thought them unlikely... -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ Just my 0.086g of Ag. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue May 02 10:52:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FawEV-0007BO-Gi; Tue, 02 May 2006 10:52:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FawET-0007BJ-NR for ippm@ietf.org; Tue, 02 May 2006 10:52:09 -0400 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FawES-0006zm-Af for ippm@ietf.org; Tue, 02 May 2006 10:52:09 -0400 Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id k42Eq2n27570; Tue, 2 May 2006 16:52:03 +0200 (MEST) 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="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [ippm] draft-shalunov-ippm-reporting-00.txt - availability Date: Tue, 2 May 2006 16:52:04 +0200 Message-ID: <70524A4436C03E43A293958B505008B61B9FAF@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ippm] draft-shalunov-ippm-reporting-00.txt - availability Thread-Index: AcZt9KqlToej2VkNSZCbLvXPAgjUHwAARLJA From: "Schmoll, Carsten" To: "stanislav shalunov" , , "Al Morton" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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: , Errors-To: ippm-bounces@ietf.org > Would that work for you? (I'm still not convinced we should put it > in, but if we do, that would probably be my preferred way of treating > it. What does everyone else think? Is a separate availability metric > needed when delay, loss, etc., are already there?) Technically there is not much of a difference between "delay to X < inf" and "connectivity with X exists" I would suggest to talk about *connectivity*, since *availability* to my ears sounds much like 'service availability' which is an application-level metric, and on this level there is no clear relation like the above. Still I think connectivity deserves an extra report entry, since it might be "FALSE" for different reasons which cannot be derived from delay etc. For a user the reasons are of interest. Think about connectivity *to the Internet* as a desired metric; this can be FALSE due to a lot of things, e.g. the 1st L2 link being down, DHCP, DNS, routing, firewall, or gateway failure. Could the metric "connectivity to the Internet" be something more than binary and could it give a user a value stating either "OK", or some value indicating ''how far'' connectivity is from being OK? If connectivity is just a binary metric then I think it could be derived from the other reported metrics (if we just talk about Layer3 connectivity) as long as the destination parameter is the same. What do you think about a finer granularity for connectivity? With best regards, Carsten. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue May 02 12:17:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaxYM-0002xv-Kh; Tue, 02 May 2006 12:16:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaxYL-0002to-PB for ippm@ietf.org; Tue, 02 May 2006 12:16:45 -0400 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaxYK-0002BI-Eu for ippm@ietf.org; Tue, 02 May 2006 12:16:45 -0400 Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id E4C2947DF0; Tue, 2 May 2006 12:16:43 -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 23533-10; Tue, 2 May 2006 12:16:43 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 4DF7247D8C; Tue, 2 May 2006 12:16:43 -0400 (EDT) To: "Schmoll, Carsten" Subject: Re: [ippm] draft-shalunov-ippm-reporting-00.txt - availability References: <70524A4436C03E43A293958B505008B61B9FAF@EXCHSRV.fokus.fraunhofer.de> From: stanislav shalunov Date: 02 May 2006 12:16:43 -0400 In-Reply-To: <70524A4436C03E43A293958B505008B61B9FAF@EXCHSRV.fokus.fraunhofer.de> Message-ID: <86bqugxuz8.fsf@abel.internet2.edu> Lines: 67 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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: , Errors-To: ippm-bounces@ietf.org "Schmoll, Carsten" writes: > Technically there is not much of a difference between > "delay to X < inf" and "connectivity with X exists" With current definitions, delay < +infinity is equivalent to loss < 50% The only connectivity metric I see as compatible with the connectivity RFC is loss < 100%. How could we square loss < 50% with RFC2678? > I would suggest to talk about *connectivity*, since *availability* > to my ears sounds much like 'service availability' which is an > application-level metric, and on this level there is no clear > relation like the above. ``Connectivity'' is consistent with RFC2678, so, if there are no arguments against it, it should probably be the default. > Still I think connectivity deserves an extra report entry, > since it might be "FALSE" for different reasons which cannot > be derived from delay etc. For a user the reasons are of interest. I don't understand. If, as you seem to be proposing, we make ``no connectivity'' == ``delay < +infinity'', it's derived from delay. If we make it ``loss < 100%'', it's derived from loss. When would connectivity *not* be derived from the five metrics already in there? > Think about connectivity *to the Internet* as a desired metric; Any measurement is tied to specific endpoints. I don't expect connectivity to the Internet can be meaningfully defined in a way that will endure. > this can be FALSE due to a lot of things, e.g. > the 1st L2 link being down, DHCP, DNS, routing, firewall, or > gateway failure. > > Could the metric "connectivity to the Internet" be something more > than binary and could it give a user a value stating either > "OK", or some value indicating ''how far'' connectivity is from being > OK? Such a metric would essentially require an entire troubleshooting algorithm. This is way beyond the very limited summarization of measurement results I'm trying to do with this draft... > If connectivity is just a binary metric then I think it could be > derived from the other reported metrics (if we just talk about > Layer3 connectivity) as long as the destination parameter is the > same. Is there any need to report it separately, then? The argument against doing so is: Presence of derivative metrics enlarges the set of metrics needlessly and violates metric orthogonality. > What do you think about a finer granularity for connectivity? I think if it's defined, it should be a separate effort. (It would probably also be a larger effort than anything IPPM has done so far...) -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ Al your Qaeda are belong to US. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue May 02 12:51:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fay5V-0002HI-5w; Tue, 02 May 2006 12:51:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fay5T-0002HD-Ua for ippm@ietf.org; Tue, 02 May 2006 12:50:59 -0400 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fay5R-0003s4-HE for ippm@ietf.org; Tue, 02 May 2006 12:50:59 -0400 Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id k42Goun25250; Tue, 2 May 2006 18:50:56 +0200 (MEST) 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="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [ippm] draft-shalunov-ippm-reporting-00.txt - availability Date: Tue, 2 May 2006 18:50:57 +0200 Message-ID: <70524A4436C03E43A293958B505008B61B9FBC@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ippm] draft-shalunov-ippm-reporting-00.txt - availability Thread-Index: AcZuA91P8sW9Sh1TS+OP4KwoDDmWRAAAlyBQ From: "Schmoll, Carsten" To: "stanislav shalunov" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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: , Errors-To: ippm-bounces@ietf.org Please see comments inline.=20 > -----Original Message----- > From: stanislav shalunov [mailto:shalunov@internet2.edu]=20 > Sent: Tuesday, May 02, 2006 6:17 PM > Subject: Re: [ippm] draft-shalunov-ippm-reporting-00.txt -=20 > availability >=20 > "Schmoll, Carsten" writes: >=20 > > Technically there is not much of a difference between > > "delay to X < inf" and "connectivity with X exists" >=20 > With current definitions, >=20 > delay < +infinity is equivalent to loss < 50% Yes, you're right. I overlooked that detail. > When would > connectivity *not* be derived from the five metrics already in there? If we consider connectivitiy on the IP level only, then I cannot think of any case. Sill, some text in the draft=20 about how to derive "connectivity" would still be helpful,=20 since e.g. a fine delay+loss value for one direction only would=20 not be enough to imply in general that connectivity =3D TRUE. > Such a metric would essentially require an entire troubleshooting > algorithm. This is way beyond the very limited summarization of > measurement results I'm trying to do with this draft... I agree, as much as I'd like to see work on such topic, it is clearly beyond the scope of your draft. Regards, Carsten. PS - there is one general question to the draft I have: Do you consider also reporting for *which* traffic the=20 metrics have been measured (e.g. for UDP only, for DSCP=3D3)? _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue May 02 14:58:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb04x-0005aT-Vm; Tue, 02 May 2006 14:58:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb04w-0005aO-Pc for ippm@ietf.org; Tue, 02 May 2006 14:58:34 -0400 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb04u-0001Os-Fq for ippm@ietf.org; Tue, 02 May 2006 14:58:34 -0400 Received: by postman.ripe.net (Postfix, from userid 4008) id 8763F23F13; Tue, 2 May 2006 20:58:31 +0200 (CEST) Received: from herring.ripe.net (herring.ripe.net [193.0.1.203]) by postman.ripe.net (Postfix) with ESMTP id 63E8123F00; Tue, 2 May 2006 20:58:31 +0200 (CEST) Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239]) by herring.ripe.net (Postfix) with ESMTP id 13AB12F583; Tue, 2 May 2006 20:58:30 +0200 (CEST) Message-Id: <7.0.1.0.2.20060502172914.034d4e78@ripe.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 02 May 2006 17:37:19 +0200 To: "Geib, Ruediger" , acmorton@att.com From: Henk Uijterwaal Subject: RE: [ippm] draft-shalunov-ippm-reporting-00.txt - availability In-Reply-To: <6439282641581441A36F7F6F83ED2ED20E631D@S4DE8PSAAFQ.mitte.t -com.de> References: <6439282641581441A36F7F6F83ED2ED20E631D@S4DE8PSAAFQ.mitte.t-com.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RIPE-Spam-Level: X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00,DATE_IN_PAST_03_06 X-RIPE-Spam-Status: N 0.000014 / -3.9 X-RIPE-Signature: ec36b56d8975cdc6e1272e4149f956b4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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: , Errors-To: ippm-bounces@ietf.org Al, Ruediger, >|Despite the difficulties, Availability is probably one of >|the most important network metrics, as far as real users >|are concerned. > >Yes, it is part of many product descriptions and SLAs. But don't they (implicitly) define "available" as some mixture of a number of parameters all being below some threshold? Isn't it sufficient to report the numbers, then leave the math to the application? 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 ------------------------------------------------------------------------------ 1160438400. Watch this space... _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue May 02 15:28:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb0YB-0001XY-UG; Tue, 02 May 2006 15:28:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb0YA-0001VB-Ok for ippm@ietf.org; Tue, 02 May 2006 15:28:46 -0400 Received: from panorama.covad.com ([66.134.72.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb0Y9-0002cM-An for ippm@ietf.org; Tue, 02 May 2006 15:28:46 -0400 Received: from zanxmb00a.cc-ntd1.covad.com (zanxmb00a.corp.covad.com [172.16.2.75]) by panorama.Covad.COM (8.9.3/8.8.7) with ESMTP id MAA06429; Tue, 2 May 2006 12:28:44 -0700 (PDT) Received: from ZANEVS03.cc-ntd1.covad.com ([172.16.2.84]) by zanxmb00a.cc-ntd1.covad.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 12:27:17 -0700 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="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [ippm] draft-shalunov-ippm-reporting-00.txt - availability Date: Tue, 2 May 2006 12:28:00 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ippm] draft-shalunov-ippm-reporting-00.txt - availability Thread-Index: AcZuA+yDBe8JyXGdSPyOtKUDEEPJrQADiruA From: "Fardid, Reza" To: "stanislav shalunov" , "Schmoll, Carsten" X-OriginalArrivalTime: 02 May 2006 19:27:17.0800 (UTC) FILETIME=[6CAD2A80:01C66E1E] X-Immunity-Tally: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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: , Errors-To: ippm-bounces@ietf.org Carsten, Stanislav, ITU-T Y.1540 has defined "loss ratio > X%" as its IP service availability metric, with X being service-specific, per Y.1541. I think deriving connecitivity from one or more IPPM metrics will leave gaps that you identified. However, service availability lends itself to a less ambiguous defintion based on one metric, if we cross-reference the above. Regards, Reza=20 -----Original Message----- From: stanislav shalunov [mailto:shalunov@internet2.edu]=20 Sent: Tuesday, May 02, 2006 9:17 AM To: Schmoll, Carsten Cc: ippm@ietf.org Subject: Re: [ippm] draft-shalunov-ippm-reporting-00.txt - availability "Schmoll, Carsten" writes: > Technically there is not much of a difference between > "delay to X < inf" and "connectivity with X exists" With current definitions, delay < +infinity is equivalent to loss < 50% The only connectivity metric I see as compatible with the connectivity RFC is loss < 100%. How could we square loss < 50% with RFC2678? > I would suggest to talk about *connectivity*, since *availability* > to my ears sounds much like 'service availability' which is an > application-level metric, and on this level there is no clear > relation like the above. ``Connectivity'' is consistent with RFC2678, so, if there are no arguments against it, it should probably be the default. > Still I think connectivity deserves an extra report entry, > since it might be "FALSE" for different reasons which cannot > be derived from delay etc. For a user the reasons are of interest. I don't understand. If, as you seem to be proposing, we make ``no connectivity'' =3D=3D ``delay < +infinity'', it's derived from delay. = If we make it ``loss < 100%'', it's derived from loss. When would connectivity *not* be derived from the five metrics already in there? > Think about connectivity *to the Internet* as a desired metric; Any measurement is tied to specific endpoints. I don't expect connectivity to the Internet can be meaningfully defined in a way that will endure. > this can be FALSE due to a lot of things, e.g. > the 1st L2 link being down, DHCP, DNS, routing, firewall, or > gateway failure. >=20 > Could the metric "connectivity to the Internet" be something more > than binary and could it give a user a value stating either > "OK", or some value indicating ''how far'' connectivity is from being > OK? Such a metric would essentially require an entire troubleshooting algorithm. This is way beyond the very limited summarization of measurement results I'm trying to do with this draft... > If connectivity is just a binary metric then I think it could be > derived from the other reported metrics (if we just talk about > Layer3 connectivity) as long as the destination parameter is the > same. Is there any need to report it separately, then? The argument against doing so is: Presence of derivative metrics enlarges the set of metrics needlessly and violates metric orthogonality. > What do you think about a finer granularity for connectivity? I think if it's defined, it should be a separate effort. (It would probably also be a larger effort than anything IPPM has done so far...) --=20 Stanislav Shalunov http://www.internet2.edu/~shalunov/ Al your Qaeda are belong to US. _______________________________________________ ippm mailing list ippm@ietf.org=20 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 Tue May 02 15:36:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb0fp-0002FB-Nm; Tue, 02 May 2006 15:36:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb0fo-0002F6-DW for ippm@ietf.org; Tue, 02 May 2006 15:36:40 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fb0fn-00031m-3K for ippm@ietf.org; Tue, 02 May 2006 15:36:40 -0400 X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-6.tower-121.messagelabs.com!1146598598!7745368!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 20221 invoked from network); 2 May 2006 19:36:38 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-6.tower-121.messagelabs.com with SMTP; 2 May 2006 19:36:38 -0000 Received: from acmt.att.com (acmt.mt.att.com[135.16.251.35](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20060502193638gw100100q3e>; Tue, 2 May 2006 19:36:38 +0000 Message-Id: <6.2.1.2.0.20060502150926.08bf9a00@postoffice.maillennium.att.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 02 May 2006 15:36:37 -0400 To: Henk Uijterwaal , "Geib, Ruediger" From: Al Morton Subject: RE: [ippm] draft-shalunov-ippm-reporting-00.txt - availability In-Reply-To: <7.0.1.0.2.20060502172914.034d4e78@ripe.net> References: <6439282641581441A36F7F6F83ED2ED20E631D@S4DE8PSAAFQ.mitte.t-com.de> <7.0.1.0.2.20060502172914.034d4e78@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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: , Errors-To: ippm-bounces@ietf.org At 11:37 AM 5/2/2006, Henk Uijterwaal wrote: >>|Despite the difficulties, Availability is probably one of >>|the most important network metrics, as far as real users >>|are concerned. >> >>Yes, it is part of many product descriptions and SLAs. > >But don't they (implicitly) define "available" as some mixture of a >number of parameters all being below some threshold? Isn't it sufficient >to report the numbers, then leave the math to the application? Henk, In my experience, they explicitly define availability as a threshold on loss (and that makes it a difficult topic for us in IPPM to take-up -- defining good/bad is out-of-scope). But they also define much more: + the length of the time window of evaluation + whether the window is sliding or fixed + how many packets must be sent in each window for valid decision + other conditions that affect the reliability of the testing and many of these details could be standardized. One of the reasons to define two-states like this is to distinguish time intervals with failures from "normal" performance when preparing long-term summaries. Then users know how much time their A-to-B avail/connect-ability was present (say 99.9% of time) and what the overall loss performance was during the fraction of time they could use their service (they don't particularly care about performance while the service was broken, or to have that performance affect the long-term report). just my 2 cents, Al _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue May 02 16:08:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb1AD-0002F7-8b; Tue, 02 May 2006 16:08:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb1AC-0002Ey-69 for ippm@ietf.org; Tue, 02 May 2006 16:08:04 -0400 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb1AB-0005U6-Uh for ippm@ietf.org; Tue, 02 May 2006 16:08:04 -0400 Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id AAD2647D90; Tue, 2 May 2006 16:08:03 -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 05467-09; Tue, 2 May 2006 16:08:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 5902E47D46; Tue, 2 May 2006 16:08:03 -0400 (EDT) To: "Schmoll, Carsten" Subject: Re: [ippm] draft-shalunov-ippm-reporting-00.txt - availability References: <70524A4436C03E43A293958B505008B61B9FBC@EXCHSRV.fokus.fraunhofer.de> From: stanislav shalunov Date: 02 May 2006 16:08:02 -0400 In-Reply-To: <70524A4436C03E43A293958B505008B61B9FBC@EXCHSRV.fokus.fraunhofer.de> Message-ID: <867j54w5p9.fsf@abel.internet2.edu> Lines: 29 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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: , Errors-To: ippm-bounces@ietf.org "Schmoll, Carsten" writes: > If we consider connectivitiy on the IP level only, > then I cannot think of any case. Sill, some text in the draft > about how to derive "connectivity" would still be helpful, > since e.g. a fine delay+loss value for one direction only would > not be enough to imply in general that connectivity = TRUE. The connectivity RFC defines both unidirectional and bidirectional connectivity. The draft is also applicable to unidirectional and bidirectional (or even passive) measurements. There might be scope somewhere for conversion of unidirectional measurements into bidirectional ones (e.g., delay <- delay1 + delay2, loss <- 1 - (1-loss1)*(1-loss2), connectivity <- connectivity1 AND connectivity2), but it's not clear why these things should go into a user reporting draft... > PS - there is one general question to the draft I have: > Do you consider also reporting for *which* traffic the > metrics have been measured (e.g. for UDP only, for DSCP=3)? Yes, it should report that in some concise (and unspecified) format. I'll add some text to that effect. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ Clothes make the man. Naked people have little or no influence on society. -- Mark Twain _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue May 02 16:23:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb1Om-0006by-4a; Tue, 02 May 2006 16:23:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb1Ol-0006XL-47 for ippm@ietf.org; Tue, 02 May 2006 16:23:07 -0400 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb1Oj-0005zB-Rs for ippm@ietf.org; Tue, 02 May 2006 16:23:07 -0400 Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 9877747D46; Tue, 2 May 2006 16:23:05 -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 07859-07; Tue, 2 May 2006 16:23:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 4C46A47D2A; Tue, 2 May 2006 16:23:05 -0400 (EDT) To: Al Morton Subject: Re: [ippm] draft-shalunov-ippm-reporting-00.txt - availability References: <6439282641581441A36F7F6F83ED2ED20E631D@S4DE8PSAAFQ.mitte.t-com.de> <7.0.1.0.2.20060502172914.034d4e78@ripe.net> <6.2.1.2.0.20060502150926.08bf9a00@postoffice.maillennium.att.com> From: stanislav shalunov Date: 02 May 2006 16:23:04 -0400 In-Reply-To: <6.2.1.2.0.20060502150926.08bf9a00@postoffice.maillennium.att.com> Message-ID: <86wtd4uqfr.fsf@abel.internet2.edu> Lines: 35 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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: , Errors-To: ippm-bounces@ietf.org Al Morton writes: > + the length of the time window of evaluation > > + whether the window is sliding or fixed > > + how many packets must be sent in each window for valid decision > > + other conditions that affect the reliability of the testing These things have nothing specific for availability/connectivity metric. The draft attempts to set the default values for all relevant parameters. Please point out the gaps so I can fill them. > One of the reasons to define two-states like this is to distinguish > time intervals with failures from "normal" performance when preparing > long-term summaries. Then users know how much time their A-to-B > avail/connect-ability was present (say 99.9% of time) and what the > overall loss performance was during the fraction of time they could > use their service (they don't particularly care about performance while > the service was broken, or to have that performance affect the long-term > report). With a default measurement interval duration of 10 seconds, the metrics the draft discusses are hardly long-term. Description of long-term network properties is interesting, too, but let's take it one step at a time: first define how to turn a 100-packet sample into human-readable measurements, then take it from there... -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed at sea level. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue May 02 16:31:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb1Wj-0007u8-VT; Tue, 02 May 2006 16:31:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb1Wi-0007pi-Sk; Tue, 02 May 2006 16:31:20 -0400 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb1Wh-0006aD-LF; Tue, 02 May 2006 16:31:20 -0400 Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 641FE47D8D; Tue, 2 May 2006 16:31:19 -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 09326-05; Tue, 2 May 2006 16:31:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 2519E47C6E; Tue, 2 May 2006 16:31:19 -0400 (EDT) To: Internet-Drafts Administrator From: stanislav shalunov Date: 02 May 2006 16:31:17 -0400 Message-ID: <86k694uq22.fsf@abel.internet2.edu> Lines: 22 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ippm@ietf.org Subject: [ippm] draft-shalunov-ippm-reporting-03.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: , Errors-To: ippm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Please publish http://www.internet2.edu/~shalunov/ippm/draft-shalunov-ippm-reporting-03.txt (SHA1 = 8754416943960c5dfde49cced953eecbc6ac75fd) as an internet-draft. - -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ WARNING: It is a US federal crime to annoy me anonymously over the Internet. (47 U.S.C. 223(a)(1)(C), amended by Sec. 113 H.R.3402, in effect 2006-01-05.) -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQCVAwUBRFfBfJRUn1EgN49xAQER8AP+IzNV5thzwBnxJQsvMwGWiWkrvVWgzNbz ElA9eC2oeGGZwoQWA2Mq8goDid2eZi3oN/V3YWOSMk2eEBt2RG/tdYOji8b5pYyF dbwxYjToiRl3dxvoIpSLqXUeckGhJEmfXmSFlqX5U9qkhubtsgZvLpUSdCTBiAIh rtmNOjgomwc= =a2XI -----END PGP SIGNATURE----- _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue May 02 16:54:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb1tE-000514-IA; Tue, 02 May 2006 16:54:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb1tC-0004sR-PT for ippm@ietf.org; Tue, 02 May 2006 16:54:34 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb18L-0005Nh-MR for ippm@ietf.org; Tue, 02 May 2006 16:06:09 -0400 Received: from basie.internet2.edu ([207.75.164.22]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fb12R-00051X-IQ for ippm@ietf.org; Tue, 02 May 2006 16:00:07 -0400 Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id C59EC47D31; Tue, 2 May 2006 16:00:02 -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 03778-04; Tue, 2 May 2006 16:00:02 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 89B5B47D0E; Tue, 2 May 2006 16:00:02 -0400 (EDT) To: "Fardid, Reza" Subject: Re: [ippm] draft-shalunov-ippm-reporting-00.txt - availability References: From: stanislav shalunov Date: 02 May 2006 16:00:01 -0400 In-Reply-To: Message-ID: <86bqugw62m.fsf@abel.internet2.edu> Lines: 16 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Score: -2.6 (--) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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: , Errors-To: ippm-bounces@ietf.org "Fardid, Reza" writes: > ITU-T Y.1540 has defined "loss ratio > X%" as its IP service > availability metric, with X being service-specific, per Y.1541. That's good to know, but we probably shouldn't replicate it as suitability of networks with given measurements for given purposes is outside of scope of IPPM (in my understanding, anyway). The existing IPPM connectivity metric has no specific percentages (well, other than 0 or 100%). -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed with 0.06479891g of NaCl. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed May 03 02:57:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbBIP-0003km-KE; Wed, 03 May 2006 02:57:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbBIN-0003ke-3a for ippm@ietf.org; Wed, 03 May 2006 02:57:11 -0400 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbBIJ-0007bF-MT for ippm@ietf.org; Wed, 03 May 2006 02:57:11 -0400 Received: by postman.ripe.net (Postfix, from userid 4008) id 1920E240F1; Wed, 3 May 2006 08:57:07 +0200 (CEST) Received: from herring.ripe.net (herring.ripe.net [193.0.1.203]) by postman.ripe.net (Postfix) with ESMTP id E0264240F0; Wed, 3 May 2006 08:57:06 +0200 (CEST) Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239]) by herring.ripe.net (Postfix) with ESMTP id 593E52F59F; Wed, 3 May 2006 08:57:06 +0200 (CEST) Message-Id: <7.0.1.0.2.20060503080247.034f4e98@ripe.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 03 May 2006 08:19:44 +0200 To: Al Morton , "Geib, Ruediger" From: Henk Uijterwaal Subject: RE: [ippm] draft-shalunov-ippm-reporting-00.txt - availability In-Reply-To: <6.2.1.2.0.20060502150926.08bf9a00@postoffice.maillennium.a tt.com> References: <6439282641581441A36F7F6F83ED2ED20E631D@S4DE8PSAAFQ.mitte.t-com.de> <7.0.1.0.2.20060502172914.034d4e78@ripe.net> <6.2.1.2.0.20060502150926.08bf9a00@postoffice.maillennium.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RIPE-Spam-Level: X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000000 / -4.4 X-RIPE-Signature: 569126eae2e0bd2cb87b4bd154b16bde X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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: , Errors-To: ippm-bounces@ietf.org Al, >In my experience, they explicitly define availability as a >threshold on loss (and that makes it a difficult topic for >us in IPPM to take-up -- defining good/bad is out-of-scope). OK, this is a specific case of "some set of parameters all being below a certain value". >But they also define much more: > >+ the length of the time window of evaluation >+ whether the window is sliding or fixed Isn't this setting "good or bad"? >+ how many packets must be sent in each window for valid decision That is a valid question and probably something to include in the draft. (If N out of M packets arrive, how confident can I be that the loss is below X%.) Any statistician on the list who can provide text? >+ other conditions that affect the reliability of the testing I think it'd be good to list them (and even throw out the ones that are not relevant). >One of the reasons to define two-states like this is to distinguish >time intervals with failures from "normal" performance when preparing >long-term summaries. I agree with all of this, but I still don't see why availability has to be in this draft. If we send X packets/unit of time and report loss, then the user can do the math for his version of availability himself using the algorithm he likes. 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 ------------------------------------------------------------------------------ 1160438400. Watch this space... _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed May 03 03:37:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbBua-0001Is-Ut; Wed, 03 May 2006 03:36:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbBuZ-0001IB-QP for ippm@ietf.org; Wed, 03 May 2006 03:36:39 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbBuZ-0001ER-Dk for ippm@ietf.org; Wed, 03 May 2006 03:36:39 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Wed, 3 May 2006 09:36:36 +0200 Received: by S4DE8PSAANS.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 3 May 2006 09:36:36 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED20E631F@S4DE8PSAAFQ.mitte.t-com.de> From: "Geib, Ruediger" To: henk@ripe.net Subject: RE: [ippm] draft-shalunov-ippm-reporting-00.txt - availability Date: Wed, 3 May 2006 09:36:33 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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: , Errors-To: ippm-bounces@ietf.org Henk, |>But they also define much more: |> |>+ the length of the time window of evaluation |>+ whether the window is sliding or fixed | |Isn't this setting "good or bad"? Yes, it says connectivity there/not there. [snip] |>+ how many packets must be sent in each window for valid decision | |That is a valid question and probably something to include in the |draft. (If N out of M packets arrive, how confident can I be that |the loss is below X%.) Any statistician on the list who can |provide text? This may be done service specific: if a user/application recognises a service as being "not connected/available" if he misses connectivity for a time of delta T, then this is the interval we look at. Then a loss rate must be defined, which would result in the "impression". A statistician may be of little help. This issue is the tricky part of any availability definition. One solution may be to describe how it is done and leave details to those applying the connectivity metric. [snip] |>One of the reasons to define two-states like this is to distinguish |>time intervals with failures from "normal" performance when preparing |>long-term summaries. | |I agree with all of this, but I still don't see why availability |has to be in this draft. If we send X packets/unit of time and |report loss, then the user can do the math for his version of |availability himself using the algorithm he likes. Please get more precise. If your statement covers the following example, I'm with you. My point would be that a report may cover a long interval and not every user may be interested in collecting raw data to do his own "connectivity" evaluation: Reporting Intervall: 15 min (900 sec) Measurement Intervall: 1 sec between probe packets Availability definition: 10 consecutive packets lost make any such ten second interval unavailable Other parameters reported: loss rate, delay etc. As an example, 20 packets may have been lost during one reporting interval, out of these 20 some 18 packets were lost in sequence. Service available: 882 sec Service not available: 18 sec Packet loss rate: 2/882 It is not possible to deduce this information from a 15 Minute report which only tells you: Packet loss rate: 20/900. The draft should allow for a reporting of "connectivity". Regards, Rudiger _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed May 03 03:40:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbBxx-00049Y-Be; Wed, 03 May 2006 03:40:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbBxv-000493-Pl for ippm@ietf.org; Wed, 03 May 2006 03:40:07 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbBxu-0001KB-Dg for ippm@ietf.org; Wed, 03 May 2006 03:40:07 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Wed, 3 May 2006 09:40:04 +0200 Received: by S4DE8PSAANS.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 3 May 2006 09:40:04 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED20E6320@S4DE8PSAAFQ.mitte.t-com.de> From: "Geib, Ruediger" To: shalunov@internet2.edu Subject: RE: [ippm] draft-shalunov-ippm-reporting-00.txt - availability Date: Wed, 3 May 2006 09:39:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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: , Errors-To: ippm-bounces@ietf.org Stas, I've added an example with my last response to Henk, hopefully clarifying the long term / ten second issue you raise here. Regards, Rudiger [snip] |> One of the reasons to define two-states like this is to distinguish |> time intervals with failures from "normal" performance when preparing |> long-term summaries. Then users know how much time their A-to-B |> avail/connect-ability was present (say 99.9% of time) and what the |> overall loss performance was during the fraction of time they could |> use their service (they don't particularly care about |> performance while the service was broken, or to have that |> performance affect the long-term report). | |With a default measurement interval duration of 10 seconds, the |metrics the draft discusses are hardly long-term. Description of |long-term network properties is interesting, too, but let's take it |one step at a time: first define how to turn a 100-packet sample into |human-readable measurements, then take it from there... _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed May 03 04:52:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbD5S-0002hK-4R; Wed, 03 May 2006 04:51:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbD5Q-0002Z3-Lt for ippm@ietf.org; Wed, 03 May 2006 04:51:56 -0400 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbD5P-0004Ld-9F for ippm@ietf.org; Wed, 03 May 2006 04:51:56 -0400 Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id k438pRn28349; Wed, 3 May 2006 10:51:27 +0200 (MEST) 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="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [ippm] draft-shalunov-ippm-reporting-00.txt - availability Date: Wed, 3 May 2006 10:51:29 +0200 Message-ID: <70524A4436C03E43A293958B505008B61B9FDB@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ippm] draft-shalunov-ippm-reporting-00.txt - availability Thread-Index: AcZufxHeL/98PSGzSjGd772vdprJZAADlkAg From: "Schmoll, Carsten" To: "Henk Uijterwaal" , "Al Morton" , "Geib, Ruediger" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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: , Errors-To: ippm-bounces@ietf.org =20 > -----Original Message----- > From: Henk Uijterwaal [mailto:henk@ripe.net]=20 > Sent: Wednesday, May 03, 2006 8:20 AM > >+ how many packets must be sent in each window for valid decision >=20 > That is a valid question and probably something to include in the > draft. (If N out of M packets arrive, how confident can I be that > the loss is below X%.) Any statistician on the list who can > provide text? I'm not a statistician but I did the math once. I'm not sure we should start to include probability calculations into the=20 draft though, since that is another quite wide field... To be *able* to check probaility of a threshold violation, if desired, I would engourage to: * report the number of probe packets n used together with the report=20 (would this be needed *per* QoS value?) * and add some text to the draft like e.g.: "Note that the reported delay and loss values have a limited accuracy due to the sampling-like nature of the QoS measurements generating them. It is possible to estimate the probability of loss/delay not exceeding a certain threshold from the loss/delay values and the number of probe=20 packets used." Regards, Carsten. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed May 03 05:24:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbDaV-0004N9-1y; Wed, 03 May 2006 05:24:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbDaQ-0004Fa-JN for ippm@ietf.org; Wed, 03 May 2006 05:23:58 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbCN6-0002v4-7D for ippm@ietf.org; Wed, 03 May 2006 04:06:08 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FbC7Q-0001zH-Kq for ippm@ietf.org; Wed, 03 May 2006 03:49:57 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Wed, 3 May 2006 09:49:51 +0200 Received: by S4DE8PSAANS.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 3 May 2006 09:49:51 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED20E6321@S4DE8PSAAFQ.mitte.t-com.de> From: "Geib, Ruediger" To: Carsten.Schmoll@fokus.fraunhofer.de Subject: RE: [ippm] draft-shalunov-ippm-reporting-00.txt - availability Date: Wed, 3 May 2006 09:49:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: -2.6 (--) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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: , Errors-To: ippm-bounces@ietf.org Carsten, while I understand your interest and intention in adding "control plane" information to an avaialbility/connectivity metric, I side with Stas in rejecting the idea for now. Let's deal with the relatively simple and basic IP connectivty and performance first. DHCP, DNS, RADIUS.....may each define their own connectivity and performance metrics. The IPPM charter however doesn't seem to include more then basic data delivery by now. If interest is there, it may be enhanced. I personally prefer the current chartered tasks to be done prior to this. Regards Rudiger |Still I think connectivity deserves an extra report entry, |since it might be "FALSE" for different reasons which cannot |be derived from delay etc. For a user the reasons are of interest. | |Think about connectivity *to the Internet* as a desired metric; |this can be FALSE due to a lot of things, e.g. |the 1st L2 link being down, DHCP, DNS, routing, firewall, or |gateway failure. | |Could the metric "connectivity to the Internet" be something more |than binary and could it give a user a value stating either |"OK", or some value indicating ''how far'' connectivity is from being |OK? | |If connectivity is just a binary metric then I think it could |be derived | |from the other reported metrics (if we just talk about Layer3 |connectivity) |as long as the destination parameter is the same. | |What do you think about a finer granularity for connectivity? _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed May 03 09:37:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbHXk-0005Em-1Y; Wed, 03 May 2006 09:37:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbHXi-0005Eh-Hw for ippm@ietf.org; Wed, 03 May 2006 09:37:26 -0400 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbHXg-0000Id-2v for ippm@ietf.org; Wed, 03 May 2006 09:37:26 -0400 Received: by postman.ripe.net (Postfix, from userid 4008) id 960912410A; Wed, 3 May 2006 15:37:17 +0200 (CEST) Received: from herring.ripe.net (herring.ripe.net [193.0.1.203]) by postman.ripe.net (Postfix) with ESMTP id 2A721240DB; Wed, 3 May 2006 15:37:17 +0200 (CEST) Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239]) by herring.ripe.net (Postfix) with ESMTP id D452E2F594; Wed, 3 May 2006 15:37:16 +0200 (CEST) Message-Id: <7.0.1.0.2.20060503151127.034f77e0@ripe.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 03 May 2006 15:37:02 +0200 To: "Geib, Ruediger" From: Henk Uijterwaal Subject: RE: [ippm] draft-shalunov-ippm-reporting-00.txt - availability In-Reply-To: <6439282641581441A36F7F6F83ED2ED20E631F@S4DE8PSAAFQ.mitte.t -com.de> References: <6439282641581441A36F7F6F83ED2ED20E631F@S4DE8PSAAFQ.mitte.t-com.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RIPE-Spam-Level: X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000136 / -4.4 X-RIPE-Signature: 3001741d543a687862c9ecba70c2ca7f X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 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: , Errors-To: ippm-bounces@ietf.org Ruediger, >|>+ how many packets must be sent in each window for valid decision >| >|That is a valid question and probably something to include in the >|draft. (If N out of M packets arrive, how confident can I be that >|the loss is below X%.) Any statistician on the list who can >|provide text? > >This may be done service specific: if a user/application recognises a >service as being "not connected/available" if he misses connectivity >for a time of delta T, then this is the interval we look at. Then a >loss rate must be defined, which would result in the "impression". >A statistician may be of little help. This issue is the tricky part >of any availability definition. That is not what I meant. We want to check if the service is available even if the user does not use it at a particular time. So, we have to send probe packets. These packets will probably sent at a lower rate than the real application, so the question is how many we have to send. Example: I want that packets sent by my VoIP phone arrive about 99.9% of the time, or roughly 3599 seconds every hour. I measure by sending probe packets at a rate of 1/minute. In a particular hour, 1 packet gets lost, or 1/60. Is that consistent with 99.9% or not? I remember doing this problem with broken lightbulbs, I don't remember how. >|>One of the reasons to define two-states like this is to distinguish >|>time intervals with failures from "normal" performance when preparing >|>long-term summaries. >| >|I agree with all of this, but I still don't see why availability >|has to be in this draft. If we send X packets/unit of time and >|report loss, then the user can do the math for his version of >|availability himself using the algorithm he likes. > >Please get more precise. If your statement covers the following >example, I'm with you. My point would be that a report may cover >a long interval and not every user may be interested in collecting >raw data to do his own "connectivity" evaluation: > >Reporting Intervall: 15 min (900 sec) >Measurement Intervall: 1 sec between probe packets >Availability definition: 10 consecutive packets lost make any such > ten second interval unavailable >Other parameters reported: loss rate, delay etc. > >As an example, 20 packets may have been lost during one reporting >interval, out of these 20 some 18 packets were lost in sequence. > >Service available: 882 sec >Service not available: 18 sec > >Packet loss rate: 2/882 I'd report loss% in a 10 second intervals, and define not-available as loss% >= 90% in such an interval. In this specific case, I'd report: 2 intervals with loss >= 90% Loss rate in the remaining 880 seconds: 2/880. And if you want to use your definition, that is still possible: set the measurement interval to 1 second, count the number of intervals with 100% packet loss in a row. The problem I see with your definition though is that a sequence like 9 packets lost, 1 arrives, 9 more lost, 1 arrives, 9 more lost, etc, results in "service available 900 seconds". 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 ------------------------------------------------------------------------------ 1160438400. Watch this space... _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed May 03 09:38:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbHZ7-000643-K2; Wed, 03 May 2006 09:38:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbHZ6-00063y-Cx for ippm@ietf.org; Wed, 03 May 2006 09:38:52 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FbHZ6-0000P6-39 for ippm@ietf.org; Wed, 03 May 2006 09:38:52 -0400 X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-15.tower-121.messagelabs.com!1146663531!8959362!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 14869 invoked from network); 3 May 2006 13:38:51 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-15.tower-121.messagelabs.com with SMTP; 3 May 2006 13:38:51 -0000 Received: from acmt.att.com (acmt.mt.att.com[135.16.251.35](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20060503133851gw100100sle>; Wed, 3 May 2006 13:38:51 +0000 Message-Id: <6.2.1.2.0.20060503090057.08a74b78@postoffice.maillennium.att.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 03 May 2006 09:38:50 -0400 To: Henk Uijterwaal , "Geib, Ruediger" From: Al Morton Subject: RE: [ippm] draft-shalunov-ippm-reporting - availability and aggregation In-Reply-To: <7.0.1.0.2.20060503080247.034f4e98@ripe.net> References: <6439282641581441A36F7F6F83ED2ED20E631D@S4DE8PSAAFQ.mitte.t-com.de> <7.0.1.0.2.20060502172914.034d4e78@ripe.net> <6.2.1.2.0.20060502150926.08bf9a00@postoffice.maillennium.att.com> <7.0.1.0.2.20060503080247.034f4e98@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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: , Errors-To: ippm-bounces@ietf.org At 02:19 AM 5/3/2006, Henk Uijterwaal wrote: >>In my experience, they explicitly define availability as a >>threshold on loss (and that makes it a difficult topic for >>us in IPPM to take-up -- defining good/bad is out-of-scope). > >OK, this is a specific case of "some set of parameters all being below >a certain value". > >>But they also define much more: >> >>+ the length of the time window of evaluation >>+ whether the window is sliding or fixed > >Isn't this setting "good or bad"? I don't think so. It's setting the methods of the measurement that would serve as a practical approximation to assess the ideal notion of availabil/continu-ity. So, maybe this topic is a separate effort? I was thinking along the same lines on a test stream as Ruediger suggested: >Reporting Intervall: 15 min (900 sec) >Measurement Intervall: 1 sec between probe packets >Availability definition: 10 consecutive packets lost make any such > ten second interval unavailable in general, that this test stream may be less dense than a stream that characterizes key performance parameters. It would be possible to sub-sample the measurement using a dense stream, of course, but there is value in having a method that specifies the "minimum" packet rate to assess availabil/continu-ity. I was confused by this (from version 02) >4.1. One-Way Active Measurement > > The default duration of the measurement interval is 10 milliseconds. > ^^^^^^^^^^^^ > The default sending schedule is a Poisson stream. > > The default sending rate is 10 packets/second on average. Hopefully this is fixed in 03. Supposed to be 10 seconds, right? But even then I'm struggling with this statement from Section 2: > The set of metrics of this document is meant for human consumption. > It must therefore be small. Anything greater than half-dozen numbers > is certainly too confusing. And the set of metrics is presented to a human every 10 seconds. That seems like a lot of numbers, more all the time... So I guess the real intent here is to "roll-up" these 10 second reports into another report over a longer time frame that is human consumable. (several folks have said, "take the numbers and do the math", so there's more work to make a report human-consumable) But now we're getting into Temporal Aggregation: - we've already chartered that work in IPPM - at least, it adds a requirement here that the metrics be "aggregatable" (wishing for more time on this, many more comments to make) Al _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed May 03 11:35:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbJNU-00054y-Vb; Wed, 03 May 2006 11:35:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbJNT-00054M-Cd for ippm@ietf.org; Wed, 03 May 2006 11:34:59 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbIYK-00031u-TF for ippm@ietf.org; Wed, 03 May 2006 10:42:08 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FbI0v-0005VE-Un for ippm@ietf.org; Wed, 03 May 2006 10:07:38 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Wed, 3 May 2006 16:07:36 +0200 Received: by S4DE8PSAANS.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 3 May 2006 16:07:36 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED20E632A@S4DE8PSAAFQ.mitte.t-com.de> From: "Geib, Ruediger" To: henk@ripe.net Subject: RE: [ippm] draft-shalunov-ippm-reporting-00.txt - availability Date: Wed, 3 May 2006 16:07:30 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: -2.6 (--) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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: , Errors-To: ippm-bounces@ietf.org Henk, |>|>+ how many packets must be sent in each window for valid decision |>| H>|That is a valid question and probably something to include in the |>|draft. (If N out of M packets arrive, how confident can I be that |>|the loss is below X%.) Any statistician on the list who can |>|provide text? |> R>This may be done service specific: if a user/application recognises a |>service as being "not connected/available" if he misses connectivity |>for a time of delta T, then this is the interval we look at. Then a |>loss rate must be defined, which would result in the "impression". |>A statistician may be of little help. This issue is the tricky part |>of any availability definition. | H|That is not what I meant. | |We want to check if the service is available even if the user does not |use it at a particular time. Agreed. |So, we have to send probe packets. These |packets will probably sent at a lower rate than the real application, |so the question is how many we have to send. Exactly. But the measurement rate must be meaningful for the application and the duration of the events we want to detect. Could it be that you'd like to know what's the minimum number of probes to detect an event of duration delta T? Without consulting a statistician, we could go for the law of minimum sampling rates in communication, i.e. half the duration of the event to be detected. |Example: I want that packets sent by my VoIP phone arrive |about 99.9% of the time, or roughly 3599 seconds every hour. I measure |by sending probe packets at a rate of 1/minute. In a particular hour, 1 |packet gets lost, or 1/60. Is that consistent with 99.9% or not? No, 98,3% within one hour. Your resolution can't be better than 1,7% here. Further, you'll probably hang up your receiver earlier than after 60 seconds. May 10 seconds be a good value? Then we'd need to send a probe all 5 seconds and declare service to be unavailable, if two consecutive packets are lost (taking the consecutive loss definition). Leaves us with 0,17% granularity, or 99,8% per hour. If you want to proof 99,9% availability within one hour, still more probes are required. Well, 24 hour or 30 day analysis may be preferable. [snip] Your proposal to work with a loss rate instead of consecutive losses is allright to me. The fundamental mechanisms of an availability/connectivity measurement must be agreed. The data amaount of a report may be reduced (that's why I proposed 15 minutes). 10 second reports may not be desireable. One second reports certainly aren't. To give an example: Our national backbone consists of 74 PoPs. Consider a full meshed measurement and a requirement to report to wholesale customers. Second intervall reports are feasible in principle of course, but not really nice. Regards, Rudiger _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed May 03 12:17:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbK2J-0007eZ-UB; Wed, 03 May 2006 12:17:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbK2J-0007eU-En for ippm@ietf.org; Wed, 03 May 2006 12:17:11 -0400 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbK2I-0006Vv-6i for ippm@ietf.org; Wed, 03 May 2006 12:17:11 -0400 Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 8623747C1C; Wed, 3 May 2006 12:17:09 -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 15155-04; Wed, 3 May 2006 12:17:09 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 3F07947E76; Wed, 3 May 2006 12:17:07 -0400 (EDT) To: Al Morton Subject: Re: [ippm] draft-shalunov-ippm-reporting - availability and aggregation References: <6439282641581441A36F7F6F83ED2ED20E631D@S4DE8PSAAFQ.mitte.t-com.de> <7.0.1.0.2.20060502172914.034d4e78@ripe.net> <6.2.1.2.0.20060502150926.08bf9a00@postoffice.maillennium.att.com> <7.0.1.0.2.20060503080247.034f4e98@ripe.net> <6.2.1.2.0.20060503090057.08a74b78@postoffice.maillennium.att.com> From: stanislav shalunov Date: 03 May 2006 12:17:11 -0400 In-Reply-To: <6.2.1.2.0.20060503090057.08a74b78@postoffice.maillennium.att.com> Message-ID: <86y7xjnkvs.fsf@abel.internet2.edu> Lines: 31 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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: , Errors-To: ippm-bounces@ietf.org Al Morton writes: > > The default duration of the measurement interval is 10 milliseconds. > Hopefully this is fixed in 03. Supposed to be 10 seconds, right? Yes, as you may have noticed, the typo is fixed in 03. > But even then I'm struggling with this statement from Section 2: > > The set of metrics of this document is meant for human consumption. > > It must therefore be small. Anything greater than half-dozen numbers > > is certainly too confusing. > > And the set of metrics is presented to a human every 10 seconds. > That seems like a lot of numbers, more all the time... The set can be derived from a run of a ping-like tool. In that case, it's just one set. If an application such as a game or a VoIP phone produces it, it just shows the statistics for the last 10 seconds (as numbers, dial positions, whatever), continually updating them. > So I guess the real intent here is to "roll-up" these 10 second reports > into another report over a longer time frame that is human consumable. > (several folks have said, "take the numbers and do the math", so there's > more work to make a report human-consumable) No. That's not an intent and, I think, should be separate. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed upside down. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed May 03 12:24:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbK9D-0004of-A2; Wed, 03 May 2006 12:24:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbK9B-0004oa-OD for ippm@ietf.org; Wed, 03 May 2006 12:24:17 -0400 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbK9B-0006og-Gz for ippm@ietf.org; Wed, 03 May 2006 12:24:17 -0400 Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 47F8747E5F; Wed, 3 May 2006 12:24:17 -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 16696-06; Wed, 3 May 2006 12:24:17 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 04C9C47CA2; Wed, 3 May 2006 12:24:17 -0400 (EDT) To: Henk Uijterwaal Subject: Re: [ippm] draft-shalunov-ippm-reporting-00.txt - availability References: <6439282641581441A36F7F6F83ED2ED20E631D@S4DE8PSAAFQ.mitte.t-com.de> <7.0.1.0.2.20060502172914.034d4e78@ripe.net> <6.2.1.2.0.20060502150926.08bf9a00@postoffice.maillennium.att.com> <7.0.1.0.2.20060503080247.034f4e98@ripe.net> From: stanislav shalunov Date: 03 May 2006 12:24:21 -0400 In-Reply-To: <7.0.1.0.2.20060503080247.034f4e98@ripe.net> Message-ID: <86u087nkju.fsf@abel.internet2.edu> Lines: 21 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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: , Errors-To: ippm-bounces@ietf.org Henk Uijterwaal writes: > (If N out of M packets arrive, how confident can I be that the loss > is below X%.) To be able to say things like that, you need an assumption of an underlying distribution and knowledge of the underlying distribution (and a few other things). I would much prefer the statistics to be empirical properties of the data set. In that case, when the network properties change, the statistics can stay the same. Even if we somehow miraculously agree today that packet delay singletons are i.i.d. deviates and the underlying distribution is a power law with given parameter relationships, such agreement or its implications are unlikely to hold up very long. Better to make no assumptions when we can avoid it. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed at room temperature. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed May 03 12:29:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbKDL-0006TO-D7; Wed, 03 May 2006 12:28:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbKDJ-0006TJ-SA for ippm@ietf.org; Wed, 03 May 2006 12:28:33 -0400 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbKDI-00072c-KZ for ippm@ietf.org; Wed, 03 May 2006 12:28:33 -0400 Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 5B4BB47E68; Wed, 3 May 2006 12:28:32 -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 17451-06; Wed, 3 May 2006 12:28:32 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id ED08B47E72; Wed, 3 May 2006 12:28:31 -0400 (EDT) To: "Geib, Ruediger" Subject: Re: [ippm] draft-shalunov-ippm-reporting-00.txt - availability References: <6439282641581441A36F7F6F83ED2ED20E632A@S4DE8PSAAFQ.mitte.t-com.de> From: stanislav shalunov Date: 03 May 2006 12:28:35 -0400 In-Reply-To: <6439282641581441A36F7F6F83ED2ED20E632A@S4DE8PSAAFQ.mitte.t-com.de> Message-ID: <86psivnkcs.fsf@abel.internet2.edu> Lines: 15 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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: , Errors-To: ippm-bounces@ietf.org "Geib, Ruediger" writes: > Your proposal to work with a loss rate instead of consecutive losses is > allright to me. The fundamental mechanisms of an availability/connectivity > measurement must be agreed. Guys, let's just print the value and be done with it. I don't expect this group will ever come to the point of agreeing on some loss threshold that defines ``OK service''. Neither should it. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ All revolutions are bloody. The October Revolution was bloodless, but it was only the beginning. -- Dmitri Volkogonov _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu May 04 04:02:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbYn0-0001aP-Kr; Thu, 04 May 2006 04:02:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbYmz-0001aJ-M5 for ippm@ietf.org; Thu, 04 May 2006 04:02:21 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbYmy-0005Xw-A8 for ippm@ietf.org; Thu, 04 May 2006 04:02:21 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Thu, 4 May 2006 10:02:19 +0200 Received: by S4DE8PSAANS.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 4 May 2006 10:02:18 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED20E632E@S4DE8PSAAFQ.mitte.t-com.de> From: "Geib, Ruediger" To: shalunov@internet2.edu Subject: RE: [ippm] draft-shalunov-ippm-reporting-00.txt - availability Date: Thu, 4 May 2006 10:02:16 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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: , Errors-To: ippm-bounces@ietf.org |From: stanislav shalunov | | | Henk|> (If N out of M packets arrive, how confident can I be that the loss |> is below X%.) | Stas| To be able to say things like that, you need an assumption of an |underlying distribution and knowledge of the underlying distribution |(and a few other things). I would much prefer the statistics to be |empirical properties of the data set. In that case, when the network |properties change, the statistics can stay the same. | |Even if we somehow miraculously agree today that packet delay |singletons are i.i.d. deviates and the underlying distribution is a |power law with given parameter relationships, such agreement or its |implications are unlikely to hold up very long. Better to make no |assumptions when we can avoid it. I agree with Stas' assessment. Regards, Rudiger _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu May 04 04:26:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbZ9t-0000Au-Mq; Thu, 04 May 2006 04:26:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbZ9s-0000Am-7E for ippm@ietf.org; Thu, 04 May 2006 04:26:00 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbZ9r-0006Bt-Rk for ippm@ietf.org; Thu, 04 May 2006 04:26:00 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Thu, 4 May 2006 10:25:59 +0200 Received: by S4DE8PSAANS.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 4 May 2006 10:25:58 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED20E632F@S4DE8PSAAFQ.mitte.t-com.de> From: "Geib, Ruediger" To: shalunov@internet2.edu Subject: RE: [ippm] draft-shalunov-ippm-reporting-00.txt - availability Date: Thu, 4 May 2006 10:25:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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: , Errors-To: ippm-bounces@ietf.org |> Your proposal to work with a loss rate instead of |> consecutive losses is allright to me. The |> fundamental mechanisms of an availability/ |> connectivity measurement must be agreed. | |Guys, let's just print the value and be done with it. I don't expect |this group will ever come to the point of agreeing on some loss |threshold that defines ``OK service''. Neither should it. As I mentioned earlier, agreeing these thresholds is the hard part of an availability measurement. I agree that IPPM better doesn't get involved. This may be done once operational experience allows for a consent within the WG. What I'd propose is to enable reports of the following kind: During a report Interval of X Service was Unavailable: U (U <= X) Service was available: X-U During X-U the following metrics were determined: Packet loss rate, delay metric..... The mechanism how to determine connectivity/availability should be specified in principle, but not in detail: service is unavailable if n out of m consecutive probing packets are lost (n <= m). The total number of probing packets p sent during X should meet p >= m. Hope that makes sense. Regards, Rudiger _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu May 04 11:30:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbfm9-00035V-JA; Thu, 04 May 2006 11:29:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbfm8-00035Q-5X for ippm@ietf.org; Thu, 04 May 2006 11:29:56 -0400 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbfm6-0000ET-Tt for ippm@ietf.org; Thu, 04 May 2006 11:29:56 -0400 Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 96AEB47C4E; Thu, 4 May 2006 11:29:54 -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 09156-09; Thu, 4 May 2006 11:29:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 7823247C3B; Thu, 4 May 2006 11:29:54 -0400 (EDT) To: "Geib, Ruediger" Subject: Re: [ippm] draft-shalunov-ippm-reporting-00.txt - availability References: <6439282641581441A36F7F6F83ED2ED20E632F@S4DE8PSAAFQ.mitte.t-com.de> From: stanislav shalunov Date: 04 May 2006 11:29:59 -0400 In-Reply-To: <6439282641581441A36F7F6F83ED2ED20E632F@S4DE8PSAAFQ.mitte.t-com.de> Message-ID: <86psitst8o.fsf@abel.internet2.edu> Lines: 31 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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: , Errors-To: ippm-bounces@ietf.org "Geib, Ruediger" writes: > The mechanism how to determine connectivity/availability should > be specified in principle, but not in detail: Ruediger, The rest of the draft can be implemented, with defaults. It has defaults for everything. Defaults are rather the point. Unless defaults are overridden, the results can be compared directly. I do believe that everything should have defaults, in this draft. > service is unavailable if n out of m consecutive probing packets are > lost (n <= m). The total number of probing packets p sent during X > should meet p >= m. ...but I don't believe that we could come up with values of n, m, and p that would be acceptable to everyone. (There are also statistical arguments against doing such ad hoc selection, but even default parameter choice, I think, is enough to make it a no-go.) If there's interest in long-term aggregation and reporting (presumably with SLAs in mind first), I think it should be a separate document, perhaps building on this draft: it might subdivide the long-term interval into 10-second chunks, do stats of this draft on the chunks, and then do something to be discussed with these stats. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ Sex is the mathematics urge sublimated. -- M. C. Reed. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu May 04 15:11:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbjDx-0001U4-PZ; Thu, 04 May 2006 15:10:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbjDw-0001Pf-7w for ippm@ietf.org; Thu, 04 May 2006 15:10:52 -0400 Received: from mail124.messagelabs.com ([85.158.136.19]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FbjDs-0001RR-Qz for ippm@ietf.org; Thu, 04 May 2006 15:10:52 -0400 X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-14.tower-124.messagelabs.com!1146769845!6795579!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 6851 invoked from network); 4 May 2006 19:10:45 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-14.tower-124.messagelabs.com with SMTP; 4 May 2006 19:10:45 -0000 Received: from acmt.att.com (acmt.mt.att.com[135.16.251.35](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20060504191044gw10010084e>; Thu, 4 May 2006 19:10:44 +0000 Message-Id: <6.2.1.2.0.20060504144354.0898d998@postoffice.maillennium.att.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 04 May 2006 15:10:44 -0400 To: stanislav shalunov , From: Al Morton Subject: Re: [ippm] draft-shalunov-ippm-reporting-00.txt - availability In-Reply-To: <86psitst8o.fsf@abel.internet2.edu> References: <6439282641581441A36F7F6F83ED2ED20E632F@S4DE8PSAAFQ.mitte.t-com.de> <86psitst8o.fsf@abel.internet2.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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: , Errors-To: ippm-bounces@ietf.org Stas, I think the most important clarification you can make at this point is to add a Scope section to the draft. The only clues I can find that these metrics are intended for real-time display to a single user are the "now-corrected-in-03" measurement interval of 10 seconds, and this: At 12:17 PM 5/3/2006, stanislav shalunov wrote: >The set can be derived from a run of a ping-like tool. In that case, >it's just one set. If an application such as a game or a VoIP phone >produces it, it just shows the statistics for the last 10 seconds (as >numbers, dial positions, whatever), continually updating them. If this scope had been clear, I'm sure I would have spent less time discussing availability. If I see packet loss = 100% every 10 seconds, I don't need anymore convincing than that. There's a point-point aspect to the scope here. Also, there seems to be no storage of the singletons. The tighter the scope in this case, the better. At 11:29 AM 5/4/2006, stanislav shalunov wrote: >If there's interest in long-term aggregation and reporting (presumably >with SLAs in mind first), I think it should be a separate document, >perhaps building on this draft: it might subdivide the long-term >interval into 10-second chunks, do stats of this draft on the chunks, >and then do something to be discussed with these stats. To simplify achieving agreement in this real-time performance display context, I'd like to argue that this set of metrics should have no explicit or implied status when it comes to reporting performance in longer time frames. That's partly because IPPM already took-up that work item under the Composition and Aggregation Framework (Steven's draft will address Temporal Aggregation). Al _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu May 04 16:18:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbkH0-0004aM-Nn; Thu, 04 May 2006 16:18:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbkH0-0004aE-44 for ippm@ietf.org; Thu, 04 May 2006 16:18:06 -0400 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbkGy-0004qv-Sj for ippm@ietf.org; Thu, 04 May 2006 16:18:06 -0400 Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id A64A147C2F; Thu, 4 May 2006 16:18:04 -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 04663-02; Thu, 4 May 2006 16:18:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 8854947C09; Thu, 4 May 2006 16:18:04 -0400 (EDT) To: Al Morton Subject: Re: [ippm] draft-shalunov-ippm-reporting-00.txt - availability References: <6439282641581441A36F7F6F83ED2ED20E632F@S4DE8PSAAFQ.mitte.t-com.de> <86psitst8o.fsf@abel.internet2.edu> <6.2.1.2.0.20060504144354.0898d998@postoffice.maillennium.att.com> From: stanislav shalunov Date: 04 May 2006 16:18:09 -0400 In-Reply-To: <6.2.1.2.0.20060504144354.0898d998@postoffice.maillennium.att.com> Message-ID: <86u085pmri.fsf@abel.internet2.edu> Lines: 13 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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: , Errors-To: ippm-bounces@ietf.org Al Morton writes: > I think the most important clarification you can make at this point > is to add a Scope section to the draft. You're quite right: the scope of the current document is not clear. I see the source of confusion now. I'll work something out and include it in the next version. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ .signature: I/O Error _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Fri May 05 02:24:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbtj6-0000RV-IW; Fri, 05 May 2006 02:23:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbtj5-0000RQ-Do for ippm@ietf.org; Fri, 05 May 2006 02:23:43 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbtj1-0002yh-0D for ippm@ietf.org; Fri, 05 May 2006 02:23:40 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Fri, 5 May 2006 08:23:37 +0200 Received: by S4DE8PSAANS.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 5 May 2006 08:23:36 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED20E6333@S4DE8PSAAFQ.mitte.t-com.de> From: "Geib, Ruediger" To: shalunov@internet2.edu, acmorton@att.com Subject: RE: [ippm] draft-shalunov-ippm-reporting-00.txt - availability Date: Fri, 5 May 2006 08:23:35 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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: , Errors-To: ippm-bounces@ietf.org Stas, Al, good conclusion, I wanted to add a similar request. Doing a generic differentiation between short term reports and temporal aggregation of metrics is allright and both documents may clarify what they are about in their scope. Regards, Rudiger |> I think the most important clarification you can make at this point |> is to add a Scope section to the draft. | |You're quite right: the scope of the current document is not clear. I |see the source of confusion now. I'll work something out and include |it in the next version. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Fri May 05 17:56:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc8HT-000869-Do; Fri, 05 May 2006 17:56:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc8HS-00085y-ES; Fri, 05 May 2006 17:56:10 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc8HS-0003Uf-6D; Fri, 05 May 2006 17:56:10 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k45Lu5vP004264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 May 2006 21:56:05 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fc8HN-0000eP-AX; Fri, 05 May 2006 17:56:05 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Fri, 05 May 2006 17:56:05 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: ippm chair , Internet Architecture Board , ippm chair , ippm mailing list , RFC Editor Subject: [ippm] Protocol Action: 'Packet Reordering Metric for IPPM' to Proposed Standard 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: , Errors-To: ippm-bounces@ietf.org The IESG has approved the following document: - 'Packet Reordering Metric for IPPM ' as a Proposed Standard This document is the product of the IP Performance Metrics Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-reordering-13.txt Technical Summary This memo defines metrics to evaluate if a network has maintained packet order on a packet-by-packet basis. It provides motivations for the new metrics and discusses the measurement issues, including the context information required for all metrics. The memo first defines a reordered singleton, and then uses it as the basis for sample metrics to quantify the extent of reordering in several useful dimensions for network characterization or receiver design. Additional metrics quantify the frequency of reordering and the distance between separate occurrences. It then defines a metric oriented toward assessing reordering effects on TCP. Working Group Summary The concepts behind the draft have been discussed since 2001, resulting in a number of individual submission drafts which were merged into this draft. This draft has been discussed for several years, it has been stable for about a year now. Reviews were done by a number of key people in the group. Protocol Quality PROTO shepherd: Henk Uijterwaal (henk.uijterwaal@ripe.net) Lars Eggert reviewed this spec for the IESG. The main comment during IETF LC was a completely revised IANA considerations section. Version -13 has addressed the concerns raised during the IESG review. Note to RFC Editor Need to replace "RFC xxxx" with the number this RFC receives upon publication. Section 2, first paragraph: replace reference to RFC2640 to RFC2460 OLD: Ordered arrival is a property found in packets that transit their path, where the packet sequence number increases with each new arrival and there are no backward steps. The Internet Protocol [RFC791] [RFC2640] has no mechanisms to assure either packet NEW: Ordered arrival is a property found in packets that transit their path, where the packet sequence number increases with each new arrival and there are no backward steps. The Internet Protocol [RFC791] [RFC2460] has no mechanisms to assure either packet ^^^^^^^ _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Fri May 05 18:25:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc8jW-0006aj-RU; Fri, 05 May 2006 18:25:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc8jV-0006ac-DO for ippm@ietf.org; Fri, 05 May 2006 18:25:09 -0400 Received: from relay1.san2.attens.net ([192.215.81.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc8jU-0004dW-3l for ippm@ietf.org; Fri, 05 May 2006 18:25:09 -0400 Received: from 607host32.starwoodbroadband.com (607host32.starwoodbroadband.com [12.104.13.32]) by relay1.san2.attens.net (8.13.6/8.13.6) with ESMTP id k45MOuBY021323; Fri, 5 May 2006 22:24:56 GMT Received: from [127.0.0.1] (localhost [127.0.0.1]) by 607host32.starwoodbroadband.com (Postfix) with ESMTP id 4D28DADDB3; Fri, 5 May 2006 18:24:55 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v749.3) In-Reply-To: References: Message-Id: <41B680BC-0163-4417-A633-8C1F821AEAE8@netlab.nec.de> From: Lars Eggert Subject: Re: [ippm] Protocol Action: 'Packet Reordering Metric for IPPM' to Proposed Standard Date: Fri, 5 May 2006 18:24:54 -0400 X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: ippm chair , ippm chair , ippm mailing list 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: , Content-Type: multipart/mixed; boundary="===============0997616075==" Errors-To: ippm-bounces@ietf.org --===============0997616075== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-9-1056970098; protocol="application/pkcs7-signature" --Apple-Mail-9-1056970098 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On May 5, 2006, at 17:56, The IESG wrote: > The IESG has approved the following document: > > - 'Packet Reordering Metric for IPPM ' > as a Proposed Standard Congratulations! And thanks again to the authors for doing a great job following up to the IESG's comments! Lars -- Lars Eggert NEC Network Laboratories --Apple-Mail-9-1056970098 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKgzCCAyAw ggKJoAMCAQICAw9TWTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE4MTAyOTU2WhcNMDYwODE4MTAyOTU2WjBgMQ8wDQYDVQQE EwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA2gsuG8tAmM6U2ESsQjhcijJSq6oDG2c+KvvXJ/xcJXbSIOY8IInezIP0DP41H0gxwHNv AyOuwM6nh0r2wOhzdr77GlKXiij0LoFOpurScPKsC9KTykGAfZtAuCnWIRdDo67Urcw1e306yYgK xF1UzYwGamLalPjejQTRcjLPIbzM4c7fUN/sxmpkpzT2p6OCJDyPhBfSaZWtv3UEoKF+xssNYzOF DRCTHcLc3iXgF7z7J0ud8maUAadfb/25Gm7tJHzBOEonMPkHx2N8Ci0qNce0MMH/LVOVQlNO5kYJ vUJiT0du7LAo/hf8tq3luZrh/Cwc/313x6oKYVuHDBllrQIDAQABo2IwYDAqBgUrZQEEAQQhMB8C AQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCQGA1UdEQQdMBuBGWxhcnMuZWdnZXJ0QG5l dGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAovojiq8758E/78nMS vNvD4359F8XAICzWbhz6cXJaGzv1FJoQcV/RY1x6CQZDt9PqiPiqyQX+xLvqicmEURbGU5+aiWj2 usovQXd+Ts8Doj3tbjk35nD7Etc8a2+Y9fQRUS6spzgJr0fcq2FMYbDnOtf71Bn77KgckoUbIszu mTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl ZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNa LIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1Ud HwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVs Mi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa 9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggQYMIIDgaADAgECAgEAMA0G CSqGSIb3DQEBBQUAMIG/MQswCQYDVQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVy ZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsT FE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkq hkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGUwHhcNMDQwNjE4MTE1MzA4WhcNMDkw NjE3MTE1MzA4WjCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcx EzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExRO ZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZI hvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQC0OQwsE86Rrt0Zs0GOCsYmkGpPwcCFvVpOijIPv1dGolr5a8+7hXSAgRlUyoclq9xfhsUT wlU1qkvVRD3/QOfQyPUxQktxba2ksfsPAKUHovInWydC6rvLU89jtYGEdnRCyA+cEB/XcSADbd2z 9/XK4A2cxmMQiYpXIphYQAxIBwIDAQABo4IBIDCCARwwHQYDVR0OBBYEFOh7L9eqGHnAhbJdO4PY LYzxCaNNMIHsBgNVHSMEgeQwgeGAFOh7L9eqGHnAhbJdO4PYLYzxCaNNoYHFpIHCMIG/MQswCQYD VQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVy ZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVz MRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0 QG5ldGxhYi5uZWMuZGWCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCX6Ipd3AF9 3FDzBaw3ZVvQzzCv/kGPBBzzrJ3n5u+4eQppmOifhuWHZfb8h8S++jqcoPHGVjjlP5PaFb+wL0NR piBalRclikD3xIY/hFoxJ1AHCO0AzfFxEflO10b4+smMrBYJtk5d9EAhr5hEgoGCM7QijBtnCwZB KLI9pFgW1zGCA6UwggOhAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMPU1kwCQYFKw4DAhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDYwNTA1MjIyNDU0WjAjBgkqhkiG9w0BCQQxFgQU83pu0SAo20Az16mrLbhm 5tHmkXowgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA BIIBAJ7h9vsE7z5IWjsJTxRfs/KE1WCsAwUJKVrrsUTWEMa0x9s6+tk+bGyQ/FYfPaibKmT4gTau hIBQ/av8h6toBS2e7nCkW8SlT8t7Aq/+yLOoyQdfQb+Rz9Hs90reQb2xhzSx8g6Xc5590m+honAI 6YStMAibEipY3QEYu1xh5G80VqBDBec1/ub/kC2LoBo7B/NdYTv1kQDD9Ckw9OYkVJ+Z33sfPz3+ HuMauG2kK5M3vy+aJWDM5AxzCBXcfMUGPwCdEMGHUyMZG2+efC6BPyDMpJJWNDam7nrK1mhH+mVO QfcNtKAbuLnJnmt3RCKdA4q6Ap3ie6O7WCK+vBXvC1sAAAAAAAA= --Apple-Mail-9-1056970098-- --===============0997616075== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm --===============0997616075==-- From ippm-bounces@ietf.org Sat May 06 09:09:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcMXB-0001tK-0f; Sat, 06 May 2006 09:09:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcMX9-0001kz-5q for ippm@ietf.org; Sat, 06 May 2006 09:09:19 -0400 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FcMX6-0007UQ-Og for ippm@ietf.org; Sat, 06 May 2006 09:09:19 -0400 Received: by postman.ripe.net (Postfix, from userid 4008) id 2801723FAA; Sat, 6 May 2006 15:09:16 +0200 (CEST) Received: from herring.ripe.net (herring.ripe.net [193.0.1.203]) by postman.ripe.net (Postfix) with ESMTP id F2B3B23F6D; Sat, 6 May 2006 15:09:15 +0200 (CEST) Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239]) by herring.ripe.net (Postfix) with ESMTP id D054F2F593; Sat, 6 May 2006 15:09:15 +0200 (CEST) Message-Id: <7.0.1.0.2.20060505155549.03444840@ripe.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 05 May 2006 16:04:33 +0200 To: "Geib, Ruediger" From: Henk Uijterwaal Subject: RE: [ippm] draft-shalunov-ippm-reporting-00.txt - availability In-Reply-To: <6439282641581441A36F7F6F83ED2ED20E632A@S4DE8PSAAFQ.mitte.t -com.de> References: <6439282641581441A36F7F6F83ED2ED20E632A@S4DE8PSAAFQ.mitte.t-com.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RIPE-Spam-Level: X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00,DATE_IN_PAST_12_24 X-RIPE-Spam-Status: N 0.000025 / -3.2 X-RIPE-Signature: 9a675538ae66445ba10646ca4b2f69a4 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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: , Errors-To: ippm-bounces@ietf.org Hi, >|Example: I want that packets sent by my VoIP phone arrive >|about 99.9% of the time, or roughly 3599 seconds every hour. I measure >|by sending probe packets at a rate of 1/minute. In a particular hour, 1 >|packet gets lost, or 1/60. Is that consistent with 99.9% or not? > >No, 98,3% within one hour. Your resolution can't be better than 1,7% here. I understand that but that wasn't the question. I asked if 98.3% is consistent with the claim of 99.9%. It is a similar problem to: if I flip a coin a lot of times, I get heads half the time, tails the other half. I now flip the coin only 10 times and get 6 heads and 4tails. Is the coin biased or is this due to the limited size of my sample. In general, I don't want to fill my network with probe packets, so the frequency of probe packets may be a lot lower and I still want to say something about the network. >Your proposal to work with a loss rate instead of consecutive losses is >allright to me. The fundamental mechanisms of an availability/connectivity >measurement must be agreed. > >The data amaount of a report may be reduced (that's why I proposed 15 >minutes). 10 second reports may not be desireable. One second reports >certainly aren't. I would not report the data for each 10 second interval to the user, just count the number of such intervals in a longer period and report that. 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 ------------------------------------------------------------------------------ 1160438400. Watch this space... _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon May 08 06:35:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd33f-0005Tl-QB; Mon, 08 May 2006 06:33:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd33e-0005Td-N5 for ippm@ietf.org; Mon, 08 May 2006 06:33:42 -0400 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd33d-0005zU-AJ for ippm@ietf.org; Mon, 08 May 2006 06:33:42 -0400 Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id k48AXOn05734; Mon, 8 May 2006 12:33:24 +0200 (MEST) 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="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [ippm] draft-shalunov-ippm-reporting-00.txt - availability Date: Mon, 8 May 2006 12:33:25 +0200 Message-ID: <70524A4436C03E43A293958B505008B61BA0E1@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ippm] draft-shalunov-ippm-reporting-00.txt - availability Thread-Index: AcZxDn9eTqiMOjaOQ8KyaQmLr827ZwBeQz0A From: "Schmoll, Carsten" To: "Henk Uijterwaal" , "Geib, Ruediger" X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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: , Errors-To: ippm-bounces@ietf.org > -----Original Message----- > From: Henk Uijterwaal [mailto:henk@ripe.net]=20 > Sent: Friday, May 05, 2006 4:05 PM > To: Geib, Ruediger > Cc: ippm@ietf.org > Subject: RE: [ippm] draft-shalunov-ippm-reporting-00.txt -=20 > availability >=20 >=20 > I understand that but that wasn't the question. I asked if 98.3% is > consistent with the claim of 99.9%. It is a similar problem to: if I > flip a coin a lot of times, I get heads half the time, tails the other > half. I now flip the coin only 10 times and get 6 heads and 4tails. > Is the coin biased or is this due to the limited size of my sample. The answer is: you absolutely cannot tell with 10 coin flips. In general you would do a Hypothesis test to check this to answer the question: Is the deviation 6:4 (instead of the expected 5:5)=20 a *significant* deviation considering 10 coin flips? High Significance of an event means: It is very *unlikely* to occur by=20 chance. In the above case a 6:4 is nothing special, since only 24.6% of all results using 10 coin flips result in a 5:5 result and 6:4 + 4:6 results make up for 41% of all results (based on Binomial distribution). So even the chance for something more unbalances than 6:4 as a result=20 is still larger than 34%! An event is usually said to be significant if the probability of getting it via chance alone is less than 5%. Hope this helped a litte, Carsten. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue May 09 05:39:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdOfc-0004cD-IH; Tue, 09 May 2006 05:38:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdOfb-0004ay-6K for ippm@ietf.org; Tue, 09 May 2006 05:38:19 -0400 Received: from smtp15.clb.oleane.net ([213.56.31.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdOfZ-0005r1-Pg for ippm@ietf.org; Tue, 09 May 2006 05:38:19 -0400 Received: from Pavillonquatre ([194.3.133.88]) by smtp15.clb.oleane.net with ESMTP id k499c8wh027083 for ; Tue, 9 May 2006 11:38:08 +0200 Message-Id: <200605090938.k499c8wh027083@smtp15.clb.oleane.net> From: "Chantal Ladouce" To: Date: Tue, 9 May 2006 11:36:54 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZzTBsfhJSXiO9NSlCRV1RqtQkN4w== X-Spam-Score: 0.2 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: Subject: [ippm] Wireless/WiFi Convergence Conference 2006 - Paris - France 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: , Content-Type: multipart/mixed; boundary="===============1995027561==" Errors-To: ippm-bounces@ietf.org This is a multi-part message in MIME format. --===============1995027561== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0272_01C6735C.DF13A570" This is a multi-part message in MIME format. ------=_NextPart_000_0272_01C6735C.DF13A570 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit UMA how? IMS when? Don't miss the 2006 Wireless/WiFi Convergence Conference to be held next week in Paris (on May 16 to May 19). Distinguished experts and key players in the convergence field will address technical issues. Registration is still open. Get all details at: http://www.upperside.fr/wirelessconvergence2006/wwconvergence2006intro.htm ------=_NextPart_000_0272_01C6735C.DF13A570 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

UMA how? = IMS when?

=

Don't miss the 2006 Wireless/WiFi Convergence Conference = to be held next week in Paris (on May 16 to May 19). Distinguished experts and key players in the convergence field will = address technical issues.

Registration is still = open.

Get all details = at:

 

http://www.upperside.fr/wirelessconvergence2006/wwconvergenc= e2006intro.htm

=

 

 

------=_NextPart_000_0272_01C6735C.DF13A570-- --===============1995027561== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm --===============1995027561==-- From ippm-bounces@ietf.org Wed May 10 06:06:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdlZ6-0003Bl-FO; Wed, 10 May 2006 06:05:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdlZ5-0003B5-BI for ippm@ietf.org; Wed, 10 May 2006 06:05:07 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdlZ0-0005G9-TG for ippm@ietf.org; Wed, 10 May 2006 06:05:07 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Wed, 10 May 2006 12:04:59 +0200 Received: by S4DE8PSAANS.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 10 May 2006 12:04:59 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED20E6339@S4DE8PSAAFQ.mitte.t-com.de> From: "Geib, Ruediger" To: henk@ripe.net Subject: RE: [ippm] draft-shalunov-ippm-reporting-00.txt - availability Date: Wed, 10 May 2006 12:04:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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: , Errors-To: ippm-bounces@ietf.org Henk, H>| Example: I want that packets sent by my VoIP phone arrive |>| about 99.9% of the time, or roughly 3599 seconds every hour. |>| I measure by sending probe packets at a rate of 1/minute. |>| In a particular hour, 1 packet gets lost, or 1/60. Is |>| that consistent with 99.9% or not? |> R> No, 98,3% within one hour. Your resolution can't be better |> than 1,7% here. | H |I understand that but that wasn't the question. I asked if 98.3% is |consistent with the claim of 99.9%. It is a similar problem to: if I |flip a coin a lot of times, I get heads half the time, tails the other |half. I now flip the coin only 10 times and get 6 heads and 4tails. |Is the coin biased or is this due to the limited size of my sample. | |In general, I don't want to fill my network with probe packets, so the |frequency of probe packets may be a lot lower and I still want to say |something about the network. In the case of your coin experiment, 50% (5/5) would have been a valid result of your experiment and you can calculate an expecation of this outcome. Your experiment has an error, but it is relatively small. If you send less than 1000 probes, 99.9% free of loss isn't possible as a result. You can estimate if 99.9% free of loss can be proved by your experiment, but you will have a considerable error. R>Your proposal to work with a loss rate instead of consecutive |>losses is allright to me. The fundamental mechanisms of an |>availability/connectivity measurement must be agreed. |> |>The data amaount of a report may be reduced (that's why I proposed 15 |>minutes). 10 second reports may not be desireable. One second reports |>certainly aren't. | H|I would not report the data for each 10 second interval to the user, |just count the number of such intervals in a longer period and report |that. Yes, that's reasonable and sound. Regards, Rudiger _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed May 17 10:32:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgN2o-0001fb-EL; Wed, 17 May 2006 10:30:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgN2Y-0001Wo-Dt for ippm@ietf.org; Wed, 17 May 2006 10:30:18 -0400 Received: from mail126.messagelabs.com ([216.82.250.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FgN2U-0003ht-1z for ippm@ietf.org; Wed, 17 May 2006 10:30:18 -0400 X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-6.tower-126.messagelabs.com!1147876212!9355916!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 3509 invoked from network); 17 May 2006 14:30:12 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-6.tower-126.messagelabs.com with SMTP; 17 May 2006 14:30:12 -0000 Received: from acmt.att.com (acmt.mt.att.com[135.16.251.35](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20060517143012gw100100oee>; Wed, 17 May 2006 14:30:12 +0000 Message-Id: <6.2.1.2.0.20060517093333.070998a0@postoffice.maillennium.att.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 17 May 2006 10:30:12 -0400 To: ippm@ietf.org From: Al Morton Subject: Re: [ippm] I-D ACTION:draft-ietf-ippm-bw-capacity-01.txt In-Reply-To: <20060424222506.GA23241@firebird1.grc.nasa.gov> References: <20060405231155.GA26226@firebird1.grc.nasa.gov> <001201c662bf$8e8c9010$6700a8c0@Trantor> <20060424222506.GA23241@firebird1.grc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: 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: , Errors-To: ippm-bounces@ietf.org Joseph and Phil, While reading the latest draft, I came up with a few suggestions, but otherwise the definitions appear well-constructed to me. (the points appear to apply to the working text, as well) hope this helps, Al Sec2: some rearrangement/modification of the phrases might help OLD IP Layer Link Usage: The average usage of a link L, Used(L,T,I), is the actual number of IP layer bits correctly transmitted from any source over link L during the interval [T, T+I], divided by I. NEW IP Layer Link Usage: The average usage of a link L, Used(L,T,I), is the actual number of IP layer bits from any source, correctly received over link L during the interval [T, T+I], divided by I. OLD An important distinction between usage and capacity is that Used(L,T,I) is not the maximum amount, but rather, the actual amount of IP bits that are sent. ... NEW An important distinction between usage and capacity is that Used(L,T,I) is not the maximum amount, but rather, the actual amount of IP bits that are correctly received. ... OLD Since measurements of available capacity are more volatile that that NEW Since measurements of available capacity are more volatile than that Sec 3.5: Type-P Suggest referring to explicit packet markings as the attribute of Type P associated with the link/path capacity, instead of QoS classes. As you say, any sort of QoS class arrangement might be encountered on the path (including null/default), but the marking (and possibly other factors) determine the treatment, or QoS class assignment. Your example of "estimated EF IP Link/Path Capacity" is consistent with this suggestion, but the paragraphs below go on to refer to QoS classes (and these are more nebulous). The packet marking (DSCP) may result in: - preferred treatment in some nodes/links, but not on others. - longer/shorter queue depths than other markings, depending on cross traffic with similar markings & marking itself. - discard - remarking (lesser drop precedence, after policing) - gross remarking (reclassification, like reset to default) So, it's possible to have an "estimated EF IP Link/Path Capacity" of zero, or something higher, and this would be good to know. This seems to be worthwhile (to me) to expand and formally include in the draft (possibly introducing Type-P into the fundamental definitions?). _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu May 18 10:24:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgjOq-0006SA-R8; Thu, 18 May 2006 10:22:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgjOp-0006Rz-RI for ippm@ietf.org; Thu, 18 May 2006 10:22:47 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgjOp-0004VB-IU for ippm@ietf.org; Thu, 18 May 2006 10:22:47 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 18 May 2006 07:22:47 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,142,1146466800"; d="scan'208"; a="28305633:sNHT24677624" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4IEMkTN006895; Thu, 18 May 2006 10:22:47 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 18 May 2006 10:22:46 -0400 Received: from [192.168.1.101] ([10.82.224.206]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 18 May 2006 10:22:46 -0400 In-Reply-To: <6.2.1.2.0.20060517093333.070998a0@postoffice.maillennium.att.com> References: <20060405231155.GA26226@firebird1.grc.nasa.gov> <001201c662bf$8e8c9010$6700a8c0@Trantor> <20060424222506.GA23241@firebird1.grc.nasa.gov> <6.2.1.2.0.20060517093333.070998a0@postoffice.maillennium.att.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0f8cf1c814c0adf3132c9b4ae1809f14@cisco.com> Content-Transfer-Encoding: 7bit From: Dana Blair Subject: Re: [ippm] I-D ACTION:draft-ietf-ippm-bw-capacity-01.txt Date: Thu, 18 May 2006 10:22:44 -0400 To: Al Morton X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 18 May 2006 14:22:46.0400 (UTC) FILETIME=[88AEC800:01C67A86] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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: , Errors-To: ippm-bounces@ietf.org Why the change from transmitted to received ? Dana On May 17, 2006, at 10:30 AM, Al Morton wrote: > Joseph and Phil, > > While reading the latest draft, I came up with a few suggestions, > but otherwise the definitions appear well-constructed to me. > (the points appear to apply to the working text, as well) > > hope this helps, > Al > > Sec2: some rearrangement/modification of the phrases might help > OLD > > IP Layer Link Usage: > The average usage of a link L, Used(L,T,I), is the actual number > of IP layer bits correctly transmitted from any source over link > L > during the interval [T, T+I], divided by I. > NEW > > IP Layer Link Usage: > The average usage of a link L, Used(L,T,I), is the actual number > of IP layer bits from any source, correctly received over link L > during the interval [T, T+I], divided by I. > > OLD > An important distinction between usage and capacity is that > Used(L,T,I) is not the maximum amount, but rather, the actual amount > of IP bits that are sent. ... > > NEW > An important distinction between usage and capacity is that > Used(L,T,I) is not the maximum amount, but rather, the actual amount > of IP bits that are correctly received. ... > > OLD > Since measurements of available capacity are more volatile that that > NEW > Since measurements of available capacity are more volatile than that > > > Sec 3.5: Type-P > > Suggest referring to explicit packet markings as the attribute of Type > P > associated with the link/path capacity, instead of QoS classes. > As you say, any sort of QoS class arrangement might be encountered > on the path (including null/default), but the marking (and possibly > other factors) determine the treatment, or QoS class assignment. > Your example of "estimated EF IP Link/Path Capacity" is consistent > with this suggestion, but the paragraphs below go on to refer to > QoS classes (and these are more nebulous). > > The packet marking (DSCP) may result in: > - preferred treatment in some nodes/links, but not on others. > - longer/shorter queue depths than other markings, > depending on cross traffic with similar markings & marking itself. > - discard > - remarking (lesser drop precedence, after policing) > - gross remarking (reclassification, like reset to default) > > So, it's possible to have an "estimated EF IP Link/Path Capacity" > of zero, or something higher, and this would be good to know. > This seems to be worthwhile (to me) to expand and formally include > in the draft (possibly introducing Type-P into the fundamental > definitions?). > > > _______________________________________________ > 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 Thu May 18 15:35:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgoFb-00082S-OL; Thu, 18 May 2006 15:33:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgoFb-00082N-Ac for ippm@ietf.org; Thu, 18 May 2006 15:33:35 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FgoFa-0007yB-2y for ippm@ietf.org; Thu, 18 May 2006 15:33:35 -0400 X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-2.tower-121.messagelabs.com!1147980813!6923601!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 11120 invoked from network); 18 May 2006 19:33:33 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-2.tower-121.messagelabs.com with SMTP; 18 May 2006 19:33:33 -0000 Received: from acmt.att.com (acmt.mt.att.com[135.16.251.35](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20060518193333gw1001005je>; Thu, 18 May 2006 19:33:33 +0000 Message-Id: <6.2.1.2.0.20060518152325.08a2e298@postoffice.maillennium.att.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 18 May 2006 15:33:29 -0400 To: Dana Blair From: Al Morton Subject: Re: [ippm] I-D ACTION:draft-ietf-ippm-bw-capacity-01.txt In-Reply-To: <0f8cf1c814c0adf3132c9b4ae1809f14@cisco.com> References: <20060405231155.GA26226@firebird1.grc.nasa.gov> <001201c662bf$8e8c9010$6700a8c0@Trantor> <20060424222506.GA23241@firebird1.grc.nasa.gov> <6.2.1.2.0.20060517093333.070998a0@postoffice.maillennium.att.com> <0f8cf1c814c0adf3132c9b4ae1809f14@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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: , Errors-To: ippm-bounces@ietf.org At 10:22 AM 5/18/2006, Dana Blair wrote: >Why the change from transmitted to received ? > >Dana In this memo, data that is in error cannot be counted as successfully received, see section 3.1. The suggestion to change the definition of IP Link Layer Usage was kind of a backlash from the suggested change in the text below (which was: s/sent/correctly received/ ) hth, Al _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu May 18 16:00:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgoeV-0000Za-SI; Thu, 18 May 2006 15:59:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgoeL-0000T9-2q; Thu, 18 May 2006 15:59:09 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgoVV-0000Cd-SO; Thu, 18 May 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k4IJo1XO018525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 May 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FgoVV-0008Fv-Cn; Thu, 18 May 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 18 May 2006 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: ippm@ietf.org Subject: [ippm] I-D ACTION:draft-ietf-ippm-bw-capacity-02.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: , Errors-To: ippm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : Defining Network Capacity Author(s) : P. Chimento, J. Ishac Filename : draft-ietf-ippm-bw-capacity-02.txt Pages : 17 Date : 2006-5-18 Measuring capacity is a task that sounds simple, but in reality can be quite complex. In addition, the lack of a unified nomenclature on this subject makes it increasingly difficult to properly build, test, and use techniques and tools built around these constructs. This document provides definitions for the terms 'Capacity' and 'Available Capacity' related to IP traffic traveling between a source and destination in an IP network. By doing so, we hope to provide a common framework for the discussion and analysis of a diverse set of current and future estimation techniques. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-bw-capacity-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ippm-bw-capacity-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ippm-bw-capacity-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-5-18114656.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-bw-capacity-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-bw-capacity-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-18114656.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm --NextPart-- From ippm-bounces@ietf.org Thu May 18 18:01:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgqVN-0002Cw-0T; Thu, 18 May 2006 17:58:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgqVL-0002Cr-Q0 for ippm@ietf.org; Thu, 18 May 2006 17:57:59 -0400 Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgqVJ-0001Rv-EV for ippm@ietf.org; Thu, 18 May 2006 17:57:59 -0400 Received: from lombok-fi.grc.nasa.gov (seraph4.grc.nasa.gov [128.156.10.13]) by mx1.grc.nasa.gov (Postfix) with ESMTP id E02EFC2B5 for ; Thu, 18 May 2006 17:57:54 -0400 (EDT) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.6/8.13.6) with ESMTP id k4ILvsku021142 for ; Thu, 18 May 2006 17:57:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.6/8.13.1) with ESMTP id k4ILvsoQ016998 for ; Thu, 18 May 2006 17:57:54 -0400 (EDT) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id 11326-23 for ;Thu, 18 May 2006 17:57:52 -0400 (EDT) Received: from firebird1.grc.nasa.gov (gr000630429.grc.nasa.gov [139.88.111.69])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.6/8.13.1) with ESMTP id k4ILvppD016961for ; Thu, 18 May 2006 17:57:51 -0400 (EDT) Received: by firebird1.grc.nasa.gov (Postfix, from userid 501)id 723A230397; Thu, 18 May 2006 17:57:51 -0400 (EDT) Date: Thu, 18 May 2006 17:57:51 -0400 From: Joseph Ishac To: ippm@ietf.org Subject: Re: [ippm] I-D ACTION:draft-ietf-ippm-bw-capacity-01.txt Message-ID: <20060518215751.GA10774@firebird1.grc.nasa.gov> Mail-Followup-To: ippm@ietf.org References: <20060424222506.GA23241@firebird1.grc.nasa.gov> <6.2.1.2.0.20060517093333.070998a0@postoffice.maillennium.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.1.2.0.20060517093333.070998a0@postoffice.maillennium.att.c om> User-Agent: Mutt/1.4.2.1i X-imss-version: 2.040 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:4 S:5 R:5 X-imss-settings: Baseline:2 C:1 M:1 S:2 R:2 (0.1500 0.1500) X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Joseph Ishac List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ippm-bounces@ietf.org Al, thanks for the comments! Just a quick note for folks. What Al refers to as working text, has just recently become version 02 of the draft. Like Al mentions, these comments are still applicable to this latest revision. Thanks, -Joseph On Wed, May 17, 2006 at 10:30:12AM -0400, Al Morton wrote: > Joseph and Phil, > > While reading the latest draft, I came up with a few suggestions, > but otherwise the definitions appear well-constructed to me. > (the points appear to apply to the working text, as well) > > hope this helps, > Al > > Sec2: some rearrangement/modification of the phrases might help > OLD > > IP Layer Link Usage: > The average usage of a link L, Used(L,T,I), is the actual number > of IP layer bits correctly transmitted from any source over link L > during the interval [T, T+I], divided by I. > NEW > > IP Layer Link Usage: > The average usage of a link L, Used(L,T,I), is the actual number > of IP layer bits from any source, correctly received over link L > during the interval [T, T+I], divided by I. > > OLD > An important distinction between usage and capacity is that > Used(L,T,I) is not the maximum amount, but rather, the actual amount > of IP bits that are sent. ... > > NEW > An important distinction between usage and capacity is that > Used(L,T,I) is not the maximum amount, but rather, the actual amount > of IP bits that are correctly received. ... > > OLD > Since measurements of available capacity are more volatile that that > NEW > Since measurements of available capacity are more volatile than that > > > Sec 3.5: Type-P > > Suggest referring to explicit packet markings as the attribute of Type P > associated with the link/path capacity, instead of QoS classes. > As you say, any sort of QoS class arrangement might be encountered > on the path (including null/default), but the marking (and possibly > other factors) determine the treatment, or QoS class assignment. > Your example of "estimated EF IP Link/Path Capacity" is consistent > with this suggestion, but the paragraphs below go on to refer to > QoS classes (and these are more nebulous). > > The packet marking (DSCP) may result in: > - preferred treatment in some nodes/links, but not on others. > - longer/shorter queue depths than other markings, > depending on cross traffic with similar markings & marking itself. > - discard > - remarking (lesser drop precedence, after policing) > - gross remarking (reclassification, like reset to default) > > So, it's possible to have an "estimated EF IP Link/Path Capacity" > of zero, or something higher, and this would be good to know. > This seems to be worthwhile (to me) to expand and formally include > in the draft (possibly introducing Type-P into the fundamental > definitions?). > > > _______________________________________________ > 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 Thu May 18 18:07:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgqbN-0004wW-TL; Thu, 18 May 2006 18:04:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgqbN-0004wQ-3B for ippm@ietf.org; Thu, 18 May 2006 18:04:13 -0400 Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgqbL-0001yg-RB for ippm@ietf.org; Thu, 18 May 2006 18:04:13 -0400 Received: from lombok-fi.grc.nasa.gov (seraph4.grc.nasa.gov [128.156.10.13]) by mx1.grc.nasa.gov (Postfix) with ESMTP id 81C00C2B5 for ; Thu, 18 May 2006 18:04:11 -0400 (EDT) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.6/8.13.6) with ESMTP id k4IM4B1g022282 for ; Thu, 18 May 2006 18:04:11 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.6/8.13.1) with ESMTP id k4IM4A7o019980 for ; Thu, 18 May 2006 18:04:10 -0400 (EDT) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id 19490-03 for ;Thu, 18 May 2006 18:04:10 -0400 (EDT) Received: from firebird1.grc.nasa.gov (gr000630429.grc.nasa.gov [139.88.111.69])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.6/8.13.1) with ESMTP id k4IM46fs019959for ; Thu, 18 May 2006 18:04:06 -0400 (EDT) Received: by firebird1.grc.nasa.gov (Postfix, from userid 501)id 3A16130397; Thu, 18 May 2006 18:04:06 -0400 (EDT) Date: Thu, 18 May 2006 18:04:06 -0400 From: Joseph Ishac To: ippm@ietf.org Subject: Re: [ippm] I-D ACTION:draft-ietf-ippm-bw-capacity-02.txt Message-ID: <20060518220406.GB10774@firebird1.grc.nasa.gov> Mail-Followup-To: ippm@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-imss-version: 2.040 X-imss-result: Passed X-imss-scores: Clean:66.24290 C:2 M:4 S:5 R:5 X-imss-settings: Baseline:2 C:1 M:1 S:2 R:2 (0.1500 0.1500) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Joseph Ishac List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ippm-bounces@ietf.org Changelog for those familiar with the previous revision. Major Changes from draft-ietf-ippm-bw-capacity-01 * Clarified Abstract * Updated definition of Nominal Physical Link Capacity and added a paragraph to clearly distinguish its purpose. * Clarified definitions of link/path with relation to the framework. * Added: Section on Time and Sampling * Added: Conclusion -Joseph On Thu, May 18, 2006 at 03:50:01PM -0400, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Performance Metrics Working Group of the IETF. > > Title : Defining Network Capacity > Author(s) : P. Chimento, J. Ishac > Filename : draft-ietf-ippm-bw-capacity-02.txt > Pages : 17 > Date : 2006-5-18 > > Measuring capacity is a task that sounds simple, but in reality can > be quite complex. In addition, the lack of a unified nomenclature on > this subject makes it increasingly difficult to properly build, test, > and use techniques and tools built around these constructs. This > document provides definitions for the terms 'Capacity' and 'Available > Capacity' related to IP traffic traveling between a source and > destination in an IP network. By doing so, we hope to provide a > common framework for the discussion and analysis of a diverse set of > current and future estimation techniques. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ippm-bw-capacity-02.txt > _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue May 23 01:51:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiPlY-0006j5-Sm; Tue, 23 May 2006 01:49:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiPlX-0006hI-MB for ippm@ietf.org; Tue, 23 May 2006 01:49:11 -0400 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiPlR-0004I0-Bi for ippm@ietf.org; Tue, 23 May 2006 01:49:11 -0400 Received: by postman.ripe.net (Postfix, from userid 4008) id 83DCB23F06; Tue, 23 May 2006 07:48:48 +0200 (CEST) Received: from herring.ripe.net (herring.ripe.net [193.0.1.203]) by postman.ripe.net (Postfix) with ESMTP id 60E2A23EEB for ; Tue, 23 May 2006 07:48:48 +0200 (CEST) Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239]) by herring.ripe.net (Postfix) with ESMTP id 53E8D2F5A3 for ; Tue, 23 May 2006 07:48:48 +0200 (CEST) Message-Id: <7.0.1.0.2.20060523074447.033af1a0@ripe.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 23 May 2006 07:48:20 +0200 To: ippm@ietf.org From: Henk Uijterwaal Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RIPE-Spam-Level: X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000120 / -4.4 X-RIPE-Signature: c1284293a44b9ec215b0da0a4a95cf02 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: [ippm] draft-shalunov-ippm-reporting 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: , Errors-To: ippm-bounces@ietf.org IPPM Group, We have been discussing draft-shalunov-ippm-reporting quite a lot over the last weeks. Since the document fits well within our charter and seems to generate interest, the chairs propose to make this a working group document. If there are any strong objections, please let us know in the next days (bearing in mind that Thursday is public holiday in most of Europe and Monday in the US). Matt & 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 ------------------------------------------------------------------------------ 1160438400. Watch this space... _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue May 23 08:00:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiVXH-0002y0-VT; Tue, 23 May 2006 07:58:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiVXH-0002xv-Bi for ippm@ietf.org; Tue, 23 May 2006 07:58:51 -0400 Received: from mail126.messagelabs.com ([216.82.250.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FiVXB-0004KY-VJ for ippm@ietf.org; Tue, 23 May 2006 07:58:51 -0400 X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-15.tower-126.messagelabs.com!1148385522!11811136!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 30710 invoked from network); 23 May 2006 11:58:43 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-15.tower-126.messagelabs.com with SMTP; 23 May 2006 11:58:43 -0000 Received: from acmt.att.com (acmt.mt.att.com[135.16.251.35](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20060523115842gw100100s5e>; Tue, 23 May 2006 11:58:42 +0000 Message-Id: <6.2.1.2.0.20060523073755.022ad420@postoffice.maillennium.att.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 23 May 2006 07:58:20 -0400 To: Henk Uijterwaal ,ippm@ietf.org From: Al Morton Subject: Re: [ippm] draft-shalunov-ippm-reporting In-Reply-To: <7.0.1.0.2.20060523074447.033af1a0@ripe.net> References: <7.0.1.0.2.20060523074447.033af1a0@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: 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: , Errors-To: ippm-bounces@ietf.org At 01:48 AM 5/23/2006, Henk Uijterwaal wrote: >We have been discussing draft-shalunov-ippm-reporting quite a lot over >the last weeks. Since the document fits well within our charter and >seems to generate interest, the chairs propose to make this a working >group document. Henk, One of the last comments I made was that this draft desperately needed a Scope section. Without a scope, it's not clear whether this new work would overlap the existing IPPM work or not. Let me add that there is at least one different perspective on the reporting topic, and another draft is in preparation (it's nearly ready for publication). This initial draft will address just a few of the controversial points raised by draft-shalunov-ippm-reporting. regards, Al _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed May 24 09:40:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fita8-0003il-PA; Wed, 24 May 2006 09:39:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fita6-0003ig-Mr for ippm@ietf.org; Wed, 24 May 2006 09:39:22 -0400 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fita2-0007Uz-D8 for ippm@ietf.org; Wed, 24 May 2006 09:39:22 -0400 Received: by postman.ripe.net (Postfix, from userid 4008) id BEEA024003; Wed, 24 May 2006 15:39:09 +0200 (CEST) Received: from herring.ripe.net (herring.ripe.net [193.0.1.203]) by postman.ripe.net (Postfix) with ESMTP id 982BC24065; Wed, 24 May 2006 15:39:09 +0200 (CEST) Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239]) by herring.ripe.net (Postfix) with ESMTP id 8598F2F5B4; Wed, 24 May 2006 15:39:09 +0200 (CEST) Message-Id: <7.0.1.0.2.20060524153225.034df5f8@ripe.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 24 May 2006 15:38:40 +0200 To: Al Morton , ippm@ietf.org From: Henk Uijterwaal Subject: Re: [ippm] draft-shalunov-ippm-reporting In-Reply-To: <6.2.1.2.0.20060523073755.022ad420@postoffice.maillennium.a tt.com> References: <7.0.1.0.2.20060523074447.033af1a0@ripe.net> <6.2.1.2.0.20060523073755.022ad420@postoffice.maillennium.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RIPE-Spam-Level: X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000257 / -4.4 X-RIPE-Signature: 60775a29759e076622295161106a4bf1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: 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: , Errors-To: ippm-bounces@ietf.org Al, >One of the last comments I made was that this draft >desperately needed a Scope section. Without a scope, >it's not clear whether this new work would overlap >the existing IPPM work or not. I agree with this, we (well the authors) should add this and then the whole world can comment. >Let me add that there is at least one different perspective >on the reporting topic, and another draft is in >preparation (it's nearly ready for publication). >This initial draft will address just >a few of the controversial points raised by >draft-shalunov-ippm-reporting. In general (and as a member of the group), I like to see one document that reflects what the group is thinking, rather than two competing documents for the same problem space. OTOH, if a competing document helps the discussion, post it. We can discuss the issues, then see how to merge it into one document that reflects consensus. 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 ------------------------------------------------------------------------------ 1160438400. Watch this space... _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed May 31 11:15:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSOe-0002QL-Ae; Wed, 31 May 2006 11:14:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSOd-0002QC-1V for ippm@ietf.org; Wed, 31 May 2006 11:14:07 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlRSC-0007Yw-I8 for ippm@ietf.org; Wed, 31 May 2006 10:13:44 -0400 Received: from basie.internet2.edu ([207.75.164.22]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FlREq-0007y3-Eb for ippm@ietf.org; Wed, 31 May 2006 10:00:00 -0400 Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id D53CB47E77 for ; Wed, 31 May 2006 09:59:55 -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 18929-03 for ; Wed, 31 May 2006 09:59:55 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id A19CC47DC3 for ; Wed, 31 May 2006 09:59:55 -0400 (EDT) Message-ID: <447DA148.1060509@internet2.edu> Date: Wed, 31 May 2006 09:59:36 -0400 From: Matthew J Zekauskas User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: ippm@ietf.org X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/mixed; boundary="------------040305000601010505010803" X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Score: -2.6 (--) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: Subject: [ippm] [Fwd: Creation of nettest mailing list] 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: , Errors-To: ippm-bounces@ietf.org This is a multi-part message in MIME format. --------------040305000601010505010803 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This might be of interest to some on this list. I apologize if it means you receive multiple copies... (as far as I know Dan hasn't sent it to IPPM yet). --Matt --------------040305000601010505010803 Content-Type: message/rfc822; name="Creation of nettest mailing list" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Creation of nettest mailing list" X-Account-Key: account2 Return-Path: Delivered-To: matt@internet2.edu Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id D498D47F1D for ; Wed, 31 May 2006 09:02:26 -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 06620-04 for ; Wed, 31 May 2006 09:02:26 -0400 (EDT) Received: from megatron.ietf.org (lists.ietf.org [156.154.16.145]) by basie.internet2.edu (Postfix) with ESMTP id A4B6747F1C for ; Wed, 31 May 2006 09:02:26 -0400 (EDT) Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlQLB-00050I-TI; Wed, 31 May 2006 09:02:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlQLA-0004za-4O; Wed, 31 May 2006 09:02:24 -0400 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlQL8-0002AM-Pf; Wed, 31 May 2006 09:02:24 -0400 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4VD0Qrc028582; Wed, 31 May 2006 09:00:27 -0400 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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 31 May 2006 16:02:15 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Creation of nettest mailing list Thread-Index: AcaEsnCI3u8k9DI6Rtmjemzq9GgXpA== From: "Romascanu, Dan (Dan)" To: , , "Ops-Nm (E-mail)" , "Netconf (E-mail)" , X-Scanner: InterScan AntiVirus for Sendmail X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: nettest@ietf.org Subject: Creation of nettest mailing list X-BeenThere: wgchairs@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working Group Chairs List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: wgchairs-bounces@ietf.org X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on basie.internet2.edu X-Spam-Status: No, score=-3.2 required=6.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Level: This is an announcement for the creation of the NETTEST mail list nettest@ietf.org General information about the mailing list is at: https://www1.ietf.org/mailman/listinfo/nettest Craig Brown (crbrown@cisco.com) is the administrator of the list.=20 The purpose of the list is to open the discussions for proposing a new specification for the development of a protocol for the management of network test devices in the areas of data, voice, video, security, and storage.=20 The end goal is to submit an I-D and discuss a request for a BOF.=20 In preparation we will discuss: . The NETTEST charter - "the development a protocol for the management of network test devices in the areas of data, voice, video, security, and storage" . The goals of NETTEST . Some of the discussions to develop the I-D will include: . Experiences already learnt from the current API specifications . Review existing standards to understand what fits . Outline the NETTEST protocol layer that the technologies will use . The method of managing data structures The expectation is to not come to a final decision of all technology specifics prior to the BoF, but to instead have detailed explanations and group understanding of the NETTEST objectives and technology overview. =20 --------------040305000601010505010803 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm --------------040305000601010505010803--