From ippm-bounces@ietf.org Wed Apr 05 19:12:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRHAM-0008Af-T8; Wed, 05 Apr 2006 19:11:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRHAL-0008Aa-W4 for ippm@ietf.org; Wed, 05 Apr 2006 19:11:57 -0400 Received: from mx2.grc.nasa.gov ([128.156.11.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRHAL-0002FY-L3 for ippm@ietf.org; Wed, 05 Apr 2006 19:11:57 -0400 Received: from lombok-fi.grc.nasa.gov (seraph4.grc.nasa.gov [128.156.10.13]) by mx2.grc.nasa.gov (Postfix) with ESMTP id 24710C2B1 for ; Wed, 5 Apr 2006 19:11:57 -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 k35NBuFG025499 for ; Wed, 5 Apr 2006 19:11:56 -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 k35NBuV7002666 for ; Wed, 5 Apr 2006 19:11:56 -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 24407-24 for ;Wed, 5 Apr 2006 19:11:55 -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 k35NBtFe002662for ; Wed, 5 Apr 2006 19:11:55 -0400 (EDT) Received: by firebird1.grc.nasa.gov (Postfix, from userid 501)id 4374830387; Wed, 5 Apr 2006 19:11:55 -0400 (EDT) Date: Wed, 5 Apr 2006 19:11:55 -0400 From: Joseph Ishac To: ippm@ietf.org Subject: Re: [ippm] I-D ACTION:draft-ietf-ippm-bw-capacity-01.txt Message-ID: <20060405231155.GA26226@firebird1.grc.nasa.gov> Mail-Followup-To: ippm@ietf.org References: <20051112010101.GA531@firebird1.grc.nasa.gov> <004401c5ee9a$62b1f050$6700a8c0@Trantor> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004401c5ee9a$62b1f050$6700a8c0@Trantor> User-Agent: Mutt/1.4.2.1i X-imss-version: 2.038 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:2 R:2 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 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 Resurrecting this thread in order to recapture Patrik's comments. After IETF week, I put some more thought into the two comments below and the changes made to the draft, and would like to solicit some input from the list. There were two major comments: 1) Nominal Physical Link Capacity (NPLC) "does not vary with time" I agree, and have a proposed change to the text below. However, I had a question for the list. Take the following example: (a) 802.11b switching speeds from 11 Mbps to 5 Mbps (b) A channel bonded 802.11g going from 108 Mbps to 54 Mbps (single channel) I can see (b) easily argued as a changing NPLC, however one could potentially argue case (a) either way [speed was decreased in order to accommodate signal properties and thus technically the NPLC is still 11 Mbps] So the question is, is it important to distinguish between such cases or is it good enough to say that NomCap (t,t+I) > C(t,t+I), for all values of t and I. (Especially given that the NPLC is not used to define other values in the document) The proposed modifications to the text currently reads as: ===== Nominal Physical Link Capacity: Or NomCap(L) is the theoretical maximum amount of data that the link can support. For example, an OC-3 link would be capable of roughly 155 Mbps. We stress that this is a measurement at the physical layer and not the network IP layer, which we will define separately. While NomCap(L) is typically constant over time, there are links whose characteristics may allow otherwise, such as the dynamic activation of additional transponders for a satellite link. However, the nominal physical link capacity will always be greater than the information carrying capacity of the link. ===== 2) "Link" (Current) vs. "Hop", and concept of VLANs/multiple physical links between routers. After some more thought, I believe the document is accurate with the use of "link". Our definitions are consistent with the framework in that a link connects two "hosts" or "nodes" and does not necessarily make them routers. IP packets are still transported over each link, and that's the property we're looking for. A hop in your terms would be treated as a "cloud subpath" (again from the framework) and would be equivalent to calculating the capacity over that path. So, does text need to be added to further clarify this or can it be leaved as is? Thanks, -Joseph On Mon, Nov 21, 2005 at 01:52:09PM +0100, Patrik Arlos wrote: > Hi Joseph, Philip: > > > In your definition of Nominal Physical Link Capacity (NPLC), you state that > it 'does not vary with time'. I do not think that it holds for wireless > channels. The argument being that the signal interference can change quite > rapidly, and at some point the sending speed has to be altered to compensate > for the interference. Cf. the different speeds of 802.11 or UMTS. However, > from the following discussion, the time varying behaviour of the NPLC is not > interesting. Since it only acts as the upper limit of the capacity, i.e., > C(t,t+I) the IP layer the behaviour of the underlying technologies should not matter. > > > > > How about using 'hop' instead of 'link' in the IP layer terminology? A hop > involves a sender, a receiver and a set of link layer links. I do think that > is would resolve some other problems as well, for instance when virtual LAN > (VLAN) is used a 'hop' might cover multiple physical links, without any IP > layer treatment. I.e., from the IP layer's viewpoint there is a direct > connection to the destination. > > > > For instance, let S and D denote the IP address of the sending and receiving > entities, respectively. The path between S and D is described as sequence of > hops. A hop covers all communication entities involved in the transfer of an > IP packet between two logically adjacent entities. Via the number of hops > (hop count) we can identify the number of networks that has to be traversed > in order to reach D from S. The number of hops is only dependent on the IP > layer configuration, not the underlying configurations. For example, if S > and D are located on the same IP network, then hop count is zero. A hop > count of one would mean that the IP traffic passes one router to reach the > destination. > > /Patrik > > Patrik Arlos > > SE/BTH/Sweden > > +46 (0)455-385654 _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Sun Apr 09 10:41:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSb6Y-0004bn-8i; Sun, 09 Apr 2006 10:41:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSb6W-0004a0-UI; Sun, 09 Apr 2006 10:41:28 -0400 Received: from mail126.messagelabs.com ([216.82.250.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FSb6V-0000QZ-J7; Sun, 09 Apr 2006 10:41:28 -0400 X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-2.tower-126.messagelabs.com!1144593686!10706829!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 31299 invoked from network); 9 Apr 2006 14:41:26 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-2.tower-126.messagelabs.com with SMTP; 9 Apr 2006 14:41:26 -0000 Received: from acmt.att.com (unknown[135.70.150.5](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20060409144124gw1001002ve>; Sun, 9 Apr 2006 14:41:25 +0000 Message-Id: <6.2.1.2.0.20060407224249.0229d900@postoffice.maillennium.att.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 09 Apr 2006 10:41:24 -0400 To: Lars Eggert ,Henk Uijterwaal , Matthew J Zekauskas , Emile Stephan From: Al Morton Subject: Re: [ippm] Last Call: 'Packet Reordering Metric for IPPM' to Proposed Standard 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: 4d87d2aa806f79fed918a62e834505ca Cc: iesg@ietf.org, 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 08:52 PM 3/27/2006, The IESG wrote: >- 'Packet Reordering Metric for IPPM ' > as a Proposed Standard > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg@ietf.org or ietf@ietf.org mailing lists by 2006-04-10. Lars, Henk, Matt, Emile Stephan passed a comment to me in-person, regarding the IPPM Metrics Registry. He reminds that the IANA section of the draft should request registration of the metrics, as is done in the current version of the ippm-multimetrics draft: 9. IANA Considerations Metrics defined in this memo should be registered in the IANA IPPM METRICS REGISTRY as described in initial version of the registry [RFC4148]. Emile -- As author of the registry RFC, is the text sufficient? Or do we need to prepare a template for each new metric, as RFC 4148 says: >5.2. Registration Template > > The following is a proposed template to insert in the IANA > considerations section. For each metric, that section would > instantiate the following statement: > > IANA has registed the following metric in the IANA-IPPM-METRICS- > REGISTRY-MIB: > > aNewMetricName OBJECT-IDENTITY > STATUS current > DESCRIPTION > "The identifier for a new metric." > REFERENCE > "Reference R, section n." > ::= { ianaIppmMetrics nn } -- IANA assigns nn I don't mind preparing a template for each reordering metric with a "Metric Name" section. But this seems like a lot of text to insert at Last Call, although none of it would be controversial. We might do this in a separate draft, too. I'm open to opinions and suggestions. Al _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Sun Apr 09 22:16:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSlx7-0002hy-U0; Sun, 09 Apr 2006 22:16:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSlx5-0002ht-UC for ippm@ietf.org; Sun, 09 Apr 2006 22:16:27 -0400 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSlx4-0001f8-MF for ippm@ietf.org; Sun, 09 Apr 2006 22:16:27 -0400 Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 5BB0447D41 for ; Sun, 9 Apr 2006 22:16: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 06460-02 for ; Sun, 9 Apr 2006 22:16:26 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 2290547D21 for ; Sun, 9 Apr 2006 22:16:26 -0400 (EDT) To: ippm@ietf.org References: From: stanislav shalunov Date: 09 Apr 2006 22:16:24 -0400 In-Reply-To: Message-ID: <86fykmw4xz.fsf@abel.internet2.edu> Lines: 17 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: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [ippm] draft-shalunov-ippm-reporting-00.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ippm-bounces@ietf.org I did not see this announcement on the IPPM list. Internet-Drafts@ietf.org writes: > Network measurement has many purposes. Often, the ultimate purpose > is to report a concise set of metrics describing a network's state to > an end user. The aim of this document is to define a small set of > metrics that are robust, easy to understand, orthogonal, relevant, > and easy to compute. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-shalunov-ippm-reporting-00.txt -- 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 Mon Apr 10 06:12:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FStND-0000hO-E5; Mon, 10 Apr 2006 06:11:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FStNC-0000hG-6R; Mon, 10 Apr 2006 06:11:54 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FStNB-0001mU-P9; Mon, 10 Apr 2006 06:11:54 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 12:11:50 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ippm] Last Call: 'Packet Reordering Metric for IPPM' to Proposed Standard Date: Mon, 10 Apr 2006 12:11:48 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ippm] Last Call: 'Packet Reordering Metric for IPPM' to Proposed Standard thread-index: AcZb46+ZzG6PztRtRDKeP8MBlyl2hwAnY43Q From: "STEPHAN Emile RD-CORE-LAN" To: "Al Morton" X-OriginalArrivalTime: 10 Apr 2006 10:11:50.0100 (UTC) FILETIME=[2EBB3940:01C65C87] X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: ippm@ietf.org, Henk Uijterwaal , Matthew J Zekauskas , Lars Eggert , "Wijnen, Bert \(Bert\)" , iesg@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, RFC4148 tells to describe them in the IANA consideration section. So = from my point of view the simple way (and the faster) consists in = inserting the following in the IANA section: ietfReordered OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-Reordered" REFERENCE "RFCyyyy, section 3." -- RFC Ed.: replace yyyy with actual RFC number & remove this note ::=3D { ianaIppmMetrics nn } -- IANA assigns nn ietfReorderedRatioStream OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-Reordered-Ratio-Stream" REFERENCE "RFCyyyy, section 4.1." -- RFC Ed.: replace yyyy with actual RFC number & remove this note ::=3D { ianaIppmMetrics nn } -- IANA assigns nn ietfPktReorderingExtentStream OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-packet-Reordering-Extent-Stream" REFERENCE "RFCyyyy, section 4.2." -- RFC Ed.: replace yyyy with actual RFC number & remove this note ::=3D { ianaIppmMetrics nn } -- IANA assigns nn ietfPktLateTimeStream OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-packet-Late-Time-Stream" REFERENCE "RFCyyyy, section 4.3." -- RFC Ed.: replace yyyy with actual RFC number & remove this note ::=3D { ianaIppmMetrics nn } -- IANA assigns nn ietfPktByteOffsetStream OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-packet-Byte-Offset-Stream" REFERENCE "RFCyyyy, section 4.4." -- RFC Ed.: replace yyyy with actual RFC number & remove this note ::=3D { ianaIppmMetrics nn } -- IANA assigns nn ietfPktReorderingGapStream OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-packet-Reordering-Gap-Stream" REFERENCE "RFCyyyy, section 4.5." -- RFC Ed.: replace yyyy with actual RFC number & remove this note ::=3D { ianaIppmMetrics nn } -- IANA assigns nn ietfPktReorderingFreeRunStream OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-packet-Reordering-Free-Run-Stream" REFERENCE "RFCyyyy, section 4.6." -- RFC Ed.: replace yyyy with actual RFC number & remove this note ::=3D { ianaIppmMetrics nn } -- IANA assigns nn ietfPktNReorderingStream OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-packet-n-Reordering-Stream" REFERENCE "RFCyyyy, section 5." -- RFC Ed.: replace yyyy with actual RFC number & remove this note ::=3D { ianaIppmMetrics nn } -- IANA assigns nn PS: I take care to have objects name length shorter than 32. Hope it helps. Regards Emile > -----Message d'origine----- > De=A0: Al Morton [mailto:acmorton@att.com] > Envoy=E9=A0: dimanche 9 avril 2006 16:41 > =C0=A0: Lars Eggert; Henk Uijterwaal; Matthew J Zekauskas; STEPHAN = Emile RD- > CORE-LAN > Cc=A0: ippm@ietf.org; iesg@ietf.org > Objet=A0: Re: [ippm] Last Call: 'Packet Reordering Metric for IPPM' to > Proposed Standard >=20 > At 08:52 PM 3/27/2006, The IESG wrote: > >- 'Packet Reordering Metric for IPPM ' > > as a Proposed Standard > > > >The IESG plans to make a decision in the next few weeks, and solicits > >final comments on this action. Please send any comments to the > >iesg@ietf.org or ietf@ietf.org mailing lists by 2006-04-10. >=20 > Lars, Henk, Matt, >=20 > Emile Stephan passed a comment to me in-person, > regarding the IPPM Metrics Registry. He reminds that the IANA section > of the draft should request registration of the metrics, > as is done in the current version of the ippm-multimetrics draft: >=20 > 9. IANA Considerations >=20 > Metrics defined in this memo should be registered in the IANA IPPM > METRICS REGISTRY as described in initial version of the registry > [RFC4148]. >=20 > Emile -- As author of the registry RFC, is the text sufficient? > Or do we need to prepare a template for each new metric, > as RFC 4148 says: >=20 > >5.2. Registration Template > > > > The following is a proposed template to insert in the IANA > > considerations section. For each metric, that section would > > instantiate the following statement: > > > > IANA has registed the following metric in the = IANA-IPPM-METRICS- > > REGISTRY-MIB: > > > > aNewMetricName OBJECT-IDENTITY > > STATUS current > > DESCRIPTION > > "The identifier for a new metric." > > REFERENCE > > "Reference R, section n." > > ::=3D { ianaIppmMetrics nn } -- IANA assigns nn >=20 > I don't mind preparing a template for each reordering metric with a > "Metric Name" section. But this seems like a lot of text > to insert at Last Call, although none of it would be controversial. >=20 > We might do this in a separate draft, too. > I'm open to opinions and suggestions. >=20 > Al >=20 _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed Apr 12 15:50:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTlMB-00064z-4b; Wed, 12 Apr 2006 15:50:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTlLn-0005Zr-Es; Wed, 12 Apr 2006 15:50:03 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTlLm-0002D2-Ob; Wed, 12 Apr 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k3CJo2BX029548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Apr 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FTlLm-0002h4-A9; Wed, 12 Apr 2006 15:50:02 -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: Wed, 12 Apr 2006 15:50:02 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: ippm@ietf.org Subject: [ippm] I-D ACTION:draft-ietf-ippm-reordering-12.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-12.txt Pages : 39 Date : 2006-4-12 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-12.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-12.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-12.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-4-12144303.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-reordering-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-reordering-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-12144303.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 Apr 18 04:10:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVlIH-00036E-42; Tue, 18 Apr 2006 04:10:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVlIF-00035t-Qe for ippm@ietf.org; Tue, 18 Apr 2006 04:10:39 -0400 Received: from spinett.bth.se ([194.47.129.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVlIF-0006MJ-5x for ippm@ietf.org; Tue, 18 Apr 2006 04:10:39 -0400 Received: from Trantor (spinett.bth.se [194.47.129.13]) by spinett.bth.se (8.13.4/8.13.4/Debian-3) with ESMTP id k3I8AREw011798; Tue, 18 Apr 2006 10:10:27 +0200 From: "Patrik Arlos" To: "'Joseph Ishac'" , Subject: RE: [ippm] I-D ACTION:draft-ietf-ippm-bw-capacity-01.txt Date: Tue, 18 Apr 2006 10:10:28 +0200 Organization: Blekinge Institute of Technology Message-ID: <001201c662bf$8e8c9010$6700a8c0@Trantor> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Importance: Normal In-Reply-To: <20060405231155.GA26226@firebird1.grc.nasa.gov> X-Scanned-By: MIMEDefang 2.51 on 194.47.129.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 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 Hi,=20 1) Would it not be possibly to say that a speed reduction is due to = packet loss/signal degradation. What I'm getting at is that we can view the = NPLC as fixed, it's just subject to more disturbances, thus making the perceived capacity (as viewed from layer +1) smaller than the NPLC.=20 In short, I agree that it is sufficient to say that "NomCap (t,t+I) > C(t,t+I), for all values of t and I." 2) I think that you should add one line that highlights how link-layer = links are supposed to be treated, just for clarification.=20 Can you send a copy/url to the current working document? Regards, Patrik Patrik Arlos Ph.D Telecommunications Systems SE/BTH/Sweden +46 (0)455-385444 > -----Original Message----- > From: Joseph Ishac [mailto:jishac@grc.nasa.gov] > Sent: den 6 april 2006 01:12 > To: ippm@ietf.org > Subject: Re: [ippm] I-D ACTION:draft-ietf-ippm-bw-capacity-01.txt >=20 > Resurrecting this thread in order to recapture Patrik's comments. >=20 > After IETF week, I put some more thought into the two comments below = and > the changes made to the draft, and would like to solicit some input > from the list. There were two major comments: >=20 > 1) Nominal Physical Link Capacity (NPLC) "does not vary with time" >=20 > I agree, and have a proposed change to the text below. However, I had = a > question for the list. Take the following example: >=20 > (a) 802.11b switching speeds from 11 Mbps to 5 Mbps > (b) A channel bonded 802.11g going from 108 Mbps to 54 Mbps (single > channel) >=20 > I can see (b) easily argued as a changing NPLC, however one could > potentially argue case (a) either way [speed was decreased in order to > accommodate signal properties and thus technically the NPLC is still = 11 > Mbps] >=20 > So the question is, is it important to distinguish between such cases = or > is it good enough to say that NomCap (t,t+I) > C(t,t+I), for all = values > of t and I. (Especially given that the NPLC is not used to define = other > values in the document) >=20 > The proposed modifications to the text currently reads as: > =3D=3D=3D=3D=3D > Nominal Physical Link Capacity: >=20 > Or NomCap(L) is the theoretical maximum amount of data that the link = can > support. For example, an OC-3 link would be capable of roughly 155 > Mbps. We stress that this is a measurement at the physical layer and > not the network IP layer, which we will define separately. While > NomCap(L) is typically constant over time, there are links whose > characteristics may allow otherwise, such as the dynamic activation of > additional transponders for a satellite link. However, the nominal > physical link capacity will always be greater than the information > carrying capacity of the link. > =3D=3D=3D=3D=3D >=20 >=20 > 2) "Link" (Current) vs. "Hop", and concept of VLANs/multiple physical > links between routers. >=20 > After some more thought, I believe the document is accurate with the = use > of "link". Our definitions are consistent with the framework in that = a > link connects two "hosts" or "nodes" and does not necessarily make = them > routers. IP packets are still transported over each link, and that's > the property we're looking for. A hop in your terms would be treated = as > a "cloud subpath" (again from the framework) and would be equivalent = to > calculating the capacity over that path. >=20 > So, does text need to be added to further clarify this or can it be > leaved as is? >=20 > Thanks, >=20 > -Joseph >=20 >=20 >=20 > On Mon, Nov 21, 2005 at 01:52:09PM +0100, Patrik Arlos wrote: > > Hi Joseph, Philip: > > > > > > In your definition of Nominal Physical Link Capacity (NPLC), you = state > that > > it 'does not vary with time'. I do not think that it holds for = wireless > > channels. The argument being that the signal interference can change > quite > > rapidly, and at some point the sending speed has to be altered to > compensate > > for the interference. Cf. the different speeds of 802.11 or UMTS. > However, > > from the following discussion, the time varying behaviour of the = NPLC is > not > > interesting. Since it only acts as the upper limit of the capacity, > i.e., > > C(t,t+I) capacity at > > the IP layer the behaviour of the underlying technologies should not > matter. > > > > > > > > > > How about using 'hop' instead of 'link' in the IP layer terminology? = A > hop > > involves a sender, a receiver and a set of link layer links. I do = think > that > > is would resolve some other problems as well, for instance when = virtual > LAN > > (VLAN) is used a 'hop' might cover multiple physical links, without = any > IP > > layer treatment. I.e., from the IP layer's viewpoint there is a = direct > > connection to the destination. > > > > > > > > For instance, let S and D denote the IP address of the sending and > receiving > > entities, respectively. The path between S and D is described as > sequence of > > hops. A hop covers all communication entities involved in the = transfer > of an > > IP packet between two logically adjacent entities. Via the number of > hops > > (hop count) we can identify the number of networks that has to be > traversed > > in order to reach D from S. The number of hops is only dependent on = the > IP > > layer configuration, not the underlying configurations. For example, = if > S > > and D are located on the same IP network, then hop count is zero. A = hop > > count of one would mean that the IP traffic passes one router to = reach > the > > destination. > > > > /Patrik > > > > Patrik Arlos > > > > SE/BTH/Sweden > > > > +46 (0)455-385654 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Apr 18 08:08:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVp0R-0003aj-1w; Tue, 18 Apr 2006 08:08:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVp0P-0003ZW-4I for ippm@ietf.org; Tue, 18 Apr 2006 08:08:29 -0400 Received: from smtp12.clb.oleane.net ([213.56.31.47]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVp0O-00026H-O8 for ippm@ietf.org; Tue, 18 Apr 2006 08:08:29 -0400 Received: from Pavillonquatre ([194.3.133.88]) by smtp12.clb.oleane.net with ESMTP id k3IC8P4E018770 for ; Tue, 18 Apr 2006 14:08:26 +0200 Message-Id: <200604181208.k3IC8P4E018770@smtp12.clb.oleane.net> From: "Chantal Ladouce" To: Date: Tue, 18 Apr 2006 14:07:24 +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: AcZi4KbZmHfNUttjSKqEolE4CMt3+Q== X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: Subject: [ippm] Mobile TV World Congress 2007 - 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="===============1296843799==" Errors-To: ippm-bounces@ietf.org This is a multi-part message in MIME format. --===============1296843799== Content-Type: multipart/alternative; boundary="----=_NextPart_000_05B4_01C662F1.6AB14280" This is a multi-part message in MIME format. ------=_NextPart_000_05B4_01C662F1.6AB14280 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The Mobile TV World Congress, will be held in Paris January 23 to 26, together with the worldwide leader event TVoDSL 2007. Carriers, content providers and equipment vendors will address technical issues, describe the standardization process and discuss business and content delivery models. A call for proposals is online at: http://www.upperside.fr/mobiletv2007/mobiletv2007intro.htm ------=_NextPart_000_05B4_01C662F1.6AB14280 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The Mobile TV World = Congress, will be held in Paris January 23 to 26, together with the worldwide leader event = TVoDSL = 2007.

Carriers, content providers and equipment = vendors will address technical issues, describe the standardization process and = discuss business and content delivery models.

 

A call for proposals is online = at:

http://www.upperside.fr/mobiletv2007/mobiletv2007intro.htm

 

------=_NextPart_000_05B4_01C662F1.6AB14280-- --===============1296843799== 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 --===============1296843799==-- From ippm-bounces@ietf.org Thu Apr 20 13:59:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWdQu-0001Sk-E5; Thu, 20 Apr 2006 13:59:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWdQt-0001Sc-4F for ippm@ietf.org; Thu, 20 Apr 2006 13:59:11 -0400 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWdQr-00052g-K6 for ippm@ietf.org; Thu, 20 Apr 2006 13:59:11 -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 k3KHx7n09947; Thu, 20 Apr 2006 19:59:08 +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 Date: Thu, 20 Apr 2006 19:59:06 +0200 Message-ID: <70524A4436C03E43A293958B505008B61B9CFB@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ippm] draft-shalunov-ippm-reporting-00.txt Thread-Index: AcZcRPPtsDBsQx8fQeq60489yWTD5QIXDZbA From: "Schmoll, Carsten" To: "stanislav shalunov" , X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b 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 Dear Stanislav, I read your draft and I think it is going in the=20 right direction. Some suggestions for the next=20 version from my point of view are: * Motivation: should state some application areas, i.e. "why would a human user want to get those values" - e.g. 'to check that IP telephony would be feasable with available QoS' * please don't be offended, but I disagree on the traffic=20 statistics you plan to apply to the traffic metrics. To me they seem to be quite unusual. see below: * delay: I would suggest to use mean or a high percentile as I have never seen median delay to be used to report QoS * loss: just a typo =3D per cent -> percent * jitter: as far as I know the two common defintions are=20 (high) percentile minus min delay across some interval (ITU approach) or min/max of IP delay variation, taken from the series of differences of consecutuve OWD values (IETF approach) * duplication: just lacks definition of a default timeout value * additionally I think two things will need to be added to the draft: a) mentioning about the size of the interval about which all those metrics are obtained and the fact whether this will be=20 a sliding window or fixed time slots, e.g. new values each 10sec b) I'd personally like to see some "packet filter" added to the reporting record. Data might relate only to a fraction of all traffic, e.g. only to UDP or only to traffic from videos.fun.org * additionally "availability" could be one metric (probably with param =3D (list of) server(s) or network) * a small final note (not specific to the draft): when applying the=20 ITU definition for jitter, then high percentile of delay and jitter are quite correlated, and just differ by the interval's min-delay. I cannot say if/how they correlate when the IETF definition (IPDV) is used. * one question from my side: how would you define/report the measurement parameters? (i.e. the src/dst/network/path to which the reported delay/jitter etc. applies) With best regards, Carsten. > -----Original Message----- > From: stanislav shalunov [mailto:shalunov@internet2.edu]=20 > Sent: Monday, April 10, 2006 4:16 AM > To: ippm@ietf.org > Subject: [ippm] draft-shalunov-ippm-reporting-00.txt >=20 > I did not see this announcement on the IPPM list. >=20 > Internet-Drafts@ietf.org writes: >=20 > > Network measurement has many purposes. Often, the ultimate purpose > > is to report a concise set of metrics describing a=20 > network's state to > > an end user. The aim of this document is to define a small set of > > metrics that are robust, easy to understand, orthogonal, relevant, > > and easy to compute. > >=20 > > A URL for this Internet-Draft is: > >=20 > http://www.ietf.org/internet-drafts/draft-shalunov-ippm-report ing-00.txt >=20 > --=20 > Stanislav Shalunov http://www.internet2.edu/~shalunov/ >=20 > Al your Qaeda are belong to US. >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/ippm >=20 >=20 _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu Apr 20 15:40:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWf17-0002f8-Cb; Thu, 20 Apr 2006 15:40:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWf16-0002f3-Ci for ippm@ietf.org; Thu, 20 Apr 2006 15:40:40 -0400 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWf14-0001xg-5U for ippm@ietf.org; Thu, 20 Apr 2006 15:40:40 -0400 Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 19AFB47E36; Thu, 20 Apr 2006 15:40:36 -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 26903-03; Thu, 20 Apr 2006 15:40:36 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id BA7B247C09; Thu, 20 Apr 2006 15:40:36 -0400 (EDT) Date: Thu, 20 Apr 2006 15:40:26 -0400 From: Matthew J Zekauskas To: ippm@ietf.org Message-ID: 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: Henk Uijterwaal , Matt Zekauskas Subject: [ippm] minutes & presentations from the IPPM meeting at IETF-65 Dallas available 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 slides, and now finally all the minutes, from the meeting are now available on the preliminary proceedings page If anyone has any comment or correction, please let the list or the Chairs know. Thanks! --Matt, for Matt & Henk _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Fri Apr 21 04:51:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWrMF-0001a9-60; Fri, 21 Apr 2006 04:51:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWrME-0001a4-0e for ippm@ietf.org; Fri, 21 Apr 2006 04:51:18 -0400 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWrMC-0001CY-Jw for ippm@ietf.org; Fri, 21 Apr 2006 04:51:17 -0400 Received: by postman.ripe.net (Postfix, from userid 4008) id 45464241FE; Fri, 21 Apr 2006 10:51:16 +0200 (CEST) Received: from herring.ripe.net (herring.ripe.net [193.0.1.203]) by postman.ripe.net (Postfix) with ESMTP id 11BFB23EEC; Fri, 21 Apr 2006 10:51:16 +0200 (CEST) Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239]) by herring.ripe.net (Postfix) with ESMTP id E2AC52F5A9; Fri, 21 Apr 2006 10:51:15 +0200 (CEST) Message-Id: <7.0.1.0.2.20060421103820.0346a710@ripe.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 21 Apr 2006 10:51:03 +0200 To: "Schmoll, Carsten" , "stanislav shalunov" , From: Henk Uijterwaal Subject: RE: [ippm] draft-shalunov-ippm-reporting-00.txt In-Reply-To: <70524A4436C03E43A293958B505008B61B9CFB@EXCHSRV.fokus.fraun hofer.de> References: <70524A4436C03E43A293958B505008B61B9CFB@EXCHSRV.fokus.fraunhofer.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.000000 / -4.4 X-RIPE-Signature: b7bd8d62f91ea8fe2b7b65e7139ce404 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 Hi all, >* Motivation: should state some application areas, i.e. > "why would a human user want to get those values" - e.g. > 'to check that IP telephony would be feasable with available QoS' I agree with this. >* delay: I would suggest to use mean or a high percentile as > I have never seen median delay to be used to report QoS We have had this discussion before and consensus seems that median (or percentiles in general) seem the most appropriate way to report delays. We should probably point to this discussion. Carsten: If median cannot be used, then please explain why. >* duplication: just lacks definition of a default timeout value I think we should define one time-out value for delay, loss and duplication. >* additionally I think two things will need to be added to the draft: > a) mentioning about the size of the interval about which all > those metrics are obtained and the fact whether this will be > a sliding window or fixed time slots, e.g. new values each 10sec > b) I'd personally like to see some "packet filter" added to the > reporting record. Data might relate only to a fraction of all > traffic, e.g. only to UDP or only to traffic from videos.fun.org The way I understood the set, is that this refers to 1 pair of source-destination, that is, you get 5 numbers for traffic between src1 and dst1, then 5 other numbers for src1 to dst2. >* additionally "availability" could be one metric > (probably with param = (list of) server(s) or network) There is an availability metric but I don't think anybody has implemented it. I don't see the need in this set of 5 either, loss and delay already tell you that the dst can see the src. "availability" would just confirm 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 Fri Apr 21 05:46:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWsDs-0007Z4-S2; Fri, 21 Apr 2006 05:46:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWsDr-0007OK-2R for ippm@ietf.org; Fri, 21 Apr 2006 05:46:43 -0400 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWsDp-0004BH-Lt for ippm@ietf.org; Fri, 21 Apr 2006 05:46:43 -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 k3L9kTn18660; Fri, 21 Apr 2006 11:46:29 +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 Date: Fri, 21 Apr 2006 11:46:26 +0200 Message-ID: <70524A4436C03E43A293958B505008B61B9D13@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ippm] draft-shalunov-ippm-reporting-00.txt Thread-Index: AcZlINtBxKnmmIYjST2kXayfzZs4CgABnhbQ From: "Schmoll, Carsten" To: "Henk Uijterwaal" , "stanislav shalunov" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 =20 Dear all, please see some comments inline. > -----Original Message----- > From: Henk Uijterwaal [mailto:henk@ripe.net]=20 > Sent: Friday, April 21, 2006 10:51 AM > To: Schmoll, Carsten; stanislav shalunov; ippm@ietf.org > Subject: RE: [ippm] draft-shalunov-ippm-reporting-00.txt >=20 > Carsten: If median cannot be used, then please explain why. Technically median delay can of course be used, yet I don't=20 see its importance, since it does capture the influence of=20 dalay spikes/outliers even *less* than average delay - and a change in those outliers, i.e. the tail of the delay distribution is often the most significant issue to know when checking whether some service could run with an acceptable quality. In case I forgot about some important property of median delay, please=20 let me know. > >* duplication: just lacks definition of a default timeout value >=20 > I think we should define one time-out value for delay, loss and > duplication. Agree. The default value can be the same. It should be a=20 safe upper limit for OWD. Those 2sec would be find with me. > > b) I'd personally like to see some "packet filter" added to the > > reporting record. Data might relate only to a fraction of all > > traffic, e.g. only to UDP or only to traffic from videos.fun.org >=20 > The way I understood the set, is that this refers to 1 pair of > source-destination, that is, you get 5 numbers for traffic=20 > between src1 and dst1, then 5 other numbers for src1 to dst2. Yes, I would say so too. This opens the question: are src+dst part of the reported parameters, part of the request by the client, or both? With best regards, Carsten. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Fri Apr 21 09:05:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWvJH-0007cB-Fl; Fri, 21 Apr 2006 09:04:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWvJG-0007bJ-4L for ippm@ietf.org; Fri, 21 Apr 2006 09:04:30 -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 1FWsgu-0006no-6Y for ippm@ietf.org; Fri, 21 Apr 2006 06:16:44 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FWsOG-0005Zn-Hp for ippm@ietf.org; Fri, 21 Apr 2006 05:57:29 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k3L9tQf4023275; Fri, 21 Apr 2006 04:55:26 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 21 Apr 2006 11:55:24 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15509D5BEB8@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: ippm@ietf.org Date: Fri, 21 Apr 2006 11:55:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: -2.5 (--) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: "Dan Romascanu \(E-mail\)" , "Mreview \(E-mail\)" Subject: [ippm] Review of: draft-ietf-ippm-reordering-12.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 Dan Romascanu (new OPS AD) asked on MIB Doctors list for review of this document, since it is on IESG agenda for April 27th. So I reviewed the document. Looks pretty good. I have one question that maybe the authors or other WG members can answer for me and that is: In section 4.5, it seems to allow for using msg sequence numbers OR units of time (without even having defined what the unit is). So I wonder how this definitions specifies an exact metric. The metric would not be comparable from one to the other measurement if one of them uses msg sequence numbers, while the other uses "units of time". Even if two of them use "units of time" but different units (e.g. micro seconds vs milliseconds) even then they would not be comparable. Was it not the goal of IPPM to define EXACT metrics, so that results of two different tests/measurments could be compared? Bert _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Fri Apr 21 15:05:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX0vm-0000An-Fu; Fri, 21 Apr 2006 15:04:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX0vl-0000AK-7S for ippm@ietf.org; Fri, 21 Apr 2006 15:04:37 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FX0vh-00012i-UL for ippm@ietf.org; Fri, 21 Apr 2006 15:04:37 -0400 X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-3.tower-121.messagelabs.com!1145646272!7532543!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 29178 invoked from network); 21 Apr 2006 19:04:32 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-3.tower-121.messagelabs.com with SMTP; 21 Apr 2006 19:04:32 -0000 Received: from acmt.att.com (acmt.mt.att.com[135.16.251.35](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20060421190432gw100100phe>; Fri, 21 Apr 2006 19:04:32 +0000 Message-Id: <6.2.1.2.0.20060421114535.070d5d70@postoffice.maillennium.att.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 21 Apr 2006 15:04:32 -0400 To: "Wijnen, Bert (Bert)" ,ippm@ietf.org From: Al Morton Subject: Re: [ippm] Review of: draft-ietf-ippm-reordering-12.txt In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15509D5BEB8@nl0006exch001u.nl .lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B15509D5BEB8@nl0006exch001u.nl.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: "Dan Romascanu \(E-mail\)" , "Mreview \(E-mail\)" 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 Bert, Thanks for your review and questions. Please see my take on the answers, below. hope this helps, Al At 05:55 AM 4/21/2006, Wijnen, Bert (Bert) wrote: >... >Looks pretty good. > >I have one question that maybe the authors or other WG members can answer >for me and that is: > > In section 4.5, it seems to allow for using msg sequence numbers OR > units of time (without even having defined what the unit is). > >So I wonder how this definitions specifies an exact metric. The metric would >not be comparable from one to the other measurement if one of them uses >msg sequence numbers, while the other uses "units of time". Even if two of >them use "units of time" but different units (e.g. micro seconds vs >milliseconds) >even then they would not be comparable. I'll tackle the issue of different time resolutions below. In the case of the Gap metrics of Section 4.5, all the parameters necessary to compute the Gap (in units of msg numbers) and GapTime (in units of time) are mandatory, inherited from earlier metrics (as 4.5.2 states). If one reports a metric from this section, then the Gap metric is mandatory, while the GapTime is optional: "Gaps may also be expressed in time:" (equation follows) So, I don't think we should run into a problem when two different testers report metrics that are compliant with section 4.5. They should be able to compare the Gap (msg number-based) metric, at least. >Was it not the goal of IPPM to define EXACT metrics, so that results of >two different tests/measurments could be compared? None of the current IPPM metric RFCs mandate a resolution for time stamps. The IPPM Framework RFC 2330 treats Clock Issues in Section 10, and simply defines the term "resolution" as "the smallest unit by which the clock's time is updated." The One-way Delay RFC 2679 even allows for different resolutions to be used on the Source and Destination clocks (from 3.7.1): > + The resolution of a clock adds to uncertainty about any time > measured with it. Thus, if the source clock has a resolution of > 10 msec, then this adds 10 msec of uncertainty to any time value > measured with it. We will denote the resolution of the source > clock and the destination clock as Rsource and Rdest, > respectively. So, I believe we have specified the metric definitions "exactly", or without ambiguity. But the degree to which measurements from different implementations will be comparable depends on the details of each implementation, including the time stamp resolution and other sources of error or uncertainty (such as time accuracy and skew). _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Fri Apr 21 16:22:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX28v-0007yh-9F; Fri, 21 Apr 2006 16:22:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX28t-0007rr-BI for ippm@ietf.org; Fri, 21 Apr 2006 16:22:15 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FX28r-0004Py-V4 for ippm@ietf.org; Fri, 21 Apr 2006 16:22:15 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k3LKM39n003989; Fri, 21 Apr 2006 13:22:07 -0700 (PDT) (envelope-from mallman@icir.org) Received: from lawyers.icir.org (guns.icir.org [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 773A277AB77; Fri, 21 Apr 2006 16:22:01 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id A41DD3F92A5; Fri, 21 Apr 2006 16:21:09 -0400 (EDT) To: "Wijnen, Bert (Bert)" From: Mark Allman Subject: Re: [ippm] Review of: draft-ietf-ippm-reordering-12.txt In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15509D5BEB8@nl0006exch001u.nl.lucent.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: The Rising MIME-Version: 1.0 Date: Fri, 21 Apr 2006 16:21:09 -0400 Message-Id: <20060421202109.A41DD3F92A5@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: "Dan Romascanu \(E-mail\)" , "Mreview \(E-mail\)" , ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0625029018==" Errors-To: ippm-bounces@ietf.org --===============0625029018== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > Dan Romascanu (new OPS AD) asked on MIB Doctors list for review > of this document, since it is on IESG agenda for April 27th. > > So I reviewed the document. > > Looks pretty good. > > I have one question that maybe the authors or other WG members can answer > for me and that is: > > In section 4.5, it seems to allow for using msg sequence numbers OR > units of time (without even having defined what the unit is). > > So I wonder how this definitions specifies an exact metric. The metric would > not be comparable from one to the other measurement if one of them uses > msg sequence numbers, while the other uses "units of time". Even if two of > them use "units of time" but different units (e.g. micro seconds vs milliseconds) > even then they would not be comparable. > > Was it not the goal of IPPM to define EXACT metrics, so that results of > two different tests/measurments could be compared? I thought we agree to get rid of the "units of time" notion in that it makes it either damn hard or impossible for the receiver to know what is expected (as opposed to a sequence number, which makes it trivial). allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEST61WyrrWs4yIs4RAnMSAJ93Ud4glC4asXYN4QMIQdiKdaHrkwCdFpmn 5S5qISVh7r7ocb7B4XjoUvk= =ltr2 -----END PGP SIGNATURE----- --=_bOundary-- --===============0625029018== 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 --===============0625029018==-- From ippm-bounces@ietf.org Sat Apr 22 01:01:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXAFU-0006La-VE; Sat, 22 Apr 2006 01:01:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXAFU-0006LV-64 for ippm@ietf.org; Sat, 22 Apr 2006 01:01:36 -0400 Received: from mail124.messagelabs.com ([85.158.136.19]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FXAFR-0007Hk-LM for ippm@ietf.org; Sat, 22 Apr 2006 01:01:36 -0400 X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-6.tower-124.messagelabs.com!1145682090!6587647!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 30300 invoked from network); 22 Apr 2006 05:01:30 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-6.tower-124.messagelabs.com with SMTP; 22 Apr 2006 05:01:30 -0000 Received: from acmt.att.com (unknown[135.70.23.230](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20060422050123gw100100sae>; Sat, 22 Apr 2006 05:01:29 +0000 Message-Id: <6.2.1.2.0.20060422003809.022f77d8@postoffice.maillennium.att.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sat, 22 Apr 2006 01:01:22 -0400 To: mallman@icir.org,"Wijnen, Bert (Bert)" From: Al Morton Subject: Re: [ippm] Review of: draft-ietf-ippm-reordering-12.txt In-Reply-To: <20060421202109.A41DD3F92A5@lawyers.icir.org> References: <7D5D48D2CAA3D84C813F5B154F43B15509D5BEB8@nl0006exch001u.nl.lucent.com> <20060421202109.A41DD3F92A5@lawyers.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: "Dan Romascanu \(E-mail\)" , ippm@ietf.org, "Mreview \(E-mail\)" 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 04:21 PM 4/21/2006, Mark Allman wrote: >I thought we agree to get rid of the "units of time" notion in that it >makes it either damn hard or impossible for the receiver to know what is >expected (as opposed to a sequence number, which makes it trivial). > >allman Yes, but your comments on this applied to section 3. We use the message number in the reordering singleton definition. We also agreed to keep SrcTime as a mandatory parameter, and mention time and bytes only as secondary means to determine order. When we discussed this in Minneapolis last year, you came to the mic to agree with this, even where we did not implement your comments verbatim (as with the SrcTime parameter). A summary of comments and responses is here: http://www3.ietf.org/proceedings/05mar/slides/ippm-1.pdf We're discussing a later section here (4.5), and you expressed no objections about using time to quantify the extent of reordering, AFAIK. Al _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Sat Apr 22 15:48:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXO50-0000xk-SF; Sat, 22 Apr 2006 15:47:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXO4z-0000xc-73 for ippm@ietf.org; Sat, 22 Apr 2006 15:47:41 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXO4x-0002BD-R0 for ippm@ietf.org; Sat, 22 Apr 2006 15:47:41 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k3MJlQcK029503; Sat, 22 Apr 2006 12:47:27 -0700 (PDT) (envelope-from mallman@icir.org) Received: from lawyers.icir.org (guns.icir.org [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 3DE2F77ACAD; Sat, 22 Apr 2006 15:47:25 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 95A513F975C; Sat, 22 Apr 2006 15:46:33 -0400 (EDT) To: Al Morton From: Mark Allman Subject: Re: [ippm] Review of: draft-ietf-ippm-reordering-12.txt In-Reply-To: <6.2.1.2.0.20060422003809.022f77d8@postoffice.maillennium.att.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: The Rising MIME-Version: 1.0 Date: Sat, 22 Apr 2006 15:46:33 -0400 Message-Id: <20060422194633.95A513F975C@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: "Wijnen, Bert \(Bert\)" , "Mreview \(E-mail\)" , ippm@ietf.org, "Dan Romascanu \(E-mail\)" X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1405681366==" Errors-To: ippm-bounces@ietf.org --===============1405681366== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Al- > Yes, but your comments on this applied to section 3. > > We use the message number in the reordering singleton definition. We > also agreed to keep SrcTime as a mandatory parameter, and mention time > and bytes only as secondary means to determine order. When we > discussed this in Minneapolis last year, you came to the mic to agree > with this, even where we did not implement your comments verbatim (as > with the SrcTime parameter). A summary of comments and responses is > here: http://www3.ietf.org/proceedings/05mar/slides/ippm-1.pdf > > We're discussing a later section here (4.5), and you expressed no > objections about using time to quantify the extent of reordering, > AFAIK. Doh! This is what I get for not going back and looking at the draft. You're right that my objection was in terms of determining the out-of-orderness and not determining the extent or the characteristics this dynamic created. I do support the use of time for characterizing reordering events, just not for determining the event. But, somehow I misread the context of Bert's note. In any case, sorry for the spurious chud. I'll shut up now! :) allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFESogZWyrrWs4yIs4RAiddAJ9BxbnVfovSSIB9HDpuZerlMoEZ0wCfWiYr lyxJ8QTtPMAetx1IiwGeW8A= =jM1/ -----END PGP SIGNATURE----- --=_bOundary-- --===============1405681366== 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 --===============1405681366==-- From ippm-bounces@ietf.org Sun Apr 23 07:18:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXcbC-0003Sr-KK; Sun, 23 Apr 2006 07:17:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXcbA-0003Oh-SC for ippm@ietf.org; Sun, 23 Apr 2006 07:17:52 -0400 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXcb8-0007KJ-DS for ippm@ietf.org; Sun, 23 Apr 2006 07:17:52 -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 k3NBFQnc008126 for ; Sun, 23 Apr 2006 07:15: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 Subject: RE: [ippm] Review of: draft-ietf-ippm-reordering-12.txt Date: Sun, 23 Apr 2006 14:17:47 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ippm] Review of: draft-ietf-ippm-reordering-12.txt Thread-Index: AcZmwalQVFpAd/64Q6y5NXBWVEsYdQAA9kuA From: "Romascanu, Dan \(Dan\)" To: , "Al Morton" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: "Wijnen, Bert \(Bert\)" , "Mreview \(E-mail\)" , 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 =20 > -----Original Message----- > From: owner-mreview@ops.ietf.org=20 > [mailto:owner-mreview@ops.ietf.org] On Behalf Of Mark Allman > Sent: Saturday, April 22, 2006 10:47 PM > To: Al Morton > Cc: Wijnen, Bert (Bert); Romascanu, Dan (Dan); ippm@ietf.org;=20 > Mreview (E-mail) > Subject: Re: [ippm] Review of: draft-ietf-ippm-reordering-12.txt=20 >=20 >=20 > Al- >=20 > > Yes, but your comments on this applied to section 3. > >=20 > > We use the message number in the reordering singleton=20 > definition. We=20 > > also agreed to keep SrcTime as a mandatory parameter, and=20 > mention time=20 > > and bytes only as secondary means to determine order. When we=20 > > discussed this in Minneapolis last year, you came to the=20 > mic to agree=20 > > with this, even where we did not implement your comments=20 > verbatim (as=20 > > with the SrcTime parameter). A summary of comments and responses is > > here: http://www3.ietf.org/proceedings/05mar/slides/ippm-1.pdf > >=20 > > We're discussing a later section here (4.5), and you expressed no=20 > > objections about using time to quantify the extent of reordering,=20 > > AFAIK. >=20 > Doh! This is what I get for not going back and looking at the draft. > You're right that my objection was in terms of determining=20 > the out-of-orderness and not determining the extent or the=20 > characteristics this dynamic created. I do support the use=20 > of time for characterizing reordering events, just not for=20 > determining the event. But, somehow I misread the context of=20 > Bert's note. In any case, sorry for the spurious chud. I'll=20 > shut up now! :) >=20 > allman >=20 >=20 The context of the question is the comment made by Bert Wijnen wrt. Section 4.5 of the document in preparation of the discussion of the document in the IESG on 4/27. Bert is asking how 'would the metric be comparable from one to the other measurement if one of them uses msg sequence numbers, while the other uses "units of time". Even if two of them use "units of time" but different units (e.g. micro seconds vs milliseconds) even then they would not be comparable.' I believe that his question is still pending.=20 Dan >=20 >=20 _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Sun Apr 23 07:23:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXcgk-00080H-NS; Sun, 23 Apr 2006 07:23:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXcgk-0007xU-4B for ippm@ietf.org; Sun, 23 Apr 2006 07:23:38 -0400 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXcgj-0007az-SR for ippm@ietf.org; Sun, 23 Apr 2006 07:23:38 -0400 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k3NBKRSE020482 for ; Sun, 23 Apr 2006 07:20:28 -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 Subject: RE: [ippm] Review of: draft-ietf-ippm-reordering-12.txt Date: Sun, 23 Apr 2006 14:23:35 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ippm] Review of: draft-ietf-ippm-reordering-12.txt Thread-Index: AcZldm7LOQDd3Z6JTf+zCxX6C17mjwBUXhpw From: "Romascanu, Dan \(Dan\)" To: "Al Morton" , "Wijnen, Bert \(Bert\)" , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: "Mreview \(E-mail\)" 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 It is still not clear to me how this would work in the case one entity determines gaps in units of time and the other uses message sequence numbers. Or, in case message sequence numbers are mandatory anyway, why does Section 4.5 still refer to units of time?=20 Dan =20 =20 > -----Original Message----- > From: Al Morton [mailto:acmorton@att.com]=20 > Sent: Friday, April 21, 2006 10:05 PM > To: Wijnen, Bert (Bert); ippm@ietf.org > Cc: Romascanu, Dan (Dan); Mreview (E-mail) > Subject: Re: [ippm] Review of: draft-ietf-ippm-reordering-12.txt >=20 > Hi Bert, >=20 > Thanks for your review and questions. > Please see my take on the answers, below. > hope this helps, > Al >=20 > At 05:55 AM 4/21/2006, Wijnen, Bert (Bert) wrote: > >... > >Looks pretty good. > > > >I have one question that maybe the authors or other WG members can=20 > >answer for me and that is: > > > > In section 4.5, it seems to allow for using msg sequence=20 > numbers OR > > units of time (without even having defined what the unit is). > > > >So I wonder how this definitions specifies an exact metric.=20 > The metric=20 > >would not be comparable from one to the other measurement if one of=20 > >them uses msg sequence numbers, while the other uses "units=20 > of time".=20 > >Even if two of them use "units of time" but different units=20 > (e.g. micro=20 > >seconds vs > >milliseconds) > >even then they would not be comparable. >=20 > I'll tackle the issue of different time resolutions below. >=20 > In the case of the Gap metrics of Section 4.5, all the=20 > parameters necessary to compute the Gap (in units of msg=20 > numbers) and GapTime (in units of time) are mandatory,=20 > inherited from earlier metrics (as 4.5.2 states). >=20 > If one reports a metric from this section, then the Gap=20 > metric is mandatory, while the GapTime is optional: >=20 > "Gaps may also be expressed in time:" (equation follows) >=20 > So, I don't think we should run into a problem when two=20 > different testers report metrics that are compliant with=20 > section 4.5. They should be able to compare the Gap (msg=20 > number-based) metric, at least. >=20 >=20 > >Was it not the goal of IPPM to define EXACT metrics, so that=20 > results of=20 > >two different tests/measurments could be compared? >=20 > None of the current IPPM metric RFCs mandate a resolution for=20 > time stamps. > The IPPM Framework RFC 2330 treats Clock Issues in Section=20 > 10, and simply defines the term "resolution" as "the smallest=20 > unit by which the clock's time is updated." >=20 > The One-way Delay RFC 2679 even allows for different=20 > resolutions to be used on the Source and Destination clocks=20 > (from 3.7.1): > > + The resolution of a clock adds to uncertainty about any time > > measured with it. Thus, if the source clock has a=20 > resolution of > > 10 msec, then this adds 10 msec of uncertainty to any=20 > time value > > measured with it. We will denote the resolution of the source > > clock and the destination clock as Rsource and Rdest, > > respectively. >=20 > So, I believe we have specified the metric definitions=20 > "exactly", or without ambiguity. But the degree to which=20 > measurements from different implementations will be=20 > comparable depends on the details of each implementation,=20 > including the time stamp resolution and other sources of=20 > error or uncertainty (such as time accuracy and skew). >=20 >=20 _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Sun Apr 23 11:00:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXg4o-0002mo-5f; Sun, 23 Apr 2006 11:00:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXg4m-0002l1-Dx for ippm@ietf.org; Sun, 23 Apr 2006 11:00:40 -0400 Received: from mail126.messagelabs.com ([216.82.250.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FXg4j-0000oi-WF for ippm@ietf.org; Sun, 23 Apr 2006 11:00:40 -0400 X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-13.tower-126.messagelabs.com!1145804433!11227226!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 5657 invoked from network); 23 Apr 2006 15:00:33 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-13.tower-126.messagelabs.com with SMTP; 23 Apr 2006 15:00:33 -0000 Received: from acmt.att.com (unknown[135.70.119.177](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20060423150032gw100100she>; Sun, 23 Apr 2006 15:00:32 +0000 Message-Id: <6.2.1.2.0.20060423103143.022fb7c8@postoffice.maillennium.att.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 23 Apr 2006 11:00:31 -0400 To: "Romascanu, Dan \(Dan\)" , "Wijnen, Bert \(Bert\)" , From: Al Morton Subject: RE: [ippm] Review of: draft-ietf-ippm-reordering-12.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: 8fbbaa16f9fd29df280814cb95ae2290 Cc: "Mreview \(E-mail\)" 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 Good morning, Dan. At 07:23 AM 4/23/2006, Romascanu, Dan \(Dan\) wrote: >It is still not clear to me how this would work in the case one entity >determines gaps in units of time and the other uses message sequence >numbers. As I said below, I don't believe that reporting *either* Gap or GapTime is possible when claiming compliance. The text (reproduced below) says "may also" which to me says: "permission to report GapTime, in addition to Gap". So any system claiming compliance with section 4.5 would report Gaps (based on message numbers), and Gaps would always be a basis for comparison between compliant systems. GapTime is optional, Gaps are not. >Or, in case message sequence numbers are mandatory anyway, why >does Section 4.5 still refer to units of time? And as I clarified below, the DstTime parameter is introduced in section 4.3.2, and is mandatory for section 4.5: > > In the case of the Gap metrics of Section 4.5, all the > > parameters necessary to compute the Gap (in units of msg > > numbers) and GapTime (in units of time) are mandatory, > > inherited from earlier metrics (as 4.5.2 states). Finally, (in response to your earlier message) time stamp resolution is an implementation detail here in IPPM, unless you claim compliance with the active measurement protocol. Using different Timestamp resolutions certainly affects the degree to which the results can be compared, but that's just one of the possible errors and uncertainties, and it doesn't make comparison impossible. hope this helps, Al >Dan > > > > > > > -----Original Message----- > > From: Al Morton [mailto:acmorton@att.com] > > Sent: Friday, April 21, 2006 10:05 PM > > To: Wijnen, Bert (Bert); ippm@ietf.org > > Cc: Romascanu, Dan (Dan); Mreview (E-mail) > > Subject: Re: [ippm] Review of: draft-ietf-ippm-reordering-12.txt > > > > Hi Bert, > > > > Thanks for your review and questions. > > Please see my take on the answers, below. > > hope this helps, > > Al > > > > At 05:55 AM 4/21/2006, Wijnen, Bert (Bert) wrote: > > >... > > >Looks pretty good. > > > > > >I have one question that maybe the authors or other WG members can > > >answer for me and that is: > > > > > > In section 4.5, it seems to allow for using msg sequence > > numbers OR > > > units of time (without even having defined what the unit is). > > > > > >So I wonder how this definitions specifies an exact metric. > > The metric > > >would not be comparable from one to the other measurement if one of > > >them uses msg sequence numbers, while the other uses "units > > of time". > > >Even if two of them use "units of time" but different units > > (e.g. micro > > >seconds vs > > >milliseconds) > > >even then they would not be comparable. > > > > I'll tackle the issue of different time resolutions below. > > > > In the case of the Gap metrics of Section 4.5, all the > > parameters necessary to compute the Gap (in units of msg > > numbers) and GapTime (in units of time) are mandatory, > > inherited from earlier metrics (as 4.5.2 states). > > > > If one reports a metric from this section, then the Gap > > metric is mandatory, while the GapTime is optional: > > > > "Gaps may also be expressed in time:" (equation follows) > > > > So, I don't think we should run into a problem when two > > different testers report metrics that are compliant with > > section 4.5. They should be able to compare the Gap (msg > > number-based) metric, at least. > > > > > > >Was it not the goal of IPPM to define EXACT metrics, so that > > results of > > >two different tests/measurments could be compared? > > > > None of the current IPPM metric RFCs mandate a resolution for > > time stamps. > > The IPPM Framework RFC 2330 treats Clock Issues in Section > > 10, and simply defines the term "resolution" as "the smallest > > unit by which the clock's time is updated." > > > > The One-way Delay RFC 2679 even allows for different > > resolutions to be used on the Source and Destination clocks > > (from 3.7.1): > > > + The resolution of a clock adds to uncertainty about any time > > > measured with it. Thus, if the source clock has a > > resolution of > > > 10 msec, then this adds 10 msec of uncertainty to any > > time value > > > measured with it. We will denote the resolution of the source > > > clock and the destination clock as Rsource and Rdest, > > > respectively. > > > > So, I believe we have specified the metric definitions > > "exactly", or without ambiguity. But the degree to which > > measurements from different implementations will be > > comparable depends on the details of each implementation, > > including the time stamp resolution and other sources of > > error or uncertainty (such as time accuracy and skew). > > > > _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Apr 24 16:38:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY7p5-0005AZ-SQ; Mon, 24 Apr 2006 16:38:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY7p4-000575-HD for ippm@ietf.org; Mon, 24 Apr 2006 16:38:18 -0400 Received: from mx.cbeyond.net ([66.180.96.58] helo=mx.cbeyond.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY7p2-0000v0-3Z for ippm@ietf.org; Mon, 24 Apr 2006 16:38:18 -0400 Received: from [64.238.103.215] (port=1521 helo=telws116) by mx.cbeyond.com with asmtp (Exim 4.34) id 1FY7oy-0001tL-Lg for ippm@ietf.org; Mon, 24 Apr 2006 16:38:12 -0400 From: "Alan Clark" To: Date: Mon, 24 Apr 2006 16:38:08 -0400 Organization: Telchemy MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZn3va+czaa958CSy2ACWmOAaDN7Q== X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Subject: [ippm] Open source ITU-T G.1050 IP impairment simulation/ emulation software X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alan.d.clark@telchemy.com List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1718493283==" Errors-To: ippm-bounces@ietf.org Message-Id: This is a multi-part message in MIME format. --===============1718493283== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C1_01C667BD.7A0055C0" This is a multi-part message in MIME format. ------=_NextPart_000_00C1_01C667BD.7A0055C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit IPPM members may be interested in the new ITU-T G.1050 / TIA 921 IP impairment simulation/emulation model. This uses an impulse driven time series model to emulate the packet delays introduced by a network "stage", which may be a LAN, access router etc. Telchemy developed the original algorithm for this and also maintained the reference implementation associated with the TIA and ITU projects. We decided to make this available free of any IPR and also to make the source code freely available. Obviously, if anyone would like copies of the associated TIA and ITU standards they would need to purchase these from TIA and ITU respectively. The software and some documentation is available on www.telchemy.com/telsim.html - we would welcome technical comments related to this software, and would appreciate feedback on applications. Alan Clark Telchemy ------=_NextPart_000_00C1_01C667BD.7A0055C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
IPPM members may be = interested=20 in the new ITU-T G.1050 / TIA 921 IP impairment simulation/emulation=20 model.  This uses an impulse driven time series model to = emulate the=20 packet delays introduced by a network "stage", which may be a LAN, = access router=20 etc.
 
Telchemy developed = the original=20 algorithm for this and also maintained the reference implementation = associated=20 with the TIA and ITU projects.  We decided to make this available = free of=20 any IPR and also to make the source code freely available.  = Obviously, if=20 anyone would like copies of the associated TIA and ITU standards they = would need=20 to purchase these from TIA and ITU respectively.   The = software and=20 some documentation is available on www.telchemy.com/telsim.html=  -=20 we would welcome technical comments related to this software, and would=20 appreciate feedback on applications. 
 
 
Alan = Clark
Telchemy
 
 
------=_NextPart_000_00C1_01C667BD.7A0055C0-- --===============1718493283== 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 --===============1718493283==-- From ippm-bounces@ietf.org Mon Apr 24 18:25:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY9Ud-0005GS-CP; Mon, 24 Apr 2006 18:25:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY9Ub-0005GN-Ci for ippm@ietf.org; Mon, 24 Apr 2006 18:25:17 -0400 Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY9UZ-0007k7-1x for ippm@ietf.org; Mon, 24 Apr 2006 18:25:17 -0400 Received: from lombok-fi.grc.nasa.gov (seraph1.grc.nasa.gov [128.156.10.10]) by mx1.grc.nasa.gov (Postfix) with ESMTP id 61E29C253 for ; Mon, 24 Apr 2006 18:25:12 -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 k3OMPCdU023011 for ; Mon, 24 Apr 2006 18:25:12 -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 k3OMPB1d019195 for ; Mon, 24 Apr 2006 18:25:11 -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 18250-02 for ;Mon, 24 Apr 2006 18:25:11 -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 k3OMP6xO019181for ; Mon, 24 Apr 2006 18:25:07 -0400 (EDT) Received: by firebird1.grc.nasa.gov (Postfix, from userid 501)id E7D073038D; Mon, 24 Apr 2006 18:25:06 -0400 (EDT) Date: Mon, 24 Apr 2006 18:25:06 -0400 From: Joseph Ishac To: ippm@ietf.org Subject: Re: [ippm] I-D ACTION:draft-ietf-ippm-bw-capacity-01.txt Message-ID: <20060424222506.GA23241@firebird1.grc.nasa.gov> Mail-Followup-To: ippm@ietf.org References: <20060405231155.GA26226@firebird1.grc.nasa.gov> <001201c662bf$8e8c9010$6700a8c0@Trantor> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001201c662bf$8e8c9010$6700a8c0@Trantor> User-Agent: Mutt/1.4.2.1i X-imss-version: 2.038 X-imss-result: Passed X-imss-scores: Clean:86.15272 C:2 M:3 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: 9182cfff02fae4f1b6e9349e01d62f32 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 On Tue, Apr 18, 2006 at 10:10:28AM +0200, Patrik Arlos wrote: > 1) Would it not be possibly to say that a speed reduction is due to packet > loss/signal degradation. What I'm getting at is that we can view the NPLC as > fixed, it's just subject to more disturbances, thus making the perceived > capacity (as viewed from layer +1) smaller than the NPLC. > > In short, I agree that it is sufficient to say that "NomCap (t,t+I) > > C(t,t+I), for all values of t and I." Ok, cool. > 2) I think that you should add one line that highlights how link-layer links > are supposed to be treated, just for clarification. I added a two sentence blurb that attempts to do that. See... > Can you send a copy/url to the current working document? http://roland.grc.nasa.gov/~jishac/share/draft-ietf-ippm-bw-capacity-02.txt The changes fall in Section 2, page 5. Thanks! -Joseph _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Apr 25 08:09:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYMLn-0008DO-Co; Tue, 25 Apr 2006 08:09:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY8wF-0007cd-4k for ippm@ietf.org; Mon, 24 Apr 2006 17:49:47 -0400 Received: from pop-cowbird.atl.sa.earthlink.net ([207.69.195.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY8wC-0005Bw-PL for ippm@ietf.org; Mon, 24 Apr 2006 17:49:47 -0400 Received: from h-68-166-188-143.snvacaid.dynamic.covad.net ([68.166.188.143] helo=oemcomputer) by pop-cowbird.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FY8w7-0003Qz-00; Mon, 24 Apr 2006 17:49:40 -0400 Message-ID: <001a01c667e9$897624e0$6501a8c0@oemcomputer> From: "Randy Presuhn" To: References: <6.2.1.2.0.20060423103143.022fb7c8@postoffice.maillennium.att.com> Subject: Re: [ippm] Review of: draft-ietf-ippm-reordering-12.txt Date: Mon, 24 Apr 2006 14:53:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f X-Mailman-Approved-At: Tue, 25 Apr 2006 08:09:02 -0400 Cc: "Mreview \(E-mail\)" 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 - I think the question is much simpler. Without getting into the question of accuracy or precision of the measurements, what are the UNITS in which they are reported? Randy ----- Original Message ----- > From: "Al Morton" > To: "Romascanu, Dan (Dan)" ; "Wijnen, Bert (Bert)" ; > Cc: "Mreview (E-mail)" > Sent: Sunday, April 23, 2006 8:00 AM > Subject: RE: [ippm] Review of: draft-ietf-ippm-reordering-12.txt > > Good morning, Dan. > > At 07:23 AM 4/23/2006, Romascanu, Dan \(Dan\) wrote: > >It is still not clear to me how this would work in the case one entity > >determines gaps in units of time and the other uses message sequence > >numbers. > > As I said below, I don't believe that reporting > *either* Gap or GapTime is possible when claiming compliance. > The text (reproduced below) says "may also" which to me says: > "permission to report GapTime, in addition to Gap". > > So any system claiming compliance with section 4.5 would > report Gaps (based on message numbers), > and Gaps would always be a basis for comparison between compliant > systems. GapTime is optional, Gaps are not. > > >Or, in case message sequence numbers are mandatory anyway, why > >does Section 4.5 still refer to units of time? > > And as I clarified below, the DstTime parameter is introduced > in section 4.3.2, and is mandatory for section 4.5: > > > In the case of the Gap metrics of Section 4.5, all the > > > parameters necessary to compute the Gap (in units of msg > > > numbers) and GapTime (in units of time) are mandatory, > > > inherited from earlier metrics (as 4.5.2 states). > > Finally, (in response to your earlier message) > time stamp resolution is an implementation detail > here in IPPM, unless you claim compliance with the active > measurement protocol. Using different Timestamp resolutions certainly > affects the degree to which the results can be compared, but > that's just one of the possible errors and uncertainties, > and it doesn't make comparison impossible. > > hope this helps, > Al > > > > >Dan > > > > > > > > > > > > > -----Original Message----- > > > From: Al Morton [mailto:acmorton@att.com] > > > Sent: Friday, April 21, 2006 10:05 PM > > > To: Wijnen, Bert (Bert); ippm@ietf.org > > > Cc: Romascanu, Dan (Dan); Mreview (E-mail) > > > Subject: Re: [ippm] Review of: draft-ietf-ippm-reordering-12.txt > > > > > > Hi Bert, > > > > > > Thanks for your review and questions. > > > Please see my take on the answers, below. > > > hope this helps, > > > Al > > > > > > At 05:55 AM 4/21/2006, Wijnen, Bert (Bert) wrote: > > > >... > > > >Looks pretty good. > > > > > > > >I have one question that maybe the authors or other WG members can > > > >answer for me and that is: > > > > > > > > In section 4.5, it seems to allow for using msg sequence > > > numbers OR > > > > units of time (without even having defined what the unit is). > > > > > > > >So I wonder how this definitions specifies an exact metric. > > > The metric > > > >would not be comparable from one to the other measurement if one of > > > >them uses msg sequence numbers, while the other uses "units > > > of time". > > > >Even if two of them use "units of time" but different units > > > (e.g. micro > > > >seconds vs > > > >milliseconds) > > > >even then they would not be comparable. > > > > > > I'll tackle the issue of different time resolutions below. > > > > > > In the case of the Gap metrics of Section 4.5, all the > > > parameters necessary to compute the Gap (in units of msg > > > numbers) and GapTime (in units of time) are mandatory, > > > inherited from earlier metrics (as 4.5.2 states). > > > > > > If one reports a metric from this section, then the Gap > > > metric is mandatory, while the GapTime is optional: > > > > > > "Gaps may also be expressed in time:" (equation follows) > > > > > > So, I don't think we should run into a problem when two > > > different testers report metrics that are compliant with > > > section 4.5. They should be able to compare the Gap (msg > > > number-based) metric, at least. > > > > > > > > > >Was it not the goal of IPPM to define EXACT metrics, so that > > > results of > > > >two different tests/measurments could be compared? > > > > > > None of the current IPPM metric RFCs mandate a resolution for > > > time stamps. > > > The IPPM Framework RFC 2330 treats Clock Issues in Section > > > 10, and simply defines the term "resolution" as "the smallest > > > unit by which the clock's time is updated." > > > > > > The One-way Delay RFC 2679 even allows for different > > > resolutions to be used on the Source and Destination clocks > > > (from 3.7.1): > > > > + The resolution of a clock adds to uncertainty about any time > > > > measured with it. Thus, if the source clock has a > > > resolution of > > > > 10 msec, then this adds 10 msec of uncertainty to any > > > time value > > > > measured with it. We will denote the resolution of the source > > > > clock and the destination clock as Rsource and Rdest, > > > > respectively. > > > > > > So, I believe we have specified the metric definitions > > > "exactly", or without ambiguity. But the degree to which > > > measurements from different implementations will be > > > comparable depends on the details of each implementation, > > > including the time stamp resolution and other sources of > > > error or uncertainty (such as time accuracy and skew). > > > > > > > > _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Apr 25 11:53:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYPqY-0008Ox-3z; Tue, 25 Apr 2006 11:53:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYPqW-0008Os-Eh for ippm@ietf.org; Tue, 25 Apr 2006 11:53:00 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FYPqW-0006OF-4H for ippm@ietf.org; Tue, 25 Apr 2006 11:53:00 -0400 X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-5.tower-120.messagelabs.com!1145980378!10493538!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 12453 invoked from network); 25 Apr 2006 15:52:59 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-5.tower-120.messagelabs.com with SMTP; 25 Apr 2006 15:52:59 -0000 Received: from acmt.att.com (acmt.mt.att.com[135.16.251.35](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20060425155258gw1001009oe>; Tue, 25 Apr 2006 15:52:58 +0000 Message-Id: <6.2.1.2.0.20060425110831.08ac6390@postoffice.maillennium.att.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 25 Apr 2006 11:52:58 -0400 To: "Romascanu, Dan \(Dan\)" , "Wijnen, Bert \(Bert\)" ,ippm@ietf.org From: Al Morton Subject: RE: [ippm] Review of: draft-ietf-ippm-reordering-12.txt In-Reply-To: <6.2.1.2.0.20060423103143.022fb7c8@postoffice.maillennium.a tt.com> References: <6.2.1.2.0.20060423103143.022fb7c8@postoffice.maillennium.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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, After several off-list exchanges with Bert and Dan, we have a better statement of the issues Bert raised w.r.t. reordering metrics Sec 4.5: 1. Metrics with multiple output parameters are somewhat problematic for NM systems, and a simple MetricName:value relationship is desired. If we defined two metrics in Sec 4.5, they could be called: Type-P-Packet-Reordering-Gap-Stream Type-P-Packet-Reordering-GapTime-Stream and then we could easily refer to them in the IANA section, and get a metric number assigned to each one in the registry. However, I see that we would have to do the same thing in Sec 4.6. There are four output parameters that we defined, so we would need a new metric name for each one: Type-P-Packet-Reordering-Free-Run-x-numruns-Stream Type-P-Packet-Reordering-Free-Run-q-squruns-Stream Type-P-Packet-Reordering-Free-Run-p-numpkts-Stream Type-P-Packet-Reordering-Free-Run-a-accpkts-Stream An alternative to adding all these new metric names would be to simply revise the (new) IANA section to reflect the existence of output parameters, but this seems less straightforward. So the current plan is to add the new metric names and corresponding entries in the IANA section. (Also, it's possible to revise the text of section 4.5 to make it more clear the GapTime is optional, and we'll make those changes while in that neighborhood.) Back to Bert's Issues: 2. When a metric is reported in units of time, it's much easier to compare the results between systems if the same resolution is used, and some standard solution should be developed. My conclusion is that all the "time" metrics in the current IPPM registry RFC 4148 would not necessarily be reported with a standard resolution because IPPM has allowed flexibility in this area (and even the units might differ: seconds vs. millisec). In order for the registry to be useful, more standardization is needed, and the need is larger than the reordering draft. I believe we need an agreement/solution that covers all our metrics as pertains to their values stored and reported in the context of the metric registry. Also, Randy Presuhn observed that we have have not explicitly specified the units of time in the reordering draft, possibly because we been using the word "time" synonymously with "seconds". This is easily corrected in sections 4.3 and 4.5, where we would specify units of seconds explicitly. Constructive comments on any of these issues would be welcome. Al _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Apr 25 12:04:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYQ0s-0003ev-Ef; Tue, 25 Apr 2006 12:03:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYQ0r-0003eb-5P for ippm@ietf.org; Tue, 25 Apr 2006 12:03:41 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYQ0p-0007Av-Tn for ippm@ietf.org; Tue, 25 Apr 2006 12:03:41 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k3PG3axZ016489; Tue, 25 Apr 2006 11:03:37 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 25 Apr 2006 18:03:34 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15509E13567@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Al Morton , "Romascanu, Dan (Dan)" , ippm@ietf.org Subject: RE: [ippm] Review of: draft-ietf-ippm-reordering-12.txt Date: Tue, 25 Apr 2006 18:03:35 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 Thanks Al, you summarized our discussion wel. Bert > -----Original Message----- > From: Al Morton [mailto:acmorton@att.com] > Sent: Tuesday, April 25, 2006 17:53 > To: Romascanu, Dan (Dan); Wijnen, Bert (Bert); ippm@ietf.org > Subject: RE: [ippm] Review of: draft-ietf-ippm-reordering-12.txt > > > IPPM, > > After several off-list exchanges with Bert and Dan, we have a better > statement of the issues Bert raised w.r.t. reordering metrics Sec 4.5: > > 1. Metrics with multiple output parameters are somewhat problematic > for NM systems, and a simple MetricName:value relationship is desired. > > If we defined two metrics in Sec 4.5, they could be called: > Type-P-Packet-Reordering-Gap-Stream > Type-P-Packet-Reordering-GapTime-Stream > and then we could easily refer to them in the IANA section, > and get a metric number assigned to each one in the registry. > > However, I see that we would have to do the same thing in Sec 4.6. > There are four output parameters that we defined, so we would > need a new metric name for each one: > Type-P-Packet-Reordering-Free-Run-x-numruns-Stream > Type-P-Packet-Reordering-Free-Run-q-squruns-Stream > Type-P-Packet-Reordering-Free-Run-p-numpkts-Stream > Type-P-Packet-Reordering-Free-Run-a-accpkts-Stream > > An alternative to adding all these new metric names would > be to simply revise the (new) IANA section to reflect the existence > of output parameters, but this seems less straightforward. > > So the current plan is to add the new metric names and corresponding > entries in the IANA section. (Also, it's possible to revise the > text of section 4.5 to make it more clear the GapTime is optional, > and we'll make those changes while in that neighborhood.) > > > Back to Bert's Issues: > 2. When a metric is reported in units of time, it's much easier > to compare the results between systems if the same resolution > is used, and some standard solution should be developed. > > My conclusion is that all the "time" metrics in the current > IPPM registry RFC 4148 would not necessarily be reported > with a standard resolution because IPPM has allowed flexibility > in this area (and even the units might differ: seconds vs. millisec). > In order for the registry to be useful, more standardization > is needed, and the need is larger than the reordering draft. > I believe we need an agreement/solution that covers all > our metrics as pertains to their values stored and reported in the > context of the metric registry. > > Also, Randy Presuhn observed that we have have not explicitly > specified the units of time in the reordering draft, possibly > because we been using the word "time" synonymously with "seconds". > This is easily corrected in sections 4.3 and 4.5, where we > would specify units of seconds explicitly. > > Constructive comments on any of these issues would be welcome. > > Al > _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Apr 25 18:24:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYVwO-0007vc-W0; Tue, 25 Apr 2006 18:23:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYVwN-0007vX-KY for ippm@ietf.org; Tue, 25 Apr 2006 18:23:27 -0400 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYVwM-0003yS-2Y for ippm@ietf.org; Tue, 25 Apr 2006 18:23:27 -0400 Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id BFE2A47C45; Tue, 25 Apr 2006 18:23:25 -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 10876-07; Tue, 25 Apr 2006 18:23:25 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 6B45847C04; Tue, 25 Apr 2006 18:23:25 -0400 (EDT) To: "Schmoll, Carsten" Subject: Re: [ippm] draft-shalunov-ippm-reporting-00.txt References: <70524A4436C03E43A293958B505008B61B9CFB@EXCHSRV.fokus.fraunhofer.de> From: stanislav shalunov Date: 25 Apr 2006 18:23:27 -0400 In-Reply-To: <70524A4436C03E43A293958B505008B61B9CFB@EXCHSRV.fokus.fraunhofer.de> Message-ID: <8664kxwazk.fsf@abel.internet2.edu> Lines: 244 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: 32029c790f79bd4a84a26bd2915c54b9 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: > I read your draft and I think it is going in the > right direction. Some suggestions for the next > version from my point of view are: Carsten, Thank you for the thoughtful review. In my response, unless specified otherwise, unidiff format means changes I made to the document to accommodate your concern. > * Motivation: should state some application areas, i.e. > "why would a human user want to get those values" - e.g. > 'to check that IP telephony would be feasable with available QoS' @@ -68,7 +68,28 @@ Such a set would enable different tools to produce results that can be compared against each other. -The set is meant for human consumption. It must therefore be +Existing tools already report statistic about the network. This is +done for varying reasons: network testing tools, such as the ping +program available in UNIX-derived operating systems as well as in +Microsoft Windows, report statistics with no knowledge of why the user +is running the program; networked games might report statistics of the +network connection to the server so users can better understand why +they get the results they get (e.g., if something is slow, is this +because of the network or the CPU?), so they can compare their +statistics to those of others (``you're not lagged any more than I +am'') or perhaps so that users can decide whether they need to upgrade +the connection to their home; IP telephony hardware and software might +report the statistics for similar reasons. While existing tools +report statistics all right, the particular set of metrics they choose +is ad hoc; some metrics are not statistically robust, some are not +relevant, and some are not easy to understand; more important than +specific shortcomings, however, is the incompatibility: even if the +sets of metrics were perfect, they would still be all different, and, +therefore, metrics reported by different tools would not be +comparable. + +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. > * please don't be offended, but I disagree on the traffic > statistics you plan to apply to the traffic metrics. > To me they seem to be quite unusual. see below: > > * delay: I would suggest to use mean or a high percentile as > I have never seen median delay to be used to report QoS Henk already responded to this. Mean of delay is undefined, infinite, or unknown (depending on how you look at it) for most samples. Reporting invalid statistics can't be a good strategy. The only thing mean has going for it is that it's trivial to compute. Luckily, percentiles can be computed approximately with good efficiency, too. In addition, mean, even when defined, is not robust. I fail to see advantage of high percentile over median. A high percentile will be more frequently infinite, is less robust, is harder to understand, and, in general, has no advantages in relevancy, orthogonality, or ease of computation [1]. > * loss: just a typo = per cent -> percent Actually, it was not a typo, but if it causes confusion, then -Loss is the fraction, expressed in per cent, of packets that did +Loss is the fraction, expressed as a percentage, of packets that did > * jitter: as far as I know the two common defintions are > (high) percentile minus min delay across some interval > (ITU approach) or min/max of IP delay variation, taken from > the series of differences of consecutuve OWD values (IETF approach) The definition of the document fits into the very general IPDV framework (with an appropriate selection function, if I remember IPDV terminology right). The use of 0th percentile (minimum) in inter-percentile spread is, indeed, appealing. However, it is appealing for reasons that might turn out to be temporary: namely, the main reason to use a min is that it the maximum likelihood estimator of propagation delay in network models where propagation delay is fixed and queuing delay is distributed so that there's significant clumping at 0 (ddf(x) --> +infinity as x --> +0 is a necessary condition, but almost certainly not sufficient; shifted exponential distribution works as an example where minimum, is, indeed, the maximum likelihood estimate of the shift parameter). Maximum likelihood estimators are asymptotically consistent, and this makes minimum attractive. However, two considerations made me reject it: (1) While one end of the spread starts to mean something, the other is just as arbitrary. Using maximum as the other end is clearly a poor choice, so symmetry must be broken. This makes the metric harder to understand. (2) In today's world, indeed, the minimum delay is a decent propagation delay estimate. We don't know whether it'll remain this way. For example, a world with most traffic going between high-speed wireless points (e.g., where a ubiquitous mode of connectivity is through a low-orbit satellites) has little use for minimum delay. In such a world minimum breaks. On the other hand, interquartile spread is a well-understood metric that is robust without strong assumptions about the nature of the distribution. > * duplication: just lacks definition of a default timeout value Duplication is the fraction of packets for which more than a single -copy of the packet was received within the timeout period, expressed +copy of the packet was received within the timeout period (same +timeout as in the definition of loss), expressed in percentage points. > * additionally I think two things will need to be added to the draft: > a) mentioning about the size of the interval about which all > those metrics are obtained and the fact whether this will be > a sliding window or fixed time slots, e.g. new values each 10sec > b) I'd personally like to see some "packet filter" added to the > reporting record. Data might relate only to a fraction of all > traffic, e.g. only to UDP or only to traffic from videos.fun.org +
+ + describes the metrics to compute on a +sample of measurements. The source of the sample in not discussed +there, and, indeed, the metrics discussed (delay, loss, etc.) are +simply estimators that could be applied to any sample whatsoever. For +the names of the estimators to be applicable, of course, the +measurements need to come from a packet delivery network. + +The data in the samples for the set of metrics discussed in this +document can come from the following sources: one-way active +measurement, round-trip measurement, and passive measurement. There +infrequently is a choice between active and passive measurement, as, +typically, only one is available; consequently, no preference is given +to one over the other. In cases where clocks can be expected to be +synchronized, in general, one-way measurements are preferred over +round-trip measurements (as one-way measurements are more +informative). When one-way measurements cannot be obtained, or when +clocks cannot be expected to be synchronized, round-trip measurement +MAY be used. + +
+ +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. When +randomized schedules, such as a Poisson stream, are used, the rate +MUST be set with the distribution parameter(s). + +The default packet size is the minimum necessary for the +measurement. + +Values other than the default ones MAY be used; if they are used, +their use, and specific values used, MUST be reported. + +A one-way active measurement is characterized by the source IP +address, the destination IP address, and the time when measurement was +taken. For the time, the middle of the measurement interval MUST be +reported. + +
+
+ +The same default parameters and characterization apply to +round-trip measurement as to one-way measurement (). + +
+ +
+ +Passive measurement use whatever data it is natural to use. For +example, an IP telephony application or a networked game would use the +data that it sends. An analysis of performance of a link might use +all the packets that traversed the link in the measurement interval. +An analysis of performance of an Internet service provider's network +might use all the packets that traversed the network in the +measurement interval. An analysis of performance of a specific +service from the point of view of a given site might use an +appropriate filter to select only the relevant packets. + +The same default duration applies to passive measurement as to +one-way active measurement (). + +When the passive measurement data is reported in real time, a +sliding window SHOULD be used as a measurement period, so that recent +data become more quickly reflected. + +
+ +
> * additionally "availability" could be one metric > (probably with param = (list of) server(s) or network) 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? > * a small final note (not specific to the draft): when applying the > ITU definition for jitter, then high percentile of delay and jitter > are quite correlated, and just differ by the interval's min-delay. > I cannot say if/how they correlate when the IETF definition (IPDV) is > used. The median and the interquartile spread are sufficiently orthogonal and widely used by statisticians. > * one question from my side: how would you define/report the measurement > parameters? > (i.e. the src/dst/network/path to which the reported delay/jitter etc. > applies) I believe this is covered now. Thanks again, --Stanislav P.S. I'll send out a version of the draft with these changes rolled in. [1] Well, OK, the 100th percentile (maximum) *is* easier to compute, but it is clearly unusable otherwise, as it has all the deficiencies of mean, only to a much larger extent. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed in boustrophedon. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Apr 25 18:26:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYVz6-00007H-Ly; Tue, 25 Apr 2006 18:26:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYVz5-00006h-0G for ippm@ietf.org; Tue, 25 Apr 2006 18:26:15 -0400 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYVz3-0004D5-N4 for ippm@ietf.org; Tue, 25 Apr 2006 18:26:14 -0400 Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 7CFE247E0A; Tue, 25 Apr 2006 18:26:13 -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 11267-08; Tue, 25 Apr 2006 18:26:13 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 3E06D47C04; Tue, 25 Apr 2006 18:26:13 -0400 (EDT) To: Henk Uijterwaal Subject: Re: [ippm] draft-shalunov-ippm-reporting-00.txt References: <70524A4436C03E43A293958B505008B61B9CFB@EXCHSRV.fokus.fraunhofer.de> <7.0.1.0.2.20060421103820.0346a710@ripe.net> From: stanislav shalunov Date: 25 Apr 2006 18:26:15 -0400 In-Reply-To: <7.0.1.0.2.20060421103820.0346a710@ripe.net> Message-ID: <861wvlwauw.fsf@abel.internet2.edu> Lines: 57 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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: "Schmoll, Carsten" , 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: > >* Motivation: should state some application areas, i.e. > > "why would a human user want to get those values" - e.g. > > 'to check that IP telephony would be feasable with available QoS' > > I agree with this. Addressed. > >* delay: I would suggest to use mean or a high percentile as > > I have never seen median delay to be used to report QoS > > We have had this discussion before and consensus seems that median (or > percentiles in general) seem the most appropriate way to report delays. > We should probably point to this discussion. > > Carsten: If median cannot be used, then please explain why. Agreed. > >* duplication: just lacks definition of a default timeout value > > I think we should define one time-out value for delay, loss and > duplication. I believe this is what we have now. > >* additionally I think two things will need to be added to the draft: > > a) mentioning about the size of the interval about which all > > those metrics are obtained and the fact whether this will be > > a sliding window or fixed time slots, e.g. new values each 10sec > > b) I'd personally like to see some "packet filter" added to the > > reporting record. Data might relate only to a fraction of all > > traffic, e.g. only to UDP or only to traffic from videos.fun.org > > The way I understood the set, is that this refers to 1 pair of > source-destination, that is, you get 5 numbers for traffic between src1 > and dst1, then 5 other numbers for src1 to dst2. This is addressed now. (The applicability, as written, is more general than that.) > >* additionally "availability" could be one metric > > (probably with param = (list of) server(s) or network) > > There is an availability metric but I don't think anybody has implemented > it. I don't see the need in this set of 5 either, loss and delay already > tell you that the dst can see the src. "availability" would just confirm > that. Agreed. -- 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 Tue Apr 25 18:30:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYW2E-0001ff-HO; Tue, 25 Apr 2006 18:29:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYW2D-0001fa-Lr for ippm@ietf.org; Tue, 25 Apr 2006 18:29:29 -0400 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYW2D-0004KA-Cl for ippm@ietf.org; Tue, 25 Apr 2006 18:29:29 -0400 Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 2D78047C5E; Tue, 25 Apr 2006 18:29:29 -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 11836-05; Tue, 25 Apr 2006 18:29:29 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 052DD47C59; Tue, 25 Apr 2006 18:29:29 -0400 (EDT) To: "Schmoll, Carsten" Subject: Re: [ippm] draft-shalunov-ippm-reporting-00.txt References: <70524A4436C03E43A293958B505008B61B9D13@EXCHSRV.fokus.fraunhofer.de> From: stanislav shalunov Date: 25 Apr 2006 18:29:31 -0400 In-Reply-To: <70524A4436C03E43A293958B505008B61B9D13@EXCHSRV.fokus.fraunhofer.de> Message-ID: <86wtdduw50.fsf@abel.internet2.edu> Lines: 47 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: 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 "Schmoll, Carsten" writes: > Technically median delay can of course be used, yet I don't > see its importance, since it does capture the influence of > dalay spikes/outliers even *less* than average delay Exactly. In other words, median is more robust. > - and a change in those outliers, i.e. the tail of the delay > distribution is often the most significant issue to know when > checking whether some service could run with an acceptable quality. Jitter characterizes how variable the delay is. Delay is as robust as possible and does not attempt to characterize micro-variation; indeed, it avoids doing so for orthogonality reasons. > In case I forgot about some important property of median > delay, please let me know. > > >* duplication: just lacks definition of a default timeout value > > > > I think we should define one time-out value for delay, loss and > > duplication. > > Agree. The default value can be the same. It should be a > safe upper limit for OWD. Those 2sec would be find with me. That's what we have. > > > b) I'd personally like to see some "packet filter" added to the > > > reporting record. Data might relate only to a fraction of all > > > traffic, e.g. only to UDP or only to traffic from > videos.fun.org > > > > The way I understood the set, is that this refers to 1 pair of > > source-destination, that is, you get 5 numbers for traffic > > between src1 and dst1, then 5 other numbers for src1 to dst2. > > Yes, I would say so too. This opens the question: are src+dst part of > the reported parameters, part of the request by the client, or both? The former. There is not necessarily anything one might call a client. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed at an angle of 45 degrees. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Apr 25 18:42:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYWEO-0005da-Cw; Tue, 25 Apr 2006 18:42:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYWEM-0005dF-MI; Tue, 25 Apr 2006 18:42:02 -0400 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYWEL-00056H-Ee; Tue, 25 Apr 2006 18:42:02 -0400 Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 39BD147DCD; Tue, 25 Apr 2006 18:42:01 -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 13336-06; Tue, 25 Apr 2006 18:42:01 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 148DA47C59; Tue, 25 Apr 2006 18:42:01 -0400 (EDT) To: Internet-Drafts Administrator Subject: [ippm] draft-shalunov-ippm-reporting-02.txt From: stanislav shalunov Date: 25 Apr 2006 18:42:03 -0400 Message-ID: <86odypuvk4.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 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-02.txt (SHA1 = 041cf9ad336a8446f06787a2ccc271c668130463) as an internet-draft. - -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ Heather has two mommies. That's nothing. The Internet has at least two dozen daddies. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQCVAwUBRE6lqJRUn1EgN49xAQFYyQQAsiqKdw9qXVyw6MKtDJljuD2SJCpiO/SR U35IlnYH6MfdyHDAlpqf1qa7iAviZsAHIgbyI6PbT365ygb8LsI1lI/zRFr15bT6 kBUP0nPSzsdWXhSoWHa3rXsLgHCn8YYOYTAjOOI+ZklVdINPCiOnaVeVsJ1Yhl2v 5zSsa+CQpmQ= =aq38 -----END PGP SIGNATURE----- _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed Apr 26 11:44:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYmC2-0006XV-9n; Wed, 26 Apr 2006 11:44:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYmC1-0006XQ-3l for ippm@ietf.org; Wed, 26 Apr 2006 11:44:41 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FYmBx-0003kP-OM for ippm@ietf.org; Wed, 26 Apr 2006 11:44:41 -0400 X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-3.tower-120.messagelabs.com!1146066276!10847199!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 21228 invoked from network); 26 Apr 2006 15:44:36 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-3.tower-120.messagelabs.com with SMTP; 26 Apr 2006 15:44:36 -0000 Received: from acmt.att.com (acmt.mt.att.com[135.16.251.35](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20060426154436gw100100ije>; Wed, 26 Apr 2006 15:44:36 +0000 Message-Id: <6.2.1.2.0.20060426114119.08a9d828@postoffice.maillennium.att.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 26 Apr 2006 11:44:36 -0400 To: stanislav shalunov , Henk Uijterwaal From: Al Morton Subject: Re: [ippm] draft-shalunov-ippm-reporting-00.txt In-Reply-To: <861wvlwauw.fsf@abel.internet2.edu> References: <70524A4436C03E43A293958B505008B61B9CFB@EXCHSRV.fokus.fraunhofer.de> <7.0.1.0.2.20060421103820.0346a710@ripe.net> <861wvlwauw.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: 79899194edc4f33a41f49410777972f8 Cc: "Schmoll, Carsten" , 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 06:26 PM 4/25/2006, stanislav shalunov wrote: > > > [Carsten wrote:] > > >* delay: I would suggest to use mean or a high percentile as > > > I have never seen median delay to be used to report QoS > > [Henk wrote:] > > We have had this discussion before and consensus seems that median (or > > percentiles in general) seem the most appropriate way to report delays. > > We should probably point to this discussion. > > > > Carsten: If median cannot be used, then please explain why. > >Agreed. Can someone provide the pointer to this discussion? thx, Al _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu Apr 27 00:27:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYy5n-0007QQ-VZ; Thu, 27 Apr 2006 00:27:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYy5m-0007LG-Io for ippm@ietf.org; Thu, 27 Apr 2006 00:27:02 -0400 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYy5l-0007UT-Ak for ippm@ietf.org; Thu, 27 Apr 2006 00:27:02 -0400 Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 05F1647D46; Thu, 27 Apr 2006 00:27:01 -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 10425-05; Thu, 27 Apr 2006 00:27:00 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id ADCCA47D04; Thu, 27 Apr 2006 00:27:00 -0400 (EDT) To: Al Morton Subject: Re: [ippm] draft-shalunov-ippm-reporting-00.txt References: <70524A4436C03E43A293958B505008B61B9CFB@EXCHSRV.fokus.fraunhofer.de> <7.0.1.0.2.20060421103820.0346a710@ripe.net> <861wvlwauw.fsf@abel.internet2.edu> <6.2.1.2.0.20060426114119.08a9d828@postoffice.maillennium.att.com> From: stanislav shalunov Date: 27 Apr 2006 00:27:02 -0400 In-Reply-To: <6.2.1.2.0.20060426114119.08a9d828@postoffice.maillennium.att.com> Message-ID: <867j5bprs9.fsf@abel.internet2.edu> Lines: 30 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: ea4ac80f790299f943f0a53be7e1a21a Cc: "Schmoll, Carsten" , Henk Uijterwaal , 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: > At 06:26 PM 4/25/2006, stanislav shalunov wrote: > > > > [Carsten wrote:] > > > >* delay: I would suggest to use mean or a high percentile as > > > > I have never seen median delay to be used to report QoS > > > [Henk wrote:] > > > We have had this discussion before and consensus seems that median (or > > > percentiles in general) seem the most appropriate way to report delays. > > > We should probably point to this discussion. > > > > > > Carsten: If median cannot be used, then please explain why. > > > >Agreed. > > Can someone provide the pointer to this discussion? I can't seem to find the pointers, but the fact that mean of observed values is not the best estimator has been rehashed a few times. One notable outcome is the prominent absence of mean delay from RFC2679. I'll write up the usual boring reasons why mean delay is an invalid metric, and why mean of the observed singleton delays is not very useful so that the writeup is more permanent than the back-and-forth of the mailing list. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ A fool's brain digests philosophy into folly, science into superstition, and art into pedantry. Hence University education. -- G. B. Shaw _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu Apr 27 14:58:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZBgU-0001OV-QA; Thu, 27 Apr 2006 14:57:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZBgT-0001OQ-IE for ippm@ietf.org; Thu, 27 Apr 2006 14:57:49 -0400 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZBgS-0001Gs-AQ for ippm@ietf.org; Thu, 27 Apr 2006 14:57:49 -0400 Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id DDF9147D88; Thu, 27 Apr 2006 14:57:45 -0400 (EDT) Received: from basie.internet2.edu ([127.0.0.1]) by localhost (basie.internet2.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03212-01; Thu, 27 Apr 2006 14:57:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 9639B47C17; Thu, 27 Apr 2006 14:57:45 -0400 (EDT) To: Al Morton Subject: Re: [ippm] draft-shalunov-ippm-reporting-00.txt References: <70524A4436C03E43A293958B505008B61B9CFB@EXCHSRV.fokus.fraunhofer.de> <7.0.1.0.2.20060421103820.0346a710@ripe.net> <861wvlwauw.fsf@abel.internet2.edu> <6.2.1.2.0.20060426114119.08a9d828@postoffice.maillennium.att.com> <867j5bprs9.fsf@abel.internet2.edu> From: stanislav shalunov Date: 27 Apr 2006 14:57:48 -0400 In-Reply-To: <867j5bprs9.fsf@abel.internet2.edu> Message-ID: <86r73ig82b.fsf@abel.internet2.edu> Lines: 18 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: 856eb5f76e7a34990d1d457d8e8e5b7f 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 stanislav shalunov writes: > I can't seem to find the pointers, but the fact that mean of observed > values is not the best estimator has been rehashed a few times. One > notable outcome is the prominent absence of mean delay from RFC2679. > I'll write up the usual boring reasons why mean delay is an invalid > metric, and why mean of the observed singleton delays is not very > useful so that the writeup is more permanent than the back-and-forth > of the mailing list. As promised, http://www.internet2.edu/~shalunov/writing/mean-delay-considered-harmful.html -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ Democracy is a form of government that substitutes election by the incompetent many for appointment by the corrupt few. -- G. B. Shaw _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm